proposal: crypto/tls: add support for NIST curve based ML-KEM hybrids

[tomato42]

Proposal Details

The current version of the draft-kwiatkowski-tls-ecdhe-mlkem draft includes two hybrid ML-KEM groups that use NIST curves:

• SecP256r1MLKEM768
• SecP384r1MLKEM1024

As explained in the draft, they are interesting for environments that require compliance, either with FIPS in general, or with higher security standards, like the Common Criteria Protection Profile v4.3 or CNSA 2.0.

I'd like to ask for their inclusion in a future Go release.

[ianlancetaylor]

CC @golang/security

[FiloSottile]

We were planning to ship at least the P-256 one in #69985, but with all the noise around making backwards incompatible changes to draft-kwiatkowski-tls-ecdhe-mlkem, we ended up shipping only the X25519 one, which at least has a large deployed base to hopefully protect it from changes.

[gabyhelp]

Related Issues

• crypto/tls: add X25519MLKEM768 and use by default; remove x25519Kyber768Draft00 #69985 (closed)

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

[tomato42]

@FiloSottile yes, I've read that... should have linked to it, sorry 😅

sure, I completely understand not wanting to ship code implementing draft standards, we generally have the same policy
that being said, I don't think we will see any changes to SecP256r1MLKEM768 and SecP384r1MLKEM1024, the only controversy around them is if we should have hybrids at all (and I'm pretty sure we will end up with both pure and hybrid KEXs being standardised in TLS)... X25519MLKEM768 is more controversial with its reversed order of shares

Unfortunately, only time will tell what will end up in the RFC