I support publication. Daniel Apon Anduril/AIS
On Sat, Jun 27, 2026 at 6:42 AM D. J. Bernstein <[email protected]> wrote: > 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
