crypto/tls: add X25519MLKEM768 and use by default; remove x25519Kyber768Draft00

[FiloSottile]

Important

Nov 20, 2024: The latest version of the proposal is here.

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.)}

[aclements]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.

[aclements]

it's unfortunate that Go 1.23 to Go 1.24 connections would be weaker than Go 1.23 to Go 1.23

Given that post-quantum support in 1.23 was an experiment anyway, I'm not too bothered by the weaker crypto in this case.

[aclements]

Have all remaining concerns about this proposal been addressed?

The proposal detalis are in #69985 (comment)

[FiloSottile]

SecP256r1MLKEM768 has not yet stabilized in the IETF, so let's leave it out for Go 1.24.

X25519MLKEM768 has been widely deployed already, so it's not changing at this point.

[rsc]

I believe this proposal is now:

1. Add X25519MLKEM768 CurveID to crypto/tls.
2. Enable X25519MLKEM768 for use by default, by adding it to the default Config.CurvePreferences (semantics more like "AllowedCurves" after crypto/tls: automatic CurvePreferences ordering #69393).
3. Add new GODEBUG tlsmlkem to control (2). tlsmlkem=1 is the default for Go 1.24; setting tlsmlkem=0 undoes (2).

[aclements]

Just to be clear, we're still proposing to remove X25519Kyber768Draft00, right?

[FiloSottile]

Just to be clear, we're still proposing to remove X25519Kyber768Draft00, right?

Correct!

[aclements]

Based on the discussion above, this proposal seems like a likely accept.

The proposal is to

1. Add const X25519MLKEM768 CurveID = 4588 to crypto/tls
2. Enable X25519MLKEM768 for use by default, by adding it to the default Config.CurvePreferences
3. Add new GODEBUG tlsmlkem to control (2). tlsmlkem=1 is the default for Go 1.24; setting tlsmlkem=0 undoes (2).
4. Remove X25519Kyber768Draft00

[aclements]

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.

The proposal is to

1. Add const X25519MLKEM768 CurveID = 4588 to crypto/tls
2. Enable X25519MLKEM768 for use by default, by adding it to the default Config.CurvePreferences
3. Add new GODEBUG tlsmlkem to control (2). tlsmlkem=1 is the default for Go 1.24; setting tlsmlkem=0 undoes (2).
4. Remove X25519Kyber768Draft00

[gopherbot]

Change https://go.dev/cl/630775 mentions this issue: crypto/tls: implement X25519MLKEM768

[dmitshur]

It looks like CL 630775 implemented most of this proposal if not all, though it didn't close it. What's left for Go 1.24? Is it just SecP256r1MLKEM768, which according to #69985 (comment) is being left out of Go 1.24? (If so, perhaps that can be tracked in a separate issue, or this one should be moved to the next milestone.)

[aclements]

Since we decided to leave SecP256r1MLKEM768 out of this proposal in the end, I think that should be a new proposal (perhaps once it's stabilized by the IETF). Given that, it look like CL 630775 did indeed implement the whole proposal, but I'm not 100% sure so I'll let @FiloSottile do the closing.

[FiloSottile]

Sounds good, we can leave SecP256r1MLKEM768 to a future proposal.