MIME-Version: 1.0
References: 
 <178231320760.1520243.5914961961176039994@dt-datatracker-f9b87776f-8pmmg>
 <20260627103910.4070917.qmail@cr.yp.to>
In-Reply-To: <20260627103910.4070917.qmail@cr.yp.to>
From: Daniel Apon <dapon.crypto@gmail.com>
Date: Sat, 27 Jun 2026 09:18:27 -0400
Message-ID: 
 <CAPxHsSJNDw6eYrb6Fafo69trY_R9h22ah6rAw+wWRn5tjt7s3A@mail.gmail.com>
To: tls@ietf.org, sean@sn3rd.com, joe@salowey.net, durumcrustulum@gmail.com
Content-Type: multipart/alternative; boundary="000000000000522f0906553c1001"
Message-ID-Hash: AGOITIUQNX2OMEW4B5GDQAONIEQXQB46
Precedence: list
Subject: =?utf-8?q?=5BTLS=5D_Re=3A_WG_Last_Call=3A_draft-ietf-tls-mlkem-08_=28Ends_20?=
	=?utf-8?q?26-07-08=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/tls/7hXwfepmuHGRzrCaP8RMSdfXZac>

--000000000000522f0906553c1001
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I support publication.

Daniel Apon
Anduril/AIS

On Sat, Jun 27, 2026 at 6:42=E2=80=AFAM D. J. Bernstein <djb@cr.yp.to> wrot=
e:

> 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/li=
st.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/a=
rch/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/a=
rch/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=3DN ... 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/a=
rch/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
>
>
> =3D=3D=3D=3D=3D NOTICES =3D=3D=3D=3D=3D
>
> 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-provs=
ions.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 -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>

--000000000000522f0906553c1001
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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

--000000000000522f0906553c1001--