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

proposal: crypto/tls: implement and enable X25519Kyber768Draft00 #67061

Open
FiloSottile opened this issue Apr 26, 2024 · 1 comment
Open

proposal: crypto/tls: implement and enable X25519Kyber768Draft00 #67061

FiloSottile opened this issue Apr 26, 2024 · 1 comment
Labels
Proposal Proposal-Crypto Proposal related to crypto packages or other security issues Proposal-FinalCommentPeriod
Milestone

Comments

@FiloSottile
Copy link
Contributor

FiloSottile commented Apr 26, 2024

X25519Kyber768Draft00 is a hybrid post-quantum key exchange based on Kyber768 (the predecessor of ML-KEM-768) and X25519 (our current default preferred key exchange). It is defined in draft-tls-westerbaan-xyber768d00-03 and implemented by BoringSSL and rustls (rustls/rustls#1785).

I propose that we implement support for it in crypto/tls (on top of the recently merged crypto/internal/mlkem768 package) and enable it by default, with a GODEBUG opt-out.

We will send both an X25519 and an X25519Kyber768Draft00 key share in our Client Hello messages. This will make the CH significantly bigger, which initially caused some compatibility issues in the ecosystem, now hopefully resolved. The performance overhead will be by default that of an mlkem768.GenerateKey (as the X25519 share will be reused as allowed by draft-ietf-tls-hybrid-design-10).

That's allowed by the current docs of CurvePreferences.

// CurvePreferences contains the elliptic curves that will be used in
// an ECDHE handshake, in preference order. If empty, the default will
// be used. The client will use the first preference as the type for
// its key share in TLS 1.3. This may change in the future.
CurvePreferences []CurveID

Note that CurvePreferences and CurveID are now hopelessly misnomers, due to how TLS 1.3 reused them for key exchange algorithms.

Since this is an experimental algorithm that we plan to remove in the future, we will NOT define a CurveID constant for it. CurveID.String() will support it, though, so e.g. logs are correctly printed.

If applications set Config.CurvePreferences, their behavior will not change and X25519Kyber768Draft00 will not be enabled.

/cc @golang/security @golang/proposal-review

@FiloSottile FiloSottile added Proposal Proposal-Crypto Proposal related to crypto packages or other security issues labels Apr 26, 2024
@FiloSottile FiloSottile added this to the Proposal milestone Apr 26, 2024
@rsc
Copy link
Contributor

rsc commented May 8, 2024

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

The proposal is to enable X25519Kyber768Draft00 by default (when CurvePreferences = nil). If clients set CurvePreferences, it will be disabled, with no way to force-enable it. A future Go version may make that possible, once the key exchange is no longer a draft.

A new GODEBUG setting will control the behavior. GODEBUG=tlskyber=1 (the new default for go 1.23+ main modules) means enable kyber by default; GODEBUG=tlskyber=0 means don’t.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Proposal Proposal-Crypto Proposal related to crypto packages or other security issues Proposal-FinalCommentPeriod
Projects
Status: Likely Accept
Development

No branches or pull requests

2 participants