Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support configuration of post-quantum-safe KEM mode #5371

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

hlandau
Copy link

@hlandau hlandau commented Aug 9, 2024

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 hlandau changed the title Pqkemmode Support configuration of post-quantum-safe KEM mode Aug 9, 2024
Signed-off-by: Hugo Landau <hl@messier42.com>
Signed-off-by: Hugo Landau <hl@messier42.com>
Signed-off-by: Hugo Landau <hl@messier42.com>
@hlandau
Copy link
Author

hlandau commented Aug 12, 2024

Updated, needs workflow approval again.

@azdagron azdagron self-assigned this Aug 13, 2024
@azdagron
Copy link
Member

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
Copy link
Author

hlandau commented Sep 4, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants