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

[Sandy Ginoza <[e-mail]>]

Hi,

Please note that draft-ietf-tls-mldsa and draft-ietf-tls-mlkem have been placed on “Stream Hold” until this discussion has been resolved.  

Thank you,
Sandy Ginoza
RFC Production Center



> On Sep 22, 2026, at 12:08 PM, D. J. Bernstein <[e-mail]> wrote:
> 
> [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.
> _______________________________________________
> Rfc-editor mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]