[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)

[Daniel Apon <[e-mail]>]

I support publication.

Daniel Apon
Anduril/AIS

On Sat, Jun 27, 2026 at 6:42 AM D. J. Bernstein <[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>