The Internet Engineering Steering Group (IESG) opened an IETF-wide Last Call on July 30, 2026, for draft-ietf-tls-mlkem, a specification for using the post-quantum algorithm ML-KEM, formerly CRYSTALS-Kyber, on its own to set up encryption keys in TLS 1.3. The IESG, the body that approves Internet Engineering Task Force documents for publication as Requests for Comments (RFCs), said it “plans to make a decision in the next few weeks” and asked for final comments by August 13.
TLS 1.3 is the protocol that secures web browsing and many other internet connections. The IETF’s Transport Layer Security (TLS) working group produced the draft, titled “ML-KEM Post-Quantum Key Agreement for TLS 1.3,” and asked for its publication as an Informational RFC, a category outside the IETF’s standards track.
If the IESG approves the draft, the RFC Editor will publish it as an RFC whose three key-exchange groups are marked “N” in the Internet Assigned Numbers Authority (IANA) registry, the value for items the IETF has not evaluated. In RFC 8447, the IETF wrote that an “N” “does not necessarily mean that it is flawed.”
Pure and hybrid key exchange
Under the draft, ML-KEM-512, ML-KEM-768, and ML-KEM-1024 become “NamedGroups,” the labels a TLS client and server use to agree on a key-exchange method. ML-KEM is a key-encapsulation mechanism that NIST standardized as FIPS 203 in August 2024.
In a key-encapsulation mechanism, one side uses the other’s public key to wrap a fresh shared secret that only the holder of the matching private key can unwrap. At the start of a TLS 1.3 connection, the client and server agree on such a secret and use it to encrypt the session. The classical method, elliptic-curve Diffie-Hellman, could be broken by a large quantum computer running Shor’s algorithm.
In a hybrid key exchange, the two sides run elliptic-curve Diffie-Hellman and ML-KEM in the same handshake and combine the results into one key. The combined key stays secure “as long as at least one of the component algorithms remains secure,” the authors of the hybrid specification wrote.
A pure, or standalone, key exchange uses ML-KEM alone, so the key exchange that protects a recorded session uses ML-KEM alone, with no elliptic-curve component as a second layer. Adversaries can store encrypted traffic today and decrypt it later if they find a way to break the key exchange, an approach known as harvest now, decrypt later.
Implementers “must evaluate their specific security, performance, and operational constraints when deciding whether to deploy standalone ML-KEM or a hybrid construction,” Deirdre Connolly, the draft’s author and a co-chair of the TLS working group, wrote. The registry’s recommended column “contains the IETF’s current guidance on the recommended use of these algorithms for general purposes,” she wrote in the same section.
Registry markings
The IESG approved the hybrid specification, draft-ietf-tls-ecdhe-mlkem, as a Proposed Standard on February 11. It approved the draft again on June 18, after a second Last Call held to mark its hybrid group X25519MLKEM768 “Y,” the value that RFC 9847 defines as IETF consensus that an item is recommended.
Under RFC 9847, “N” means an item “has not been evaluated by the IETF” and that the IETF has made no statement about its suitability. Connolly added that definition to the draft’s IANA section in revision 09, posted July 20. In the same revision, she added new security text on the randomness ML-KEM uses to wrap each shared secret, a concern raised by Jacob Appelbaum.
The consensus call
Joseph Salowey and Sean Turner, who chair the working group with Connolly, ran the consensus calls on the draft. Two earlier working group last calls, closing on November 26, 2025, and February 27, 2026, ended without consensus. After the first, the chairs wrote on December 7 that they did not have consensus to publish the document as it stood. On July 19, Salowey declared “rough consensus to move forward” after a third last call that ran from June 24 to July 8.
Rough consensus “is achieved when all issues are addressed, but not necessarily accommodated,” according to RFC 7282. Among “pre-existing WG participants or people with demonstrated expertise,” Salowey wrote, “roughly 7/10 WG participants favor advancing the document.”
Cryptographer Tanja Lange wrote on July 6 that she saw none of her concerns addressed and did not support publication. On June 30, the Internet Architecture Board denied an appeal by cryptographer Daniel J. Bernstein over the working group’s adoption of the draft.
Fabiana Da Pieve, who leads a post-quantum cryptography team at the European Commission’s Directorate-General for Communications Networks, Content and Technology, asked the chairs on July 19 for the evidence behind their numbers and the method used to weigh responses. “There is no specific threshold which represents rough consensus,” Salowey replied on July 20.
IEEE 802.11, the working group that writes Wi-Fi standards, backed publication in April, and O-RAN’s WG11 did the same in June. In April, 3GPP’s security working group told the IETF that it “continues to require RFCs” as references.
Next steps
After comments close on August 13, the IESG will ballot on the draft. Deb Cooley, the Security Area director responsible for it, will bring it to the IESG. If the IESG approves it, the RFC Editor will prepare it for publication with an RFC number.
Update, November 12, 2026: The IESG approved the draft on September 3, and it entered the RFC Editor queue on September 8. Cooley put the document on hold from September 24 to October 5, writing that “the wg chairs and AD have received complaint/appeals on the processing of this document.” As of November 12, the RFC Editor had not assigned it an RFC number. The hybrid specification was published as RFC 10024 on August 10.
