The Internet Engineering Task Force (IETF) published RFC 10024 on August 10, 2026, as a Proposed Standard for combining the post-quantum algorithm ML-KEM with elliptic-curve key exchange in TLS 1.3, the current version of the protocol that encrypts web connections. The RFC Editor lists its title as “Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3.”
Kris Kwiatkowski of PQShield, Panos Kampanakis of AWS, Bas Westerbaan of Cloudflare, and Douglas Stebila of the University of Waterloo wrote the specification. With it, the IETF has put X25519MLKEM768, a hybrid group that the authors described as “widely deployed,” on the standards track for key agreement and left server authentication, which most TLS connections perform with certificate signatures, unchanged.
ML-KEM, formerly CRYSTALS-Kyber, is the key-encapsulation mechanism, or KEM, that NIST standardized in FIPS 203 in August 2024 to resist attacks by quantum computers. With a KEM, one party wraps a fresh secret under the other party’s public key so that only the holder of the matching private key can recover it.
The hybrid groups are designed to protect the session keys that encrypt each connection. An adversary who records traffic today could otherwise decrypt sessions that used classical key exchange alone once a quantum computer can break elliptic-curve cryptography, an attack pattern known as harvest now, decrypt later.
What hybrid means in RFC 10024
The authors used “hybrid” in the sense of RFC 9954, an Informational RFC that Stebila co-wrote and the IETF published in July 2026. In RFC 10024, they summarized that definition of a hybrid key exchange as “the simultaneous use of multiple key exchange algorithms, with their outputs combined to provide security as long as at least one of the component algorithms remains secure, even if the others are compromised.”
In each of the new groups, the client and server perform an elliptic-curve Diffie–Hellman exchange and an ML-KEM encapsulation in the same handshake and concatenate the two shared secrets. The authors paired X25519 with ML-KEM-768 in X25519MLKEM768, NIST’s P-256 curve with ML-KEM-768 in SecP256r1MLKEM768, and P-384 with ML-KEM-1024 in SecP384r1MLKEM1024.
They put the ML-KEM secret first in X25519MLKEM768 and the elliptic-curve secret first in the other two groups. They described SecP384r1MLKEM1024 as “intended for high-security environments that require FIPS-approved mechanisms with an increased security margin.”
Registry status
In RFC 10024, the authors set the “Recommended” values that IANA, the organization that maintains the IETF’s protocol registries, records in its TLS Supported Groups registry. They marked X25519MLKEM768, code point 0x11EC, “Y,” meaning the IETF has consensus that it is recommended. They gave the two groups built on NIST curves an “N.”
In RFC 8447, the IETF wrote that an “N” “does not necessarily mean that it is flawed” and can mean that an item “has limited applicability, or is intended only for specific use cases.” RFC 9847 kept that note when it updated the column’s definitions.
The authors also changed the status of two pre-standard code points, X25519Kyber768Draft00 and SecP256r1Kyber768Draft00, which implementations used before NIST finalized ML-KEM, to “D,” a value the IETF created in RFC 9847 in December 2025 for items that are discouraged. IANA labels each one a “Pre-standards version of Kyber768.”
FIPS and certification
The authors wrote that any of the three groups “may be implemented in a FIPS-approved way.” U.S. federal agencies must use FIPS-validated cryptography to protect sensitive data. The authors tied that approval to the order of the two secrets.
For a FIPS-approved deployment, they wrote, operators need a certified elliptic-curve implementation for the two NIST-curve groups and a certified ML-KEM implementation for X25519MLKEM768.
Related drafts
The IETF was still reviewing two related TLS documents on August 10. One, draft-ietf-tls-mlkem, covering ML-KEM used on its own, was in an IETF-wide last call that ended on August 13.
The other, draft-ietf-tls-mldsa, is about ML-DSA, formerly CRYSTALS-Dilithium, as a signature scheme for authentication in TLS 1.3. The Internet Engineering Steering Group, the body that approves IETF documents, had approved it but held the approval announcement after an appeal received on July 8. The TLS working group intended both drafts for publication as Informational RFCs, a category outside the standards track.
Update, November 12, 2026: The IESG approved draft-ietf-tls-mlkem on September 3. It sent draft-ietf-tls-mldsa to the RFC Editor on September 11, a day after denying the appeal. Both drafts were held from September 24 to October 5 over complaints and appeals about their processing, and neither had been published as of November 12.
