The IESG should reject solo ML-KEM for TLS and keep the hybrid safety net

The IESG should not bless a downgrade

The IETF has opened last call on a draft that registers pure ML-KEM key agreement for TLS 1.3, and the Internet Engineering Steering Group should let it die there. draft-ietf-tls-mlkem-09 defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as named groups so that a TLS 1.3 handshake can establish keys using nothing but the NIST lattice algorithm, with no classical fallback. Comments are due to [email protected] by 13 August 2026. The right comment is the one Simon Josefsson already sent: reject it.

The case against is not exotic. It is the same argument that is playing out one working group over, on the SSH list, and it is correct in both places. A key exchange that rests on a single post-quantum primitive is a key exchange that fails completely the day that primitive fails. Hybrids do not have that property, and hybrids are what the Internet is already deploying.

Hybrid is not a preference, it is the safety margin

The technical core here is not in dispute, which is exactly why the draft should not advance. As Thomas Bellebaum put it to the IESG, "it is known (and by now machine-verified at a symbolical level) that the widely deployed draft-ietf-tls-ecdhe-mlkem-05 provides some (limited) security even if the ML-KEM implementation is not secure, due to either ongoing cryptanalysis or lack of implementation experience. In contrast, this draft does have no such benefits." Both constructions are secure if ML-KEM is secure. Only one of them is still standing if ML-KEM is not.

That "if" is doing real work. ML-KEM is young. The lattice assumptions underneath it are under active cryptanalysis, and this very month a NIST post-quantum candidate had its security margin cut and its smallest parameter set broken end to end. The implementations are younger still, and a single decapsulation bug in a widely shipped library is exactly the kind of failure a hybrid absorbs and a solo scheme does not. Pairing ML-KEM with elliptic-curve Diffie-Hellman costs a few hundred bytes and a rounding error's worth of CPU. In exchange it buys the guarantee that a break in the new, less-tested half of the handshake does not hand an attacker the session. That is not caution for its own sake. It is the entire reason the hybrid drafts exist and the reason browsers and servers already run them.

The one honest limit on the hybrid case is worth stating plainly, because Bellebaum stated it: the ECDHE half is itself breakable by a future quantum computer, so a hybrid is "helpful for communication which is most vulnerable at present, yet vulnerable to store-now-decrypt-later once a quantum computer can break it." True. But that is an argument for making ML-KEM strong and keeping the classical layer, not for throwing the classical layer away today while ML-KEM is at its least proven.

Publishing this buys nothing and risks something

Here is the part that should settle it for the IESG. Standardizing pure ML-KEM as an RFC does not unlock any capability that is missing today. As Josefsson noted, "IANA codepoints have already been allocated so implementations do not need this document." Anyone who wants to send solo ML-KEM in TLS can already do it. The registry entries exist. The only thing the RFC adds is the IETF's stamp, and that stamp is precisely the thing that turns a discouraged option into a normal one.

Josefsson's warning to the IESG is blunt and, on the merits, right: publishing this "facilitate a non-negligible security risk that non-hybrid ML-KEM is deployed on the Internet and create a risk to users. The risk is easily avoidable by deploying ML-KEM in hybrid mode." He asked the IESG to reject the draft outright, and pointed out that if the authors want a document badly enough there is an Independent Stream for it: "This document do not have to be an IETF stream output, and I believe it will reflect badly on the IETF to publish this document."

There is also a process failure sitting in plain sight. Josefsson filed working-group last-call comments asking that the Security Considerations section actually describe the danger of running ML-KEM with no fallback. "None have been aded, in conflict with best practices around Security Considerations," he wrote. A document whose entire controversy is a security regression, and whose Security Considerations section declines to say so, is not ready to be an RFC. When Paul Hoffman asked Josefsson to supply exact replacement text, the request was fair, and Josefsson should write it. But the burden is backwards: a draft this contested should have carried an honest risk section into last call, not waited for its critics to draft one under deadline.

This document did not arrive clean

None of this is happening in a vacuum, and the IESG should not read draft-09 as a fresh, tidy request. This is the latest stage of a fight freenode has been covering for weeks. Across draft-ietf-tls-mlkem-05, -07, and -08 the working group split over whether an RFC for standalone post-quantum key establishment was necessary plumbing or a dangerous signal, and on 19 July 2026 the chairs found rough consensus to advance it anyway. That consensus call is itself contested. After citing a roughly seven-in-ten figure among pre-existing participants, the chairs declined to release the numbers, weights, or methods behind it even when the European Commission's post-quantum lead asked for them. A rough-consensus determination that cannot be shown is difficult to check, and this one now underwrites a document at IETF-wide last call.

The handling of the critics was worse than opaque. While the draft moved through its working-group last call, the chairs repeatedly moderated the draft's most rigorous opponent, D. J. Bernstein, over a copyright-protest footnote he appended to his messages, a pattern we documented at the time and one that has since escalated into a formal RFC 2026 complaint against the SSH chairs running the parallel signature fight. Separately, a straightforward question about whether a long-career former NSA cryptographer serving as Security Area Director can neutrally steward pure-ML-KEM standardization was met mostly with character defenses and a chair's moderation warning rather than a structural answer. A reader does not have to accept every objection to notice the shape of it: at each step where the process was supposed to absorb dissent, it moderated the dissenter instead.

This is also the second time freenode has argued the substance. When the SSH working group opened its own call for adoption of solo ML-DSA, the case here was the same one: keep the classical layer, because a cheap ECC hedge removes an entire class of failure. The venue has changed from signatures to key agreement and from the SSH list to the TLS and last-call lists, but the mistake on offer is identical, and so is the fix.

"WGLC successful" is not the whole story

The steering group is being asked to read this as a document that cleared its working group cleanly. It did not, and Bellebaum did the IESG the service of saying so on the record. "A simple 'WGLC successful' is insufficient to summarize the temperature on the mailing list," he wrote. Participation "has seen many proponents as well as many opponents." Discussion "were insufficient to reach any wide-arching consensus, to the point where the people 'in the rough' make up a sizable portion of people responding." When the rough is that large, and the split is not over a detail but over "whether this draft represents a security regression," the consensus that RFC publication is supposed to represent is not there.

To be fair to the other side, the draft has genuine backers. Russ Housley told the IESG, "I have read this document, and I support publication as an Informational RFC," and Bellebaum acknowledged that solo ML-KEM "has received substantial backing by people willing to implement it if (and sometimes only if) it becomes an RFC." But read that last clause again. The support is conditional on the RFC, and the fear on the other side is conditional on the same RFC, because the stamp is what drives deployment. That is not an argument for publishing. It is a description of why publishing is the risky act.

The ask

The IESG has an easy and defensible path. The code points exist for anyone with a real need. The hybrid drafts are deployed, understood, and safe against exactly the failure mode that keeps cryptographers up at night. Nothing is lost by declining to elevate a solo-PQ profile that a large minority of the working group considers a step backward, and something real is risked by blessing it. Before 13 August, the steering group should do what Josefsson asked and what the record supports: reject draft-ietf-tls-mlkem, or at the very least refuse to advance it until its Security Considerations tell users the truth, which is that they are safer with a hybrid.