Support configuration of post-quantum-safe KEM mode

[hlandau]

This PR adds support for enabling the experimental X25519Kyber768Draft00 post-quantum-safe TLS KEM supported in Go 1.23. Successful negotiation of a TLS 1.3 connection using X25519Kyber768Draft00 has been confirmed between spire-agent and spire-server, observed using Wireshark.

While this functionality can be enabled without code changes to SPIRE simply using GODEBUG, this allows the functionality to be configured explicitly via the config file, and for administrators to receive a log message confirming it has been enabled and thus to ensure that a post-quantum KEM is in use.

Since SPIRE currently defines a Go version of 1.21 in go.mod, it will inherit the GODEBUG values from that version; thus the Go 1.23 support will not be used by default, making it more important to have a way to configure it.

In this PR, the valid curve IDs are explicitly configured and passed through the SPIRE code, as opposed to previous experiments with adjusting process-global state such as GODEBUG. The notion of TLS policy is centralised somewhat as it's likely the amount of TLS configuration options which should have global effect will increase over time.

Identifying whether this functionality is available is currently based on a simple build-time test for Go 1.23 or later. This is slightly awkward as it is generally preferable to test for the functionality directly. Probably the only viable way to do this at runtime without inspecting version numbers is to generate a throwaway certificate, make a test connection over a pipe to oneself specifying X25519Kyber768Draft00 as the only permitted curve, and see if it succeeds. This is quite awkward.

Integration test coverage here is desirable, but I'm open to advice on what the best way to approach that would be.

[hlandau]

Updated, needs workflow approval again.

[azdagron]

Thanks for this contribution, @hlandau! After looking this over and discussing with the other maintainers, I think things can be simplified a bit now that go1.23 has been released and we've moved over to it as a project. From what I understand, the Kyber curve is added by default, _and at the top of the preference list, when CurvePreferences is unspecified. SPIRE does not set CurvePreferences, so I think what this means is that instead of a tri-state configurable (default, attempt, force), we can probably just get away a boolean "force" that sets CurvePreferences to only Kyber and otherwise we let the use default (equivalent to the current "attempt")?

[hlandau]

Thanks for this contribution, @hlandau! After looking this over and discussing with the other maintainers, I think things can be simplified a bit now that go1.23 has been released and we've moved over to it as a project. From what I understand, the Kyber curve is added by default, _and at the top of the preference list, when CurvePreferences is unspecified. SPIRE does not set CurvePreferences, so I think what this means is that instead of a tri-state configurable (default, attempt, force), we can probably just get away a boolean "force" that sets CurvePreferences to only Kyber and otherwise we let the use default (equivalent to the current "attempt")?

This makes sense, yes. I'll revise this PR to be a simple "require_pq_kem_mode = bool" option.

[azdagron]

Hey @hlandau, any plans to address this anytime soon? If not we'll probably close out the PR for now (can always re-open when ready for review).

[v0lkan]

This is excellent progress, especially considering that recent versions of Golang have begun supporting quantum-resilient algorithms.

It's definitely time to integrate this into SPIRE as well.

Turtle power 🐢⚡️.

[azdagron]

Hey @hlandau! No pressure, just wanted to check in to see if you were still planning on taking the PR forward. If not, no worries, we'll close it in a few weeks and can re-open it when you are ready. Thanks for the contrib!

[azdagron]

We'll go head and close this PR out for now. If/when you are ready to pick up the work again, please let us know and we can re-open.

[hlandau]

Sorry for the delay getting this revised: #5601