TLS chairs refuse to release the weighting behind a contested ML-KEM consensus call

On 19 July 2026, days after Working Group Last Call closed on draft-ietf-tls-mlkem-08, TLS co-chair Joseph Salowey declared rough consensus to advance the document. His announcement did more than assert a lean of the list. It offered a specific arithmetic claim about who counted and how.

"By pure numbers, more people want to progress the document than not, but this alone does not constitute rough consensus. However, if we look at pre-existing WG participants or people with demonstrated expertise, roughly 7/10 WG participants favor advancing the document, which shows rough consensus to move the document forward," Salowey wrote. He attributed a surge of newer voices during the call to "extensive social media coverage."

The same day, Fabiana Da Pieve, Team Leader Post-Quantum Cryptography at the European Commission (DG CNECT, Unit C4), asked the chairs to show the work behind that claim.

"Can I kindly ask if there is evidence that can be provided for your statements about the numbers, and more info on the weights / method you apply to weigh answers, from both sides? I imagine you have a table/a scheme/something, with participants, an established method for the weights, weights associated to each person on both sides, other elements you may have considered relevant...."

On 20 July 2026, Salowey answered with a firm refusal.

"As others have mentioned on this thread, a consensus call is not a vote. We used public responses to get a sense of where the mailing list participants are leaning... The chairs have the remit to judge consensus based on input such as taking into account the level of previous participation of the sender. There is no specific threshold which represents rough consensus... All of the mail used as part of this process is publicly available. We do not intend to release any further detailed analysis including 'numbers' or 'weights/methods'."

What "rough consensus" is, and what it is not

At the IETF, rough consensus is deliberately not a headcount. Chairs are expected to weigh technical arguments, experience, and the quality of objections rather than tally ballots. There is no fixed numeric threshold. That doctrine, long reflected in working-group practice and in guidance such as RFC 7282, exists precisely so that a loud minority or a sudden influx of newcomers cannot steamroll a group, and so that silent assent is not mistaken for a veto either.

None of that fully answers Da Pieve's request. Salowey did not merely say the chairs had a qualitative sense of the room. He published a concrete ratio, "roughly 7/10," limited to "pre-existing WG participants or people with demonstrated expertise," and he used that ratio as the visible proof that rough consensus existed. Once chairs put a weighted fraction on the record as the basis for advancement, asking for the classification rules, the participant set, and the weights is not the same as demanding a vote. It is asking how the non-vote judgment was performed.

Pointing only to the public mailing-list archive, as list participant Dennis Jackson did the same day, supplies the raw input. It does not disclose the chairs' scheme for sorting "pre-existing" from social-media-driven participants, nor the weights applied "from both sides," which is what Da Pieve explicitly requested.

Repeated requests, still no methodology

Ken Kubota, an objector on the list, pressed immediately after the refusal.

"I am writing to clarify the statement in your email regarding the statistic '7/10 WG participants favor advancing the document.' Transparency is a core principle of the IETF. Please provide the breakdown or data that supports this figure."

Jackson replied by directing requesters to the public TLS archive and bulk rsync extracts. That deflection left the central gap untouched: the archive shows who wrote what; it does not show how the chairs turned those messages into 7/10.

The transparency concern was sharpened, in Kubota's earlier note, by "the presence of a double-digit number of identified intelligence agency operatives" among participants. Whatever one makes of that roster, a contested re-weighting toward "pre-existing" and "demonstrated expertise" is exactly the kind of judgment that benefits from a published method rather than an assertion of chair remit alone.

Even a draft opponent called the refusal a legitimacy problem

Nadim Kobeissi, a declared opponent of publishing pure ML-KEM on technical grounds, did not treat the process question as optional. On 22 July 2026 he argued that the chairs needed to answer Da Pieve on the merits of process, not only of cryptography.

"I think that a very reasonable way to do this would be to substantively address Fabiana's questions not only because they're fair questions to ask especially given the (perhaps unprecedented) controversy regarding this WGLC, but also given the privileged responsibilities that her position gives her here in the EU where myself and a lot of other TLS stakeholders are based. In this vein, refusing to answer Fabiana's questions is a mistake, further disenfranchises list participants, and risks eroding the confidence that many of us have in the functioning of this list."

That intervention matters because it separates substance from procedure. One can oppose the draft and still hold that a consensus call built on an unpublished 7/10 re-weighting owes the list a reproducible account of how the weighting was done.

Earlier process friction had already put pressure on how "participant" was defined. Cryptographer Tanja Lange had objected to silent-assent framing: "I very much dislike this definition of "participant" and the assumption that those who don't speak up are in agreement." When chairs later elevate "pre-existing WG participants" into a 7/10 statistic while declining to publish the table, that older unease about who counts becomes harder to dismiss as pedantry.

Status of the document, and what remains closed

As of the record, pure ML-KEM under draft-ietf-tls-mlkem-08 sits as RECOMMENDED=N on a non-standards-track informational document, while hybrid X25519MLKEM768 is RECOMMENDED=Y on a standards-track document. The chairs indicated they would address several issues raised in the call but "do not intend to make significant changes" to the draft itself.

Open questions therefore sit squarely on process, not on a re-run of the pure-versus-hybrid technical debate. What exact participant list and per-person weights produced the 7/10 figure? What established method classified pre-existing expertise versus newer voices? And will the chairs ever release further detailed analysis after on-list requests from Da Pieve, Kubota, and others?

Rough consensus is not a vote. That sentence is correct as far as it goes. It does not, by itself, explain why a public ratio used to justify advancement must remain unaccompanied by the weights and methods that generated it. In a working group whose output underpins TLS for the global Internet, and at a moment the chairs themselves called unusually noisy, the refusal to show the arithmetic is the story the list has left on the record.