Skip to main content

March 03, 2026

The Rush toward Post-Quantum TLS: A critical Analysis of the IETF Standardization Process

02 February, 2021

Background: What is ML-KEM and why is it important?

With the growing threat posed by quantum computers, the cryptography community has been working intensively in recent years on so-called post-quantum cryptosystems (PQC)—algorithms that remain secure even against attacks by quantum computers. In 2024, NIST published one of the first official PQC standards with ML-KEM (Module-Lattice-based Key Encapsulation Mechanism, standardized as FIPS 203, also known by the project name CRYSTALS-Kyber).

At the same time, the IETF TLS Working Group is working to integrate ML-KEM into TLS—the protocol that ensures the security of the vast majority of encrypted internet traffic.

This is precisely where the controversy begins.


The current Debate: Hybrid vs. Pure PQC

At the heart of the debate lies a fundamental security decision:

Hybrid schemes combine classical algorithms (e.g., ECDH with P-256 or X25519) with a PQC scheme such as ML-KEM. This means that an attacker would have to break both schemes simultaneously to compromise the communication.

Pure PQC schemes (also known as standalone PQC) completely dispense with the classical component and rely exclusively on ML-KEM. This is the approach taken by the controversial draft draft-ietf-tls-mlkem. – see https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/

The question is not merely academic: If ML-KEM proves to be vulnerable in practice—whether due to mathematical weaknesses, implementation errors, or future attacks—a hybrid scheme still offers the protection of the classical algorithm. A pure PQC scheme, on the other hand, fails completely.


D. J. Bernstein’s Complaint: A procedural Failure in three Acts

On February 20, 2026, Daniel J. Bernstein, one of the world’s most prominent cryptographers and the author of algorithms such as Curve25519 and ChaCha20, filed a formal complaint against the TLS Working Group Chairs in accordance with RFC 2026, Section 6.5.1. The complaint documents three separate but mutually reinforcing procedural errors.

Issue 1: Invalid second Working Group Last Call

In November 2025, draft-ietf-tls-mlkem-05 underwent a regular Working Group Last Call (WGLC)—the formal process by which the WG determines whether there is consensus to publish a draft. The result was clear: At least eight WG participants raised substantial objections, including renowned experts such as Benjamin Kaduk (former IETF Security Area Director), Watson Ladd, Simon Josefsson, and Stephen Farrell. The Chairs themselves correctly stated: “we do not have consensus to publish the document as is.

Three months later, in February 2026, the same Chairs initiated a second WGLC for draft-ietf-tls-mlkem-07. The problem: The revisions from -05 to -07 are minimal. The motivation remains limited to a single short paragraph. There is still no concrete reference to the alleged regulatory requirements that supposedly mandate a pure PQC scheme. The central security argument—why an unnecessary security risk should be taken—remains completely unanswered.

A second WGLC is not illegitimate in and of itself. The problem lies in the implicit message: a new Last Call signals that the earlier objections have been addressed. That is simply not the case here.

Problem 2: Limitations of the consensus-building Process

The second WGLC included the following wording: “The main focus of this WGLC is to review new text providing more context around the use of pure ML-KEM.” Taken in isolation, this may sound harmless—but the responsible Area Director, Paul Wouters, significantly tightened this restriction in a later message by explicitly limiting the goal of the second WGLC to the evaluation of the new text.

The consequence: WG participants who have fundamental objections to the pure PQC concept—that is, to the core of the document—are effectively discouraged from raising them again. This corrupts the consensus-building process: consensus cannot be established if parts of the spectrum of opinion are systematically ignored.

Despite this restriction, eight or more participants once again spoke up with clear objections, including new voices such as Izzy Grosof and Nadim Kobeissi.

Problem 3: Retrospective Reinterpretation of a failed WGLC

The third issue is particularly serious: In his message, AD Wouters claimed that the first WGLC in November 2025 had passed—on the condition that a clarifying text regarding the preference for hybrid procedures in general cases be added. This account directly contradicts the official summary by the Chairs, who had unequivocally noted the lack of consensus.

This approach violates a fundamental principle of the IETF process: one cannot establish consensus for Action X and subsequently reinterpret it as consensus for Action Y without reconvening the WG. The legitimacy of the entire process depends on decisions being communicated transparently and not reinterpreted after the fact.


Technical Analysis: Why the Critics are right

The objections to draft-ietf-tls-mlkem are not of a bureaucratic nature—they are technically sound.

ML-KEM is new and has not been sufficiently analyzed

Although the NIST standardization process was thorough, ML-KEM is significantly younger than established schemes such as ECDH. The cryptography community has not yet invested the same amount of analysis time and resources. In the history of cryptography, even carefully analyzed algorithms have revealed weaknesses years later.

Hybrid schemes are already available and sufficient

X25519MLKEM768 may not yet be officially standardized, but it is already in widespread use. It offers the same quantum resistance as a pure ML-KEM but adds a robust fallback. There is no discernible disadvantage of hybrid schemes over pure PQC schemes in TLS—the overhead is minimal and acceptable.

The claimed regulatory necessity is unsubstantiated

The only justification for a pure PQC scheme would be regulations that explicitly prohibit classical algorithms. Such regulations do not currently exist to any significant extent, and the document does not cite a single concrete reference. This gap is a central point of criticism that has not been addressed by the revisions.

The principle of minimal attack surface

Good security engineering follows the principle of avoiding unnecessary risks. Standardizing a pure PQC-TLS when hybrid approaches achieve the same goals with a higher margin of security fundamentally contradicts this principle. It is not the role of a standard to conduct unnecessary experiments with security levels.


The Fundamental Question: The Trustworthiness of the IETF Process

What makes this complaint particularly significant is that it looks beyond the specific document. Bernstein and the other critics implicitly raise a broader question: Can the IETF process be considered trustworthy if procedural errors of this kind are possible?

The IETF operates on the principle of rough consensus—not through formal voting, but through careful consideration of the technical arguments of all participants. This process only works if the chairs and area directors moderate neutrally and apply the rules consistently. However, when objections are ignored, WGLC outcomes are redefined, and the space for discourse is restricted, this undermines the foundation upon which the authority of IETF standards rests.

A standard adopted through a compromised process has a legitimacy problem—regardless of its technical merits or shortcomings.


This article is based on the complaint filed by D. J. Bernstein on February 20, 2026, as well as publicly available discussions on the IETF TLS Working Group mailing list.

The assessments contained herein reflect the analysis of White Rabbit Security.

Links:

https://mailarchive.ietf.org/arch/msg/ietf/PStIAGIP2gbTNUPrr3t2jUjnS6g/

https://mailarchive.ietf.org/arch/browse/tls/?gbt=1&index=USZ5L3z4g667iV4L5ZiuTcQGijI

Contact

  • Werner-Heisenberg-Str. 8
  • 85254 Sulzemoos, Germany
  • This email address is being protected from spambots. You need JavaScript enabled to view it.

© Whiterabbitsecurity