crypto/tls: implement and enable X25519Kyber768Draft00 #67061
Description
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