[TLS] Jeopardy 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:

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.