proposal: crypto/tls: SecP256r1MLKEM768 and X25519MLKEM768

[FiloSottile]

The experiment with X25519Kyber768Draft00 #67061 went well, and NIST has now published the final version of the ML-KEM standard. https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/ specifies ML-KEM hybrids, including permanent codepoints, and Chrome and Cloudflare already deployed one of them.

I propose in Go 1.24 we remove X25519Kyber768Draft00 and add SecP256r1MLKEM768 and X25519MLKEM768, enabling both by default, and sending X25519MLKEM768 + X25519 key shares by default. (See #69393 for the precise preference ordering.)

We'll also add the following two CurveID constants, for use in Config.CurvePreferences and possibly for #67516.

const SecP256r1MLKEM768 CurveID = 4587
const X25519MLKEM768 CurveID = 4588

GODEBUG=tlsmlkem=0 reverts the default Config.CurvePreferences (but doesn't disable anything else).

It would be tempting to retain support for X25519Kyber768Draft00, because it's unfortunate that Go 1.23 to Go 1.24 connections would be weaker than Go 1.23 to Go 1.23, but that is already unavoidable in one direction: Go 1.23 will prefer a key share over other supported key exchange methods, so a Go 1.24 client that sends X25519MLKEM768 + X25519 will see X25519 selected by a Go 1.24 server even if it advertises support for X25519Kyber768Draft00.

[gabyhelp]

Related Issues and Documentation

• crypto/tls: implement and enable X25519Kyber768Draft00 #67061 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}