alt Hacker NewsThis is garbage from start to finish.
There are already codepoints assigned for MLKEM 512/768/1024 (0x0200, 0x0201, 0x0202) and nearly every major library supports it already:
- OpenSSL (ML-KEM-512/768/1024)
- BoringSSL (ML-KEM-1024)
- NSS (ML-KEM-1024)
- AWS-LC (ML-KEM-512/768/1024)
- Rustls (ML-KEM-768/1024)
- s2n-tls (ML-KEM-1024)
- Bouncy Castle (ML-KEM-512/768/1024)
- Botan (ML-KEM-512/768/1024)
- GnuTLS (ML-KEM-768/1024)
- WolfSSL (ML-KEM-512/768/1024)
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.