[adrian_b]

What you say has nothing to do with TFA, which is not about ML-KEM but about the session key establishment protocol used in TLS, in which ML-KEM is just a component.

DJB supports the use of ML-KEM in TLS, but he correctly says that using only ML-KEM is unwise, because absolutely nobody can guarantee that no method to break ML-KEM will be discovered in the next years, as it already happened with the algorithm that was preferred before ML-KEM, until it was broken a few years ago.

[galadran]

I'm afraid you've misunderstood. These codepoints are for the pure MLKEM key establishment that DJB is railing against.

All of these libraries also support the hybrid forms, which have different codepoints and are used by default. Nothing in the IETF process has any bearing on this.

[throwaway81523]

Does the specification recommend using a hybrid? At the level of at least SHOULD if not MUST, in the sense of RFC 2119? I have the opposite impression but haven't checked.

[galadran]

In effect, yes it does.

The Recommended flag is set for X25519MLKEM768. It is not set for any of the pure PQ key exchanges.

https://www.iana.org/assignments/tls-parameters/tls-paramete...

[throw0101d]

> DJB supports the use of ML-KEM in TLS, but he correctly says that using only ML-KEM is unwise

Then don't use it if you don't want to? Use hybrid? ML-KEM (CRYSTALS-Kyber) is a NIST standard, FIPS 203:

* https://csrc.nist.gov/pubs/fips/203/final

* https://en.wikipedia.org/wiki/ML-KEM

There's also HQC, FIPS 207:

* https://csrc.nist.gov/presentations/2025/fips-207-hqc-kem

Unless you're doing government work, there's no reason why you'd be force to use Officially Approved™ algorithms:

* https://en.wikipedia.org/wiki/Commercial_National_Security_A...

If the (US) government wants to use (allegedly) compromised algorithms with-in itself that's up to them. The rest of us can use whatever we want.