Support configuration of post-quantum-safe KEM mode #5371
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 theGODEBUG
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.