[TLS] Charter complaint to ADs regarding draft-ietf-tls-mldsa and draft-ietf-tls-mlkem

["D. J. Bernstein" <[e-mail]>]

[The ietf.org postmaster (1) says they've fixed some misconfiguration
that resulted in various non-deliveries and (2) invites me to resend the
messages. So I'm sending this again now.]

To [e-mail] and [e-mail], cc'ing [e-mail]
for transparency:

I'm hereby complaining to the ADs that draft-ietf-tls-mldsa and
draft-ietf-tls-mlkem violate the TLS WG charter and thus RFC 2418.
Obviously the documents have to be stopped. Further 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

The section "1. Security damage of solo PQ" from my jeopardy complaint
to the ADs is hereby incorporated into this complaint by reference.


2. Mitigation: ECC+PQ

The section "2. Mitigation: ECC+PQ" from my jeopardy complaint to the
ADs is hereby incorporated into this complaint by reference.


3. The actual rationale for solo PQ

The section "3. The actual rationale for solo PQ" from my jeopardy
complaint to the ADs is hereby incorporated into this complaint by
reference.


4. Subsequent discussion of the specs

The section "4. Subsequent discussion of the specs" from my jeopardy
complaint to the ADs is hereby incorporated into this complaint by
reference.


5. Solo PQ violates the TLS WG charter

Taking solo PQ rather than ECC+PQ, whether this means taking solo ML-DSA
as in draft-ietf-tls-mldsa or solo ML-KEM as in draft-ietf-tls-mlkem,
violates the official TLS WG charter.

There are three layers of problems here. First, the choice serves none
of the goals in the charter. Second, the documents don't lay out an
explicit case that they serve a goal in the charter---they simply ignore
the charter, improperly shifting burdens to people who object. Third,
the choice of solo PQ rather than ECC+PQ is directly contrary to the
"improve security" goal, so it would violate the charter even it
contributed to another goal.

Specifically, the charter

    https://web.archive.org/web/20251011020257/https://datatracker.ietf.org/wg/tls/about/

sets three goals for the WG:

    * to improve applicability to "emerging protocols and use cases";

    * to "improve security, privacy, and deployability"; and

    * to maintain the protocol, for example by specifying general best
      practices.

Solo PQ in TLS isn't living in a vacuum. It's a security regression from
the common-sense approach of ECC+PQ in TLS, the approach taken by RFC
10024 (draft-ietf-tls-ecdhe-mlkem) and draft-reddy-tls-composite-mldsa.

Note that the chairs promised to call for adoption of the latter
document but then reneged on this (for unclear reasons), paving the way
for arguments that solo PQ is the only option for signatures since
ECC+PQ wasn't adopted. Those arguments are circular and in any case
irrelevant to my charter complaint. The charter says "improve security",
not "play procedural games to damage security at NSA's request".

One would imagine that the "improve security" goal in the charter has
very high weight for a WG on "Transport Layer Security". The documents
on solo PQ in TLS are directly contrary to this goal.

There are situations where one can argue that incurring a security risk
is justified by a different goal in the charter---such as deployability,
which is a prerequisite for security. But weakening ECC+PQ to just PQ
isn't enabling deployment. See "2. Mitigation: ECC+PQ" for details.

There are various wrong arguments that adding solo PQ simplifies TLS
implementations and thus improves deployability. The reality is that TLS
requires ECC support, and implementations failing to include ECC won't
interoperate with large parts of the Internet. Meanwhile there's only
one broadly deployed ECC+PQ choice in TLS, namely X25519+ML-KEM-768 (as
in RFC 10024), and implementations have to support this if they don't
want a drastic reduction in how often they're making PQ connections.
Maybe ECC will be removed from TLS someday (for example, after demos of
low-cost quantum attacks), but that's _not what these documents do_. The
documents are instead making TLS _harder_ to implement by adding
unnecessary extra options, yet another obstacle to software competition.

The WG's "use cases" goal allows "protocol changes that reduce TLS
resource consumption without affecting security". That's not the
situation at hand. This document isn't making a security-preserving
protocol change: it's incurring unnecessary security risks by adding new
"groups" that throw away common-sense seatbelts. Furthermore, the change
in resource consumption is so minor that it can't possibly outweigh the
"improve security" goal in the charter.

This document also doesn't fit any of the maintenance subgoals in the
charter. It isn't specifying "general best practices for use of (D)TLS,
extensions to (D)TLS, and cipher suites"; in particular, it's far away
from best practices for cipher suites. There was a proposal to mark the
documents as D (deprecated), but this still wouldn't make the documents
fit the "when a particular version should be deprecated" part of the
charter: that's about TLS (or DTLS) versions, not about more specific
options.

The document was introduced in pursuit of "CNSA 2.0 compliance", but any
attempt to use this as a deployability argument is contradicted by an
official NSA document

    https://web.archive.org/web/20250827175413/https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF

saying that "hybrid solutions may be allowed or required due to protocol
standards". If the TLS WG simply holds the line and refuses to endorse
solo PQ, then NSA's TLS purchasing will be forced to comply, destroying
this deployability argument.

What if, hypothetically, NSA suddenly issues a new official document
saying that it _won't_ obey IETF's TLS standards? The resulting "NSA
demands it, therefore supporting it improves deployability" argument
would still fail to outweigh the damage done to the "improve security"
goal in the charter.

We have already seen many examples where options added because of NSA
pressure continued causing security problems for many years. See, e.g.,

    https://publish.illinois.edu/science-of-security-lablet/files/2016/08/10062016-Heninger-Slides.pdf

or Dual EC. TLS 1.3 did better by going beyond removing known failures:
it also tried to proactively eliminate unnecessary risks, for example by
asking for security proofs and, more to the point, taking steps to
remove unnecessary options. Adding new options because of NSA pressure
would be going back to the dark ages where "improve security" was
narrowed to removing known failures.

Furthermore, even if an RFC has a completely clear warning saying "This
is a controversial document incurring unnecessary security risks", most
people who make purchasing decisions _won't see that warning_. All
they'll see is that there's an RFC. They'll also assume that each option
has a good reason for existence---for example, that an option providing
microbenchmark wins is providing _important_ wins. If IETF issues an RFC
on solo PQ then it's begging for bad purchasing decisions. That's again
contrary to the "improve security" goal in the charter.

Finally, given that "Fundamentally, '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.' ", the "deployability" wording in the charter has to
be understood as deployability for the whole Internet, not just what
NSA claims is the solution it wants.


6. Chair non-responsiveness

I filed a detailed complaint about the charter violation (see below for
the procedural authorization for this). The WG chairs issued a grand
total of four sentences in reply, dodging the actual content of the
complaint. Here are those sentences, and my comments on those.

Sean Turner writes:
> On Point #8, the charter complaint refers to two of the three "goals"
> of the WG.

It actually refers to all three goals.

Specifically, my email to the list dated 22 Nov 2025 15:30:03 -0000
objected in detail that solo PQ violated the charter. (This was in the
context of solo ML-KEM, but my objection also applies to solo ML-DSA.)

In particular, my message linked to the charter and accurately stated
that the charter "sets three goals for the WG: to improve applicability
to 'emerging protocols and use cases'; to 'improve security, privacy,
and deployability'; and to maintain the protocol, for example by
specifying general best practices". Three goals, see?

There was no answer to that message. The purported rationale for solo PQ
wasn't, and isn't, founded upon what the charter says the WG tasks are;
it simply ignores the charter and makes up its own desiderata.

In April 2026, the chairs pushed the solo ML-DSA document forward, in
violation of the charter. I filed an objection within the complaint
deadlines. I cited my unanswered earlier message for the details: "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."

> The third goal, which you mentioned in your original email from
> November but failed to quote in its entirety, specifically places
> ciphers suites in scope; see the following:
> > The third goal is to maintain current and previous version of
> > the (D)TLS protocol as well as to specify general best practices
> > for use of (D)TLS, extensions to (D)TLS, and cipher suites.

Actually, I _did_ quote the "cipher suites" part of this. In fact, I
quoted the whole "general best practices for use of (D)TLS, extensions
to (D)TLS, and cipher suites" part. I also explained why this doesn't
apply to the situation at hand.

Specifically, I wrote that the document on solo ML-KEM in TLS "isn't
specifying 'general best practices for use of (D)TLS, extensions to
(D)TLS, and cipher suites'; in particular, it's far away from best
practices for cipher suites". The same comment applies to solo ML-DSA
in TLS.

The chairs don't respond to this. The chairs seem to insist that all
aspects of cipher suites are within scope. But this text is only for
"general best practices for use of (D)TLS, extensions to (D)TLS, and
cipher suites". This isn't some grand authorization for the WG to do
anything it wants with cipher suites, ignoring and even sabotaging the
"improve security" goal in the charter; it's only for best practices.

Have the chairs somehow acquired the idea that the words "general best
practices" are limiting only "use of (D)TLS", not limiting "extensions
to (D)TLS", not limiting "cipher suites"? To see how untenable this idea
is, simply read the first goal covering, e.g., "extensions that help
protocols better leverage TLS security properties". If the third goal
includes _all_ TLS extensions, why would there be any need for the first
goal to spend text authorizing _some_ desirable types of TLS extensions?
This is a nonsensical reading of the charter, an unfounded power grab.

As I wrote in the first place, solo PQ is directly contrary to the
"improve security" goal, _and_ it doesn't contribute to the other goals.
I already explained specifically why solo PQ isn't specifying "general
best practices for use of (D)TLS, extensions to (D)TLS, and cipher
suites". The chairs don't respond to that, and they entirely ignore the
conflict with the "improve security" goal.

> Lacking a remedy, again, we will assume that you wish to reject/eject
> the Internet-Draft from the WG.

In context, the words "Lacking a remedy, again" seem to be claiming that
I didn't make clear that I was asking for these specs to be stopped.

In fact, I wrote that "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". It's completely clear that
the target of this objection is solo PQ, including both solo ML-KEM and
solo ML-DSA. I also wrote that the WG isn't free to ignore the charter.

> In reviewing all words in the charter, we do not see a charter
> violation.

See above.


7. Procedural authorization for charter complaints

RFC 2418, Section 2.2, 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. The contract is also
with the entire IETF, not just IESG.

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".

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 objected to this as a charter violation,
invoking the above complaint procedures and citing my earlier (again,
unanswered) explanation of why this violated the charter.

Chair email dated 19 Jul 2026 11:47:58 +0200 spent a grand total of four
sentences on this (see above), ending with "we do not see a charter
violation".

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 charter 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.


---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.