This message is in response to the draft-ietf-tls-mlkem last call, but
it's also a complaint to the TLS WG chairs regarding their 28 Apr 2026
16:24:37 -0400 declaration of consensus to publish draft-ietf-tls-mldsa.
This is on different grounds from my previous, still active, complaint
about that declaration. I'll explain the complaint status below, but
I'll start by explaining the main content shared by my response to the
last call and by my new complaint; this large overlap is the reason that
I'm filing this as a single message instead of two messages.
1. Security damage of solo PQ
Deployment of draft-ietf-tls-mlkem and/or draft-ietf-tls-mldsa means two
things:
(1) Throw away the protection provided by the status quo. I'll focus
on ECC as the typical status quo for concreteness, but the exact
choice has only minor effects below.
(2) As something that's _claimed_ to provide more protection, roll
out ML-KEM and/or ML-DSA.
But let's look at whether this claim is actually true.
I have a new paper this month that presents fast exploit scripts for
some ML-DSA bugs; uses standard techniques to predict ML-DSA bug rates
starting from ML-DSA code sizes and https://arxiv.org/abs/2107.04940;
uses known ML-DSA bugs such as https://eprint.iacr.org/2026/1032 and
ML-DSA CVEs as sanity checks; and quantifies the security damage of
rolling out solo ML-DSA. The following graph summarizes the damage:
https://cr.yp.to/papers/mldsa-20260601.pdf#breakable-keys
The TLS part of the damage will be millions of breakable ML-DSA keys in
2027, millions of breakable ML-DSA keys in 2028, etc. Even years after
the first secret quantum attacks begin (I was already on record in 2023
with a median estimate of 2029 for that), there will be many more ML-DSA
keys broken because of software vulnerabilities than ECC signature keys
broken because of quantum attacks _plus_ software vulnerabilities.
It's not hard to carry out a similar analysis for ML-KEM. The code is
noticeably smaller for ML-KEM than for ML-DSA and not quite as new on
average, so the vulnerability rates per ML-KEM implementation will be
lower, but this is outweighed by the fact that there will be many more
total ML-KEM keys in TLS than total ML-DSA keys, making quantum attacks
an even smaller part of the overall attack picture.
To summarize, using draft-ietf-tls-mlkem and/or draft-ietf-tls-mldsa
will be an unmitigated security disaster. Let me emphasize that this is
simply accounting for the predictable impact of bugs, never mind timing
attacks (see, e.g., https://cr.yp.to/papers.html#kyberslash), never mind
the risk of breaks of the _specs_ of ML-KEM and ML-DSA.
2. Mitigation: ECC+PQ
The well-known, widely deployed, common-sense mitigation for failures of
PQ security is to preserve the existing ECC layer as part of ECC+PQ: for
example, continue signing with ECC as part of ECC+PQ double signatures,
and similarly for encryption. (Typically ECC+PQ is called a "hybrid",
although that name often confuses people.) There are many detailed
ECC+PQ examples, including specs that do the job for TLS, namely
draft-ietf-tls-ecdhe-mlkem and draft-reddy-tls-composite-mldsa.
ECC+PQ has negligible cost beyond solo PQ. The complexity and risks of
software engineering and testing are almost entirely inside the ECC code
(which was there already) and the much newer PQ code (for code sizes
see, e.g., https://cr.yp.to/papers/pqcomplexity-20240419.pdf regarding
ML-KEM and https://cr.yp.to/papers/mldsa-20260601.pdf regarding ML-DSA),
not the combiner code. Sure, combiner code can have bugs too, but adding
that code is mitigation against bugs in much more complicated code for
ML-KEM and ML-DSA, so it would make absolutely no sense to wave at the
combiner complexity as a reason to avoid this mitigation.
To be clear, having less code _tends_ to be good. But this has many
exceptions. Arguing for less code isn't a valid argument to throw away
test code, or to downgrade to the null cipher, or to use solo PQ rather
than ECC+PQ. ECC+PQ is safer than solo PQ.
Quantification of bug rates and exploitation costs in the case of ML-DSA
is new to my paper this month, but qualitatively the advantage of ECC+PQ
is something I pointed out much earlier. For example,
https://cr.yp.to/talks.html#2016.02.24
recommends ECC+PQ, even (explicitly) for the case of the PQ part being
hash-based signatures. As for software issues,
https://web.archive.org/web/20220308032457/https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/LVpCs_vjMlE/m/M2uQPfaEAQAJ
from 2018 describes NISTPQC as "the largest regression _ever_ in the
quality of cryptographic software" and says this "will not be easy to
fix"; see also
https://cr.yp.to/talks/2018.12.28/slides-dan+tanja-20181228-pqcrypto-16x9.pdf#page.74
for a summary of the software situation. Putting this together,
https://web.archive.org/web/20260603074058/https://mailarchive.ietf.org/arch/msg/spasm/pcISUlnedpExwwLuISP18oR1zxc/
from 2024 emphasizes how the risks of "bugs in post-quantum software"
warrant "a blanket rule of always upgrading from ECC to PQ+ECC, _not_
discarding the ECC layer, even when the PQ layer is SPHINCS+"; and the
same 2024 posting explains the difference between state-of-the-art bug
elimination and what happens in the real world.
3. The actual rationale for solo PQ
In the TLS WG, specs for solo PQ were introduced without any pretense of
an engineering rationale. Instead there were claims that NSA demands
solo PQ and will refuse to authorize government purchases of ECC+PQ
("that's what they're willing to buy. Hence, Cisco will implement it";
"CNSA 2.0 compliance"; etc.).
What I found puzzling about the content of those claims is that they
were, and as far as I know still are, inconsistent with _official_
statements from NSA. For example, an official NSA document
https://web.archive.org/web/20220524232250/https://www.nsa.gov/Portals/75/documents/resources/everyone/csfc/threat-prevention.pdf
describes an NSA program asking for two cryptographic layers "to
mitigate the ability of an adversary to exploit a single cryptographic
implementation". NSA's official post-quantum statements such as
https://web.archive.org/web/20250827175413/https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF
say that "hybrid solutions may be allowed or required due to protocol
standards, product availability, or interoperability requirements".
On the other hand, an NSA employee wrote that NSA is "looking for
products that support /standalone/ ML-DSA-87 and /standalone/
ML-KEM-1024. If there is one vendor that produces one product that
complies, then that is the product that goes on the compliance list and
is approved for use. Our interactions with vendors suggests that this
won't be a problem in most cases."
A defense contractor seeing such statements will of course conclude that
if it doesn't push for solo PQ then it will lose federal contracts
("that's what they're willing to buy. Hence, Cisco will implement it").
So NSA gets to pull the strings here even without taking any official
responsibility for doing so.
4. Subsequent discussion of the specs
Within the TLS WG, more and more objections to solo PQ started piling
up---most importantly to the security damage, but also to procedural
problems such as the lack of an engineering rationale for solo PQ. These
specs were in clear violation of what
https://web.archive.org/web/20250528213926/https://www.ietf.org/blog/ietf-llc-statement-competition-law-issues/
labels as a "fundamental" rule: "IETF participants use their best
engineering judgment to find the best solution for the whole Internet,
not just the best solution for any particular network, technology,
vendor, or user."
Unsurprisingly, the actual story of NSA paying for solo PQ was then
gradually downplayed in favor of other arguments for solo PQ. I've been
maintaining a chart of the arguments and counterarguments, with links to
the original statements:
https://blog.cr.yp.to/20260221-structure.html
This is most recently updated 25 June 2026. (For anyone who sees an
argument not covered there, please let me know.)
It's remarkable that the case for the specs includes statements that
contradict each other. For example, compare the following:
* One vote for allowing solo PQ claimed, as part of denying the
security damage, that solo PQ will be used solely by NSA so any
security problems will be "not impacting anyone else".
* Similarly, another vote for allowing solo PQ claimed that ECC+PQ
"will surely continue to be far more common in practice".
* Similarly, the chairs wrote that there's a "clear community
preference" for ECC+PQ.
* But another vote for allowing solo PQ claimed that "pure-mlkem is
the obviously correct solution if you want high-performance
solutions".
* Another vote for allowing solo PQ emphasized that "we have
implemented this in Chrome".
* Another vote for allowing solo PQ claimed that deploying ECC+PQ
would require a "second large-scale engineering effort to migrate
to pure ML-KEM sometime later" and "would consume literal years of
my life".
Who's the supposed user base for these specs? The answers are absurdly
inconsistent. Someone asking about the purported _advantage_ of solo PQ
over ECC+PQ is treated to wild exaggerations of the cost difference and
to a whac-a-mole game of supposed applications (such as "high-frequency
trading"). Someone asking about the _security damage_ is instead told
that this is just for NSA. C'mon, this doesn't pass the laugh test.
The case for the specs also includes arguments that, because of some
"recommended" entry in the IANA registry, solo PQ won't be used. Huh?
How many purchasing managers ever look at the IANA registry?
The reality is that an RFC will be viewed by typical readers as IETF
endorsement, and will lead to many deployments that wouldn't otherwise
exist. See, e.g.,
https://web.archive.org/web/20260625095524/https://mailarchive.ietf.org/arch/msg/tls/LCtGfIAfsOkuuh5NP7l0wAWUk4A/
saying "I think it's clear that many regard the publication of an RFC by
the TLS WG as a form of endorsement, even when Recommended=N ... I don't
think this position is entirely unreasonable given that the documents
state on the face of them that they 'represent[s] the consensus of the
IETF community.' " Or see
https://web.archive.org/web/20260521112257/https://mailarchive.ietf.org/arch/msg/last-call/mNqIHumBiO2kJMfh7-MBWlVS3xg/
saying that what "largely" matters is whether there's an RFC, not how
the RFC is labeled.
Perhaps most importantly, the case for the specs includes arguments
denying that ECC+PQ is safer than solo PQ:
* There's conflation of spec security with software security (how do
we explain all the bugs and timing attacks, then?), accompanied by
a claim that the ML-KEM and ML-DSA specs were "fully vetted"
during the NIST competition (so eprint papers 2025/1910,
2025/2189, and 2026/279 are all wrong?).
* There's a claim that ML-KEM and ML-DSA will have "exceedingly few
bugs"---but no response to clarification questions asking (1) how
many bugs, (2) where this number is coming from, and (3) how this
is supposed to be an argument for the specs when the same posting
admits that "a single broken key per month can be catastrophic".
* There are some astounding claims that attacks don't matter. For
example, in the case of ML-DSA, we're supposed to believe that
"the blast radius for signatures has a strict end with revocation
of the key". This ignores not just the expense and difficulty of
cleaning up after attacks that are discovered, but also the damage
done by attacks _before_ the attacks are discovered. For example,
NSA said that its QUANTUMINSERT forgery attacks were "highly
successful" starting in 2005; those attacks weren't publicly
detected until the Snowden documents revealed them in 2013.
* There's a claim that ECC is useless. This ignores (1) all of the
available evidence regarding the cost of quantum computation (see
generally https://cr.yp.to/papers/mldsa-20260601.pdf#ecc), (2)
the value of limiting the number of attackers, and (3) the value
of delaying attacks.
* There's a claim that specific ECC+PQ mechanisms proposed for TLS
allow malleability attacks that PQ by itself wouldn't allow. This
claim has been repeatedly debunked, even with a debunking demo in
https://github.com/crypto-security-tools/on-composites-signatures,
and yet the claim continues to be repeated on this mailing list.
RFC 2418 says that disagreements "must be resolved by a process of open
review and discussion". This rule is obviously a big problem for these
specs: the case for the specs is flimsy and cannot survive a resolution
process. Unfortunately, aside from a few minor issues such as the FATT
issue, this resolution process simply hasn't happened for these specs.
What the chairs _should_ be doing is insisting on the specs stating a
coherent, stable rationale that survives scrutiny and reaches consensus.
Instead the chairs are allowing spec proponents to ignore objections;
allowing new arguments for the specs to suddenly appear at the moment of
a limited-time last call; and now trying to terminate the process of
dispute resolution ("Please refrain from further discussion on this
topic"). Sorry, no, RFC 2418 says "must be resolved" and gives chairs no
authority to override this.
5. Response to the last call regarding solo ML-KEM
Regarding the draft-ietf-tls-mlkem last call: I am opposed to any
endorsement of this spec. In particular, I am opposed to the proposal on
the table to issue the spec as an RFC.
6. Status of earlier process complaint regarding solo ML-DSA
RFC 2026, Section 6.5.1, authorizes complaints from someone who
"disagrees with a Working Group recommendation". The RFC distinguishes
two types of complaints handled by this process.
The first type is "a difficulty with Working Group process" where
someone's "views have not been adequately considered by the Working
Group".
In particular, for draft-ietf-tls-mldsa, there were _14 people_ filing
objections before the end of WG last call, with no answer to the most
important objections. The chairs claimed consensus; there were process
complaints regarding that; the chairs insisted that there was consensus.
I escalated to the ADs. This is _not_ part of what I'm now filing a
complaint about; I'm just reviewing it to clearly distinguish it from
what I _am_ now filing a complaint about.
7. New jeopardy complaint regarding solo ML-DSA under RFC 2026
The second type of complaint considered in RFC 2026, Section 6.5.1, is
"an assertion of technical error" where "the Working Group has made an
incorrect technical choice which places the quality and/or integrity of
the Working Group's product(s) in significant jeopardy".
I am now invoking this provision. Solo PQ, whether solo ML-KEM or solo
ML-DSA, is an incorrect technical choice that places the quality and
integrity of the TLS WG's output in a situation of not just significant
jeopardy but clear security damage. Some of this damage will inevitably
become visible in CVEs and in forensic investigations of how computers
end up being infected by ransomware. Some of the victims will find out
that their security was damaged by various people and companies taking
money from NSA for this, and will file lawsuits. Surely this level of
jeopardy qualifies as "significant".
In a standards organization following its own rules and its own promises
of consensus, the lack of WG consensus on solo ML-DSA would make this
jeopardy complaint moot---it wasn't a choice by the WG in the first
place. In IETF, the chairs are falsely claiming consensus, i.e.,
claiming that the WG chose to approve solo ML-DSA, so the jeopardy
complaint isn't moot.
8. New charter complaint regarding solo ML-DSA under RFC 2418
Beyond RFC 2026, there are further rules in RFC 2418. IETF says in
https://web.archive.org/web/20250528213926/https://www.ietf.org/blog/ietf-llc-statement-competition-law-issues/
that IETF procedural rules "include robust appeal options"---so there
must be a provision to appeal violations of the RFC 2418 rules. Indeed,
RFC 2418 has Section 3.4, "Contention and appeals"; in particular, this
says that one can follow the RFC 2026 process to request "a review of
WG, Chair, Area Director or IESG actions".
I sent email to the list dated 22 Nov 2025 15:30:03 -0000 going
carefully through the WG tasks listed in the charter and comparing those
to solo PQ. In particular, solo PQ is directly contrary to the "improve
security" goal in the charter, a goal that one would imagine has very
high weight for a WG on "Transport Layer Security"; and solo PQ doesn't
serve any of the other goals in the charter.
There has been no response to this. The purported rationale for solo PQ
isn't founded upon what the charter says the WG tasks are; it simply
ignores the charter and makes up its own desiderata.
This violates RFC 2418, Section 2.2, which says that a WG's "charter is
a contract between a working group and the IETF to perform a set of
tasks". The word "contract" indicates that this is enforceable against
the WG: it's _not_ something that the WG can simply decide to ignore.
So I'm now invoking RFC 2418, Section 3.4, to request a review of this
charter violation. This is separate from the process complaint that
there wasn't consensus, and it's separate from the jeopardy complaint.
---D. J. Bernstein
===== NOTICES =====
IETF BCP 78, "Rights Contributors Provide to the IETF Trust", Section 5
(normative), "Rights in Contributions", provides a modification right
"unless explicitly disallowed in the notices contained in a Contribution
(in the form specified by the Legend Instructions)".
The official language from IETF's "Legend Instructions" for the
situation that "the Contributor does not wish to allow modifications nor
to allow publication as an RFC" is as follows: "This document may not be
modified, and derivative works of it may not be created, and it may not
be published except as an Internet-Draft."
<https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf>
The same language is used in, e.g., RFC 5831. The same language hereby
applies to this document. This is not disclaiming or limiting the
applicability of IETF policies; it is strictly following IETF policies.
IESG claims that the "explicitly disallowed" provision in BCP 78 is
limited to the examples in Section 3 in BCP 78. That is incorrect. BCP
78 states that Section 5, "Rights in Contributions", is normative, while
Section 3, "Exposition of Why These Procedures Are the Way They Are", is
informative. The opt-out provision in the normative text is clear, and
cannot be limited by an informative section. BCP 78 does not give IESG
any authority to issue changes or purported clarifications of the rules.
Rationale for exercising the BCP 78 opt-out provision: I'm fine with
redistribution of copies of this document. The issue is instead with
modification, such as (1) IESG's May 2025 posting of an IESG-mangled
version of an appeal that I had filed and (2) IETF management selling
IETF mailing-list text to AI companies. This goes far beyond what
copyright law allows as fair use (such as giving quotes for purposes of
commentary). When I complained about the mangled document, the IETF
Executive Director responded not by apologizing but instead by asserting
that IETF management had the power to do whatever it wanted.
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
