Fyrd
X25519Kyber768 Hybrid Post-Quantum Key Exchange for HTTPS
Hybrid key exchange in SSL handshake using ML-KEM in addition to default already has significant usage thanks to Google and Cloudflare. It appears to only be supported currently in TLS 1.3 but is intended for TLS 1.2 as well.
but is intended for TLS 1.2 as well
The IETF does not intend to backport PQ cryptography to TLS 1.2: https://www.ietf.org/archive/id/draft-ietf-tls-tls12-frozen-02.html#name-implications-for-post-quant
I think at this point we want to track X25519MLKEM768 (IANA Key Share Entry Group '4588'); X25519Kyber768Draft00 was intended to be experimental and to be replaced by the standardized FIPS 203 X25519MLKEM768. Firefox shipped ML-KEM support in 132.0; Chrome added an experimental flag #use-ml-kem in 130, and based on their announcement will enable that and disable Kyber in 131 (which should go stable on 2024-11-11).
Keeping track of X25519Kyber768Draft00 is probably going to be moot at that point.
By now you really want to track all of the following:
- ML-KEM (FIPS-203)
- ML-DSA (FIPS-204)
- SLH-DSA (FIPS-205)
- X25519MLKEM768 (https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/03/)
- SecP256r1MLKEM768 (https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/03/)
- SecP384r1MLKEM1024 (https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/03/)
Chrome and Firefox currently implement X25519MLKEM768; OpenSSL will land support for at least the first four in OpenSSL 3.5 (planned release date is 2025-04-08), boringssl already supports X25519MLKEM768.
See also: https://www.netmeister.org/blog/pqc-2025-02.html
I have put together the information from this thread and various other sources, including my own tests, into a new PR #7326 that adds support for the standardized post-quantum key agreement scheme X25519MLKEM768 to Caniuse. Please take a look at it and let me know if there are any errors that need to be fixed.
