crypto/tls: implement and enable X25519Kyber768Draft00

[FiloSottile]

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

[rsc]

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.

[rsc]

No change in consensus, so accepted. 🎉 This issue now tracks the work of implementing the proposal. — 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.

[gopherbot]

Change https://go.dev/cl/586656 mentions this issue: crypto/tls: implement X25519Kyber768Draft00

[gopherbot]

Change https://go.dev/cl/592196 mentions this issue: doc/next: improve wording for proposal 67061

[GilAddaCyberark]

Hi, I hope that my comment is ok. It's great to have the curveID parameter as a tls.Conn member. I find it very useful to validate the context in testing, and configuration. Will it be exposed as part of Go1.23? Moreover, The GODEBUG=tlskyber=1 could enable the new curve. Looking in the code, any other value or a nonexistent 'tlskyber' value will allow it to. Right? if yes, maybe the documentation should describe this method. Does the function 'IsPQEnabled' makes sense?