[TLS] Re: Jeopardy complaint to ADs regarding draft-ietf-tls-mldsa and draft-ietf-tls-mlkem

[Deb Cooley <[e-mail]>]

Bottom Line Up Front (BLUF):  I'm requesting a short concise explanation
for the differences between this appeal and [0].  From a quick skim, they
look very similar, unless I understand the distinction, I will handle them
as one appeal.

Background:

Between 19 and 20 Sep, DJB attempted to post 4 appeals in 13 messages to
various mailing lists.
 - 9 of those messages were (erroneously) held for moderation on the TLS
list.  On 19 Sep, three of those messages were released to the TLS wg mail
list (the others appear to be copies of the original three).
 - 4 of those messages (including the one I'm replying to) did not appear
in the archive, nor in the moderation queue.  The mail system support is
tackling this issue (I've cc'd Jay Daley in case he cares to elaborate).
They also appear to be mostly duplicates of the one to which I'm replying.
I'm hoping to ensure the message makes it to the tls archive (I have not
modified that message in any way)
 - DJB has now 4 email addresses that can be found in the TLS mail list
system - two are subscribed to TLS and two are not (they are in the global
allow list).

Deb Cooley
Sec AD

[0] https://mailarchive.ietf.org/arch/msg/tls/fxYN0_VHAL4m29Q_6z5wsUSM6MY/

On Sun, Sep 20, 2026 at 2:03 PM D. J. Bernstein <[e-mail]> wrote:

> [Mail-delivery note: Multiple vantage points show discrepancies in
> what's being delivered to different [e-mail] subscribers, along with
> further messages being blocked in violation of IETF policy. While
>
>
> https://archive.cr.yp.to/2026-09-20/17:53:25/CTEknlor69tVds5err_oMugneMScIW6SryCVbW9TM2o/https/mailarchive.ietf.org/arch/msg/tls/fxYN0_VHAL4m29Q_6z5wsUSM6MY/
>
> https://archive.cr.yp.to/2026-09-20/17:56:03/sIa-zA52uY0I8ws8FR4TJeBYkASuYhjRDPK-NvH4LJc/https/mailarchive.ietf.org/arch/msg/tls/RxjG9REVm4HfwhshJcfikrB3Yp8/
>
> https://archive.cr.yp.to/2026-09-20/17:56:12/Yv6bbxbQEKS40Ev4u5Q77HOLwIlyKM7xEIRT43H20L0/https/mailarchive.ietf.org/arch/msg/tls/Kt-Z1YZarfkIKCo6VOasDXd8dMU/
>
> have appeared in IETF's official list archives, they haven't been
> delivered to at least two subscribers, and meanwhile the message below
> sent at the same time---with receipt acknowledgment from the ietf.org
> mail server---isn't in IETF's official list archives.]
>
>
> To [e-mail] and [e-mail], cc'ing [e-mail]
> for transparency:
>
> RFC 2026, Section 6.5.1, authorizes complaints regarding "technical
> error", in particular 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'm hereby complaining to the ADs on this basis regarding each of the
> documents draft-ietf-tls-mldsa and draft-ietf-tls-mlkem. Obviously the
> documents have to be stopped. Details appear below, along with a review
> of the WG chairs failing to address this. I request acknowledgment of
> receipt from the ADs.
>
> I'm also hereby asking [e-mail] to confirm that it will
> pause processing of these documents until there has been full resolution
> of all complaints filed, including this one. If decisions are locked
> into place before complaints about those decisions are resolved then the
> complaint procedures are meaningless. I request acknowledgment of
> receipt from [e-mail].
>
> To avoid a source of inaccuracies, I strictly avoid all use of LLMs in
> writing all of my messages, including this one. See
>
>
> https://www.nytimes.com/2026/04/13/well/ai-chatbots-cancer.html?unlocked_article_code=1.4FA.nfHn.tMfHDs5AvOKj&smid=url-share
>
> for motivation. I request that responses also avoid all use of LLMs.
>
>
> 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 the claim of more protection is actually true.
>
> I posted a paper in June 2026 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 RFC
> 10024 (draft-ietf-tls-ecdhe-mlkem) and draft-reddy-tls-composite-mldsa.
>
> The top weapon wielded by opponents of security improvements is the
> argument that security improvements are unaffordable. This weapon simply
> bounces off ECC+PQ: the costs of ECC+PQ and solo PQ are practically
> identical. The main cost of ECC+PQ is PQ network traffic, not ECC
> network traffic or ECC computation. For example, ML-KEM-768 sends an
> 1184-byte key plus a 1088-byte ciphertext, while adding X25519 adds just
> 32 bytes to the key and adds just 32 bytes to the ciphertext. ML-DSA-44
> sends a 1320-byte key plus a 2420-byte signature, while adding Ed25519
> adds just 32 bytes to the key and adds just 64 bytes to the signature.
>
> The cost difference between ECC+PQ and PQ is even less noticeable in the
> context of overall application costs. For example, Meta reports spending
> only 1/2000 of its CPU cycles on X25519, the dominant ECC choice. See
> https://blog.cr.yp.to/20260219-obaa.html#cost for further numbers and
> references.
>
> The complexity and risks of software engineering and testing for ECC+PQ
> are almost entirely inside the ECC code (which was there already) and
> the much newer PQ code (for evaluations of PQ 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
> didn't appear before my June 2026 paper, 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. See also
>
>
> https://web.archive.org/web/20260811110407/https://mailarchive.ietf.org/arch/msg/tls/y8SB0h1D7IU1MD1ZQHpLuVJSm-g/
>
> https://web.archive.org/web/20260815191224/https://mailarchive.ietf.org/arch/msg/tls/g-oB-wLzxRO9VCrX1FPHQxVEfBE/
>
> https://web.archive.org/web/20260811110635/https://mailarchive.ietf.org/arch/msg/tls/0yf-y5TdzghP8F9j3hlNoSV20jc/
>
> https://web.archive.org/web/20260811110701/https://mailarchive.ietf.org/arch/msg/tls/yw4jeDTFmcHdWDehavATABn8pio/
>
> regarding newer arguments and counterarguments.
>
> draft-ietf-tls-mlkem-11 from a few days ago (2026-09-17) includes
> unfounded insinuations that ECC+PQ sometimes poses problems for
> "performance" and for "operational constraints". See
>
>     https://blog.cr.yp.to/20260221-structure.html#cost
>
> for more examples of such insinuations. If anyone had found even a
> single verifiable example of a TLS application where PQ is affordable
> and ECC+PQ isn't, then we would have heard endless references to that
> example by now, rather than hearing one unfounded insinuation after
> another.
>
> Note that merely having such examples _still_ wouldn't justify an RFC on
> solo PQ in TLS, given the "fundamental" rule that "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"; but this rule doesn't even matter when
> nobody has any examples in the first place. Given how minor the cost
> difference is, there clearly won't be any examples. These specs are
> indefensible from an engineering perspective.
>
> It's remarkable that the arguments for the specs include 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.
>
> The arguments for the specs that sound the most important are arguments
> denying that ECC+PQ is safer than solo PQ. Those arguments don't hold up
> to examination:
>
>     * There's conflation of spec security with software security (this
>       is contradicted by endless examples of bugs and timing attacks),
>       accompanied by a claim that the ML-KEM and ML-DSA specs were
>       "fully vetted" during the NIST competition (this is contradicted
>       by, e.g., eprint papers 2025/1910, 2025/2189, and 2026/279).
>
>     * 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. Consider NSA
>       secretly describing its QUANTUMINSERT forgery attacks as "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 was repeatedly debunked, even with a debunking demo in
>       https://github.com/crypto-security-tools/on-composites-signatures,
>       and yet the claim was incessantly repeated on the TLS list.
>
> An RFC on solo ML-KEM or solo ML-DSA in TLS will encourage usage and
> ultimately create security problems where the damage would have been
> mitigated at negligible cost by ECC+ML-KEM and ECC+ML-DSA.
>
>
> 5. Jeopardy complaint regarding solo PQ under RFC 2026
>
> 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.
>
> According to https://www.merriam-webster.com/dictionary/in%20jeopardy,
> "in jeopardy" means "in a situation in which someone or something is
> exposed to possible injury, loss, or evil : in danger". When RFC 2026
> says "in significant jeopardy", it's asking whether there's a
> significant danger, a significant risk. TLS is so broadly used that a
> security failure giving away TLS keys is tremendously damaging even when
> only a small fraction of TLS keys are affected. Surely this level of
> jeopardy qualifies as "significant".
>
> I have separate active complaints that the chairs are falsely claiming
> consensus. The WG had consensus on neither solo ML-DSA nor solo ML-KEM.
> In a standards organization following its own rules and its own promises
> of consensus, the absence of WG consensus would make this jeopardy
> complaint moot---the document wasn't a choice by the WG in the first
> place, so it would be rejected anyway. In IETF, the chairs are falsely
> claiming consensus, i.e., claiming that the WG chose to approve the
> documents, so the jeopardy complaint isn't moot.
>
>
> 6. Resolution efforts
>
> After chair email dated 28 Apr 2026 16:24:37 -0400 claimed that there
> was TLS WG consensus to issue an RFC on draft-ietf-tls-mldsa, my email
> dated 27 Jun 2026 10:39:10 -0000 filed a jeopardy complaint with the
> chairs. I invoked the RFC 2026 provisions and gave a detailed
> explanation of the specific problem at hand.
>
> Chair email dated 19 Jul 2026 11:47:58 +0200 spent a grand total of five
> sentences on this (see below for quotes and for my comments on those),
> ending with "the chairs decline the complaint/appeal".
>
> My understanding is that this chair action applies to both ML-DSA and
> ML-KEM. Chair email the same day, dated 19 Jul 2026 04:31:20 -0700,
> claimed that there was TLS WG consensus to issue an RFC on
> draft-ietf-tls-mlkem.
>
> I'm hereby escalating the jeopardy complaint to the ADs, as permitted by
> RFC 2026, regarding both ML-DSA and ML-KEM. All of this is within the
> RFC 2026 deadlines.
>
>
> 7. Chair non-responsiveness
>
> Finally, here are the five sentences from the chairs regarding my
> jeopardy complaint.
>
> Sean Turner writes:
> > On Point #7, the "jeopardy claim" that pure PQ, as opposed to hybrid
> > and regardless of whether it is ML-DSA or ML-KEM, is a ‘technical
> > error' appears to be based on implementers producing flawed code.
>
> What is "jeopardy claim" supposed to be quoting? It's not a quote from
> the complaint I had filed. It's not a quote from RFC 2026.
>
> Anyway, "based on implementers producing flawed code" is partly correct
> but partly wrong. My complaint said that "using draft-ietf-tls-mlkem
> and/or draft-ietf-tls-mldsa will be an unmitigated security disaster"
> because of "the predictable impact of bugs"---but my complaint _also_
> pointed to "timing attacks" and "the risk of breaks of the _specs_ of
> ML-KEM and ML-DSA", and gave references regarding these points. So the
> chairs are incorrectly skipping part of the basis for my complaint.
>
> > Therefore, the damage statements are aspirational at best; there is no
> > way to predict CVEs or lawsuits, let alone ransomware.
>
> Wow.
>
> I cited a study https://arxiv.org/abs/2107.04940 of _hundreds_ of CVEs
> in cryptographic libraries. There are many broader studies showing that
> there's roughly one vulnerability per thousand lines of code. My paper
> on ML-DSA bugs cites quite a few vulnerabilities already found in ML-DSA
> libraries. _Obviously_ there will be more CVEs for ML-DSA and ML-KEM.
>
> The evidence of damage here is far beyond what RFC 2026 asks for. The
> procedure at hand is a complaint under RFC 2026 that "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".
>
> The chairs aren't attempting to argue that the danger isn't significant.
> Instead the dodge the jeopardy question. They categorically exclude
> every CVE that we haven't seen yet. How can an "engineering task force"
> tolerate having security decisions being made by people who claim that
> "there is no way to predict CVEs"? Are we supposed to believe that we've
> seen the last CVE now, and by the way the sun won't rise tomorrow? This
> is ridiculous. Decisions have to be based on the evidence available.
>
> > In fact, your damage assertions could be made about any cipher suite,
> > including existing cipher suites.
>
> TLS 1.3 removed a bunch of unnecessary cipher suites to reduce risks.
> There's more that we can do to reduce risks. In particular, we're now
> faced with a very easy choice between solo PQ, which is going to be an
> unmitigated security disaster, and ECC+PQ, which at practically the same
> cost as solo PQ will often save the day.
>
> Anyway, when there's a complaint that the WG "has made an incorrect
> technical choice which places the quality and/or integrity of the
> Working Group's product(s) in significant jeopardy", saying that the WG
> is doing other dangerous things is not responsive to the complaint.
>
> > Finally, your complaint fails to suggest a remedy, but we will assume,
> > based on the other pure PQ-related complaints, that you wish to
> > reject/eject the Internet-Draft from the WG.
>
> When a complaint says "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", it's completely clear that the target of the
> objection is solo PQ, including both solo ML-KEM and solo ML-DSA.
>
> I should also note that "pure" is a misnomer, perhaps reflecting some
> chair confusion as to what's going on here. When a document is signed
> with ECC and with ML-DSA, it's being signed with _pure_ ML-DSA; it's
> _also_ being signed with ECC. The fact that the signing isn't _solo_
> ML-DSA doesn't make the usage of ML-DSA impure in any way. Similar
> comments apply to ECC+ML-KEM.
>
> > As ML-KEM and ML-DSA meet the security goals of FIPS 203 and 204,
> > respectively, the chairs decline the complaint/appeal.
>
> Where is this "meet the security goals" claim coming from, and how is
> this claim supposed to be relevant to the complaint at hand?
>
> NIST doesn't guarantee that ML-KEM and ML-DSA are safe. On the contrary,
> NIST has already selected another post-quantum KEM explicitly as a
> backup in case of ML-KEM failing; and NIST is working on similarly
> selecting backups for ML-DSA. See, for example,
>
>
> https://web.archive.org/web/20260906043159/https://www.nist.gov/news-events/news/2025/03/nist-selects-hqc-fifth-algorithm-post-quantum-encryption
>
> where one of NIST's highlighted statements is "HQC is based on different
> math than ML-KEM, which could be important if a weakness were discovered
> in ML-KEM". Furthermore, NIST certainly hasn't endorsed the insane idea
> that _software_ for ML-KEM and ML-DSA is guaranteed safe.
>
> The TLS WG can and should keep ECC as another layer of security, to
> mitigate the damage from potential spec weaknesses and from inevitable
> software weaknesses, rather than stupidly throwing ECC away.
>
>
> ---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
> >
>
> That language hereby applies to this document. This is not disclaiming
> or limiting the applicability of IETF policies; it is strictly following
> IETF policies. IETF has similarly published, e.g., RFC 7425, which says
> the following: "This document may not be modified, and derivative works
> of it may not be created, except to format it for publication as an RFC
> or to translate it into languages other than English."
>
> 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.
>
> IETF Executive Director Jay Daley says that informative text can
> "contextualise and disambiguate normative text as it does here". When he
> was asked what he claimed was ambiguous about the BCP 78 "explicitly
> disallowed" provision, he did not reply. There is no ambiguity, and an
> "Exposition of Why These Procedures Are the Way They Are" is not a
> change to the procedures.
>
> Rationale for exercising the BCP 78 opt-out provision: I'm fine with
> redistribution of copies of this document. However, BCP 78's default
> position, without the opt-out, is a power grab that goes far beyond
> redistribution and far beyond what copyright law allows as fair use
> (such as giving quotes for purposes of commentary). BCP 78 authorizes
> arbitrary modifications, such as plagiarism, quote falsification, data
> falsification, and IETF management selling IETF mailing-list text in
> bulk to AI companies spreading further misinformation.
>
> For example, Google, a major source of IETF funds, systematically
> ingests IETF mailing-list text into its AI system, which modifies the
> text and frequently spits out misinformation to readers. IETF is only
> one of many terms-of-service battlegrounds; this is not a reason to skip
> the battle.
>
> IETF itself also carries out problematic modifications. For example, in
> May 2025, IESG posted an IESG-mangled version of an appeal that I had
> filed, and then in its response confused exactly the point obfuscated by
> that mangling. 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.
>