July 30, 2026 — The IESG issued an IETF-wide Last Call for draft-ietf-tls-mlkem, the specification that defines pure ML-KEM-512, ML-KEM-768, and ML-KEM-1024 NamedGroups for key establishment in TLS 1.3. Final comments are due by August 13, and the IESG says it plans to make a decision in the next few weeks. The intended status is Informational RFC.
Bottom line: standalone ML-KEM key establishment for TLS 1.3 is one IESG decision away from an RFC. If it publishes, procurement regimes that demand a standalone option get their stable reference, while the IANA registry keeps pointing everyone else to hybrid.
The Last Call caps a dispute that produced three Working Group Last Calls and a string of appeals. The first WGLC ended in December 2025 with the chairs finding no consensus to publish. On July 19, TLS working group co-chair Joseph Salowey declared rough consensus to advance the draft, closing the third WGLC, which ran June 24 to July 8. By raw numbers, more respondents supported publication than opposed it, though Salowey wrote that raw counts alone do not establish rough consensus. Among pre-existing participants and people with demonstrated expertise, the chairs put support at “roughly 7/10.” Sustained opposition came from cryptographers including Nadim Kobeissi, whose blocking objection centered on compositional security, Tanja Lange, who wrote on July 6 that none of her concerns had been addressed and that she does not support publication, and Daniel J. Bernstein, who has fought the document since its adoption. Not every earlier critic stayed opposed: Muhammad Usama Sardar, who had pressed for a formal-analysis report in previous rounds, wrote that draft-08 resolved his technical objections and recorded no opinion on publication.
At issue is what fails together. The hybrid X25519MLKEM768 group, which the working group separately placed on the standards track with a Recommended=Y registry marking, keeps a recorded session confidential even if one of its two components later fails. The pure groups in this draft rest confidentiality entirely on ML-KEM, the lattice scheme NIST standardized as FIPS 203 in August 2024, and they are marked Recommended=N in an Informational document.
The counting drew its own challenge. Hours after the determination, Fabiana Da Pieve, Team Leader for Post-Quantum Cryptography at the European Commission’s DG CNECT, asked the chairs on the record for the numbers behind the call and the method used to weigh responses from both sides. Salowey replied on July 20: the mail is public, no specific threshold defines rough consensus, and the chairs “do not intend to release any further detailed analysis” of numbers, weights, or methods.
Draft-09, posted July 20, contains the two changes the chairs committed to. They added RFC 9847’s definition of the N marking to the IANA section, so readers see that N means the IETF has made no statement about the mechanism’s suitability. They also inserted new randomness text into the security considerations, responding to Jacob Appelbaum’s observation that ML-KEM’s m value exposes raw random-generator output to the peer, with a citation to the Checkoway et al. analysis of Dual EC exploitation in TLS. Salowey requested publication on July 28.
The demand side is on the record too. O-RAN and IEEE 802.11 filed liaison statements supporting publication, 3GPP asked for stable references for its post-quantum work, and the chairs cited all three as evidence that downstream standards bodies need a stable normative reference. A third-party IPR disclosure filed by Simon Josefsson, identifying patents that may relate to ML-KEM, remains attached to the document.
Appeals have followed this document at every stage. Bernstein has challenged its progress before both the IESG and the IAB: the IESG answered one appeal in October 2025, the IAB answered another in January 2026, and the IAB denied the most recent on June 30. As of August 1, no appeal targets the July 19 consensus determination itself. The comment window closes August 13.
My Analysis
The fight over pure versus hybrid ML-KEM comes down to who absorbs the loss if ML-KEM turns out to have an undiscovered weakness. Hybrid answers: nobody, because an attacker who records a session must later break both the classical and the post-quantum component to read it. Pure answers: the lattice scheme carries the load alone, and buyers get a smaller handshake that runs one key-establishment primitive instead of two, a cleaner fit for procurement profiles that prescribe standalone ML-KEM. Nobody in the objectors’ camp claims ML-KEM is broken today. Their claim is narrower and harder to dismiss: shipping an option that drops the second layer of defense in the internet’s default encryption protocol is a bet nobody forced the industry to make. Since harvest-now-decrypt-later adversaries are recording TLS sessions today, the consequences of that bet are retroactive: a break that lets an attacker recover shared secrets from recorded handshakes would expose every pure-ML-KEM session captured since deployment, all at once. I take the objection seriously, and one detail from the record sharpens it: the chairs’ case for holding a third Last Call cited Kobeissi’s updated ProVerif model of TLS 1.3, which they said supports results showing hybrid groups stay secure even when one component is compromised. That is the property a pure deployment gives up, offered as reassurance by the people advancing the pure option.
On the merits, the working group reached a defensible answer. The standalone code points already sit in the IANA registry, with implementations in the wild, whether the IETF blesses them or not; 3GPP and IEEE 802.11 build on IETF references; and an RFC with honest security considerations beats a vacuum filled by vendor documentation. I do not fault the working group for the answer it reached. I fault the counting. The chairs, not the critics, introduced the fraction, and once you publish a number you own the question of how it was produced. Rough consensus has always rested on chair judgment, RFC 7282 says so plainly, and nobody was promised a ballot. What the record lacks is a reproducible account of the judgment: how the expert subset was drawn, and why each principal objection was judged answered rather than blocking. Declaring roughly seven in ten among a chair-selected cohort, then telling a European Commission official in writing that nothing further will be released, is exhibit A for any future appeal. And this document’s own new security-considerations text cites the Dual EC affair, the canonical case of a cryptographic standards process that was gamed. A body that invokes that history in its references owed the public the work behind its number.
The status line is the part of this outcome the headlines will skip. This will be an Informational RFC whose code points are marked Recommended=N in the IANA TLS Supported Groups registry, while hybrid X25519MLKEM768 is on the standards track at Recommended=Y. Read the pair together: the IETF is documenting what it declines to endorse, and the RFC 9847 definition the chairs added to draft-09 states as much, since N means the IETF has made no statement on suitability. Procurement officers tend to read “RFC” and stop. Auditors and architects should read the registry instead, because the registry is where the IETF recorded its preference. Lange’s objection anticipated this exact failure mode: readers will treat an RFC as an IETF endorsement no matter which letter the registry column shows. The contrast with the IETF’s other recent post-quantum output makes the same point from the opposite direction: RFC 9980 made lattice cryptography hybrid-only in OpenPGP. TLS is getting a standalone option with no recommendation attached.
For practitioners, the calendar has its own logic, and the deadlines are already set by regulators and procurement rules that do not pause for IETF appeals. My guidance is unchanged from my May analysis of the hybrid-versus-pure split: keep hybrid as the default wherever confidentiality must outlive the connection under the NIST PQC standards, build the crypto-agility to flip modes per deployment environment, and treat pure ML-KEM as a compliance profile for CNSA 2.0-style regimes that prescribe it, once the RFC ships. Two dates anchor the near term. Final comments are due August 13, two years to the day after NIST published FIPS 203 (a coincidence of calendars, but a tidy one), and organizations with a stake in this outcome still have that window. After it closes, the IESG decides, and the objectors decide whether to appeal. There is history.
