proposal: crypto/tls: implement and enable X25519Kyber768Draft00 #67061
Labels
Proposal
Proposal-Crypto
Proposal related to crypto packages or other security issues
Proposal-FinalCommentPeriod
Milestone
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.
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
The text was updated successfully, but these errors were encountered: