Bernstein documents 75 objections the IESG cannot edit away

On 11 August, D. J. Bernstein did the IESG's job for it. In a deliberately structured series of four messages to the IETF last-call list and the TLS working group list, he compiled, quoted, and sourced the opposition to draft-ietf-tls-mlkem, the document that would bless solo ML-KEM key exchange for TLS 1.3 without a classical companion. He then filed a cost-benefit rebuttal, reported that the last-call moderators appear to have blocked the whole series from the very list the IESG opened for comment, and demanded that the chairs publish the record they filed in secret. Taken together, it is the most complete case anyone has put in front of the IESG on this document. The IESG should treat it as decisive.

Seventy-five objections that no edit can fix

Bernstein's central claim is a counting claim, and he built it to survive every attack he could anticipate. He states that 82 people registered "unambiguous, non-withdrawn opposition" to the document during the most recent working group last call, "the third WGLC after two admitted failures." He then narrows that number to 75, quotes one line from each of those 75 objectors, and links an archived copy of every original message so the quotes can be checked in context.

The narrowing is the point. He excluded opposition that arrived before the third last call, opposition sent to other venues, and opposition that the chairs blocked, "in the interests of avoiding any accusations that the quotes overstate the level of opposition." He excluded people whose objections were real but phrased ambiguously. What is left is 75 people who said no, on the record, on the list, during the official window, in language that cannot be read any other way.

And the objections are not editorial. Bernstein writes that he "checked that none of those messages suggest any possibility that document modifications can remove these objections." That is the difference between a document that needs another revision and a document that should not exist. You cannot copy-edit your way out of "do not standardize this." As Izzy Grosof put it before the last call even opened, "The performance improvements of a non-hybrid approach are trifling; the security risks are immense ... Do not endorse or standardize any non-hybrid post-quantum cryptosystem, via this document or any other."

The process that produced the "consensus"

The second message turns to how the chairs manufactured a rough-consensus call out of that pile of objections, and the account is damning if accurate. Bernstein reports that the chairs told participants to restrict themselves to "I support" or "I do not support," and scolded those who explained their reasoning. He then quotes the chairs claiming that "roughly 7/10 WG participants favor advancing the document" only after they had "focused their consensus judgement on people that participated in TLS prior to the last WGLC."

That is not a consensus measurement. That is a denominator chosen after the fact. If you first tell objectors to stop talking, then discard the ones who are not "pre-existing WG participants" or have not "demonstrated expertise," you can produce any ratio you like. Bernstein's request to the IESG is exactly the right one: state, for the record, what weight each of the 75 objectors is being given, and answer each substantive objection individually, "following the rule" that every legitimate standards body records an official response to each objection. He has signaled he will file a formal complaint under RFC 2026 on the consensus claim once he finishes documenting it.

Then the last-call list ate the evidence

The most serious allegation is procedural. Bernstein reports that his four messages "appeared promptly on tls@ietf.org but not on last-call@ietf.org," and he published timestamped archive links to prove it. If the moderators of the IESG's own limited-time comment process blocked the most thorough opposition filing during the window that opposition was solicited, the last call was not a last call. It was theater. Bernstein's dry question deserves an answer from the IESG directly: "I wonder how many more community inputs the last-call@ietf.org censors have been blocking."

His follow-up on 12 August closes the loop on transparency. The shepherd writeup says that "Details regarding past appeals and mailing list conflicts will be emailed directly to the responsible AD," off the public record. Bernstein argues this violates RFC 2026's requirement of publicly accessible records of contributions pertaining to standards activity, and asks the chairs, the area directors, and the IESG each to post what was filed. A document being pushed over documented objection is not the moment to move the paper trail into private mail.

The engineering case has not moved

Under all the process, the technical argument is unchanged and it favors hybrids. Bernstein's fourth message walks through the proponents' strongest posts and shows they mostly attack a position nobody holds. To the repeated claim that hybrid defenders are pretending classical crypto never fails, he answers plainly: "Nobody is claiming that ECC always saves the day. We're just saying that using ECC+PQ instead of solo PQ reduces the damage in case of security failures in the PQ part." To the seatbelt-in-a-trustworthy-car analogy, he answers that we hope ML-KEM adds protection against quantum computers, but "in case of security failures in the ML-KEM spec or ML-KEM software, we continue also using ECC, instead of throwing ECC away."

The most striking citation is not Bernstein's own. He quotes Roberto Avanzi, a co-designer of Kyber, the scheme standardized as ML-KEM, saying: "as a codesigner of ML-KEM myself I would not trust using it exclusively: what if it gets broken mathematically and in the classical computational model (i.e. non-quantum)? Hybrid is better, and the additional time used by ECC is not significant." When one of the people who built the algorithm says he would not deploy it alone, the burden is on the people standardizing the solo mode, not on the people asking for a seatbelt.

The math is not close

Finally, the cost-benefit filing dispatches the efficiency argument on its own terms. Bernstein reports that economist Paul Romer estimated the savings from replacing X25519 plus ML-KEM with solo ML-KEM at 2.9 nanodollars per connection, against a security cost of "at least" 270,000 nanodollars per connection. In Bernstein's words, that "makes draft-ietf-tls-mlkem look like a stunningly bad idea, unless his numbers are off by five orders of magnitude." He then notes the savings figure is if anything overstated, because it counts CPU time but ignores communication costs, which for X25519 "can easily add 4 nanodollars per connection." The entire performance case for dropping the classical layer is a rounding error, and it is being traded for a catastrophic tail risk.

What the IESG should do

Bernstein handed the IESG a finished record: 75 sourced objections it cannot dissolve with an edit, a consensus call built on a denominator picked after the objections came in, evidence that the comment list suppressed the filing, a co-designer of the algorithm on record against solo use, and a cost-benefit gap of five orders of magnitude. He did it, by his own repeated statement, without any use of language models, precisely so the record would be accurate and checkable.

freenode has followed this saga from the moderation of Bernstein over a copyright footnote, through his formal complaint against chairs who tried to silence him on a related list, to our own argument that the IESG should keep the classical layer. This filing is the case, assembled and sourced, in one place. There is one correct response to it. Do not publish draft-ietf-tls-mlkem. Keep the hybrid.