ML KEM, the U.S. post quantum encryption standard, was preferred by cryptographers to ship in TLS, the encryption protocol that secures web traffic, alongside a classical key exchange method. NSA preferred ML KEM alone.
NSA's preferred path for adding post-quantum cryptography to TLS, the encryption protocol that secures web traffic, lost a working-group vote at the IETF earlier in 2026. Weeks later, the same path won a re-vote after a run of newly subscribed list voices cast yes votes. The reversal is the story: what was framed in the technical debate as a settled loss for the standalone-ML-KEM design has become, in a single month, a procedural win for it.
The contest is over how to add Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), the National Institute of Standards and Technology's primary post-quantum key-exchange standard finalized as FIPS 203 in 2024, to the TLS handshake. Cryptographers who have worked on the protocol for years have converged on a hybrid construction that pairs ML-KEM with the existing elliptic-curve Diffie-Hellman exchange (ECDHE), on the grounds that combining classical and post-quantum primitives hedges against the unknown unknowns of an algorithm that has only been studied intensively since the NIST selections in 2022. The IETF is now considering two competing drafts: a hybrid version that runs ECDHE and ML-KEM in parallel, and a standalone ML-KEM draft that drops the classical component.
According to a tally maintained by cryptographer Daniel J. Bernstein on his votes page, which he cross-references against the IETF's public mail archive, the working group's first consensus call lined up behind the conservative hybrid approach. NSA's preferred standalone draft lost. A second working-group ballot was opened and closed on 24 June 2026. This time, the standalone draft pulled ahead, with the swing coming from voters whose first messages to the working-group list postdate the previous ballot, according to the action page's record.
One of those voters was Mike Jenkins, writing from the cyber.nsa.gov domain. His first message to the TLS working-group list is recent, according to the same source. IETF rules permit anyone to subscribe and vote, so the participation itself is procedurally clean. The pattern, however, is what an activist call-to-action page assembled by Bernstein and several co-signers characterizes as room-packing: a small number of first-time list voices, several from .gov addresses, weighing in at decisive moments. A Hacker News discussion of the action page notes that the more obvious NSA attribution is often absent, with most pro-standalone voices using personal or academic addresses, which is itself part of the coordination critique.
The public opposition is far more legible than the support. As of 1 July 2026, more than 30 named cryptographers have filed objection messages on the TLS working-group list, according to the action page's running tally, which links each entry to the underlying mail archive. The roster includes Christian Grothoff, Orr Dunkelman, Simon Josefsson, Yaakov Stein, Peter Gutmann, David Stainton, Stephan Neuhaus, Tanja Lange, and Bertrand Jacquin. Several of them have published technical critiques of dropping the classical ECDHE component. A TechTimes article from the same week takes the same side, arguing under the headline "ML-KEM Security Gaps Demand Hybrid TLS."
The substantive critique, in their telling, is that ML-KEM is a young primitive. Its security rests on module-lattice problems that have been studied intensely since 2022 but have not yet weathered the long-tail cryptanalysis that classical elliptic-curve methods have. Sophie Schmieg of Google's security team, in an ML-KEM mythbusting post from November 2025, walks through several of the most common objections to deploying the algorithm and argues that hybrid use is the responsible default for new deployments. Filippo Valsorda, who maintains cryptography libraries used across the Go ecosystem, frames the urgency in the other direction in his CRQC timeline analysis: the migration window before a cryptographically relevant quantum computer can break classical TLS is short enough that whatever ships first is what the internet will live with for a decade or more. Both positions, in other words, end up at the same place: deploy ML-KEM, but deploy it inside a hybrid.
The proponent arguments have moved with the politics. Earlier in the process, pro-standalone voices cited NSA's preference as a reason to standardize, a posture that drew immediate pushback from critics on the working-group list pointing to the agency's post-Snowden record of attempting to weaken public cryptography as reason to treat that preference as a warning sign rather than a vote of confidence. More recently, the talking points have shifted to technical objections: that no production code exists for the ECDHE hybrid variant, that running two key exchanges simultaneously costs too much, that the standards text is already too complex. Critics on the Hacker News thread describe this evolution as the talking points catching up to the political constraints rather than to the underlying engineering.
Two procedural items now loom. The IETF TLS working group's last call on the standalone ML-KEM draft closes on 8 July 2026. After that, the Internet Engineering Steering Group (IESG) will decide whether the document advances toward an RFC. Separately, Bernstein has an open IESG appeals artifact on file at the IETF datatracker, the formal channel for challenging working-group decisions, and the action page is collecting real-name opposition mail to be sent before the deadline. The substantive cryptographer objections are visible in the working-group archive. Whether the procedural majority that flipped the re-vote reflects the same constituency is the part the public record still does not show.