Iran's DigiNotar attack allowed "successful man-in-the-middle attacks
against hundreds of thousands of Internet users inside and outside of
Iran". NSA's QUANTUMINSERT forgeries were operational worldwide starting
in 2005 and weren't publicly detected until the Snowden documents
revealed them in 2013. The primary defenses used against these attacks
are better control over TLS CAs and more use of TLS; signature forgeries
would compromise both of these defenses.

Today software is getting so large that an attacker able to compromise
software supply chains will have endless places to hide, even if some
of the compromises are detected. Security-aware projects typically limit
their component imports and limit the people they trust, but all of
these limits rely on authenticating the supply-chain links. TLS
signature forgeries would directly compromise many of the existing
links---basically, a free pass for attackers to suddenly take over tons
of the world's most important software projects. Recovery from forgeries
can be very difficult.

We're facing many current risks, including the risk of ECC being broken
by quantum computers, the risk of PQ systems being broken even without
quantum computers (this has happened to half of the NIST submissions
already; see https://cr.yp.to/papers.html#qrcsp) and the risk of PQ
_software_ being broken (see https://cr.yp.to/papers.html#kyberslash for
one of many examples). Competent risk management requires us to roll out
PQ signatures to _try_ to stop quantum forgeries, but also to continue
signing with ECC to reduce the damage from PQ failures. Double-signing
with ECC+PQ adds negligible cost on top of PQ signatures.

Christian Huitema writes:
> the debates in the TLS WG surfaced an important difference between key
> exchange algorithms (e.g., MLKEM) and signature algorithms (e.g., ML-DSA)

No. Incorrect _claims_ that the differences are important here suddenly
appeared from spec proponents during WG "last call" and were promptly
disputed on list. See the quotes below.

See also https://blog.cr.yp.to/20260221-structure.html for a chart
tracking arguments for and against. I updated this near the end of WG
"last call", and I think it remains up to date: subsequent postings in
favor of the spec have been repeating previous talking points rather
than addressing the objections to those points.

Objections to this spec were filed on the TLS mailing list by 14 people
(Christoph Striecks, Daniel J. Bernstein, David Stainton, Fabiana Da
Pieve, Izzy Grosof, Jacob Appelbaum, Ludovic Perret, Muhammad Usama
Sardar, Nicola Tuveri, Simon Josefsson, Stephen Farrell, Tanja Lange,
Thomas Bellebaum, Tibor Jager) before the end of WG "last call", in some
cases before "last call" was even issued. One objection was later
withdrawn, but further objections have appeared since then (e.g., in
response to IESG "last call"). This spec doesn't have WG consensus,
doesn't have WG "rough consensus", and doesn't have "consensus of the
IETF community".

> As soon as the breakage becomes publicly known, we can expect
> implementations to switch to a different algorithm. So yes, there will
> be a window of vulnerability, but that window is hopefully short.

https://arxiv.org/abs/2107.04940 found an average exploitability
lifetime of 5.13 years (standard deviation 4.29 years) for 201 CVEs in
OpenSSL, GnuTLS, and NSS.

Is this measuring the number of years where older versions of software
remain in use, allowing attackers to exploit bugs long after patches are
released? No. The paper measured "lifetime" by software-release dates.

Is there a reason to think that bugs weren't being exploited for years
before discovery? No. That's wishful thinking contradicted by, e.g., the
eight years of QUANTUMINSERT being operational without detection.

I agree that, if forgeries are detected and the broken verification
software is upgraded to something safe on all computers, then the
attacker won't be able to forge signatures _after_ the upgrade. But the
signature vulnerability does tremendous damage _before_ the upgrade.
Double-signing with ECC+PQ proactively reduces this damage.

When efforts to downplay the importance of forgery attacks suddenly
appeared on list during WGLC, Simon Josefsson wrote the following: "I
would say a risk of a man-in-the-middle attack is, generally speaking,
more serious than a risks of a store-now-decrypt-later attack. If your
protocol allows a store-now-decrypt-later attack, it is bad. If your
protocol allows a man-in-the-middle attack, it is REALLY bad. Having
man-in-the-middle attackers puts us back into the 1980-1990's era of
computer security, when we used unauthenticated 'telnet'. Having
store-now-decrypt-later puts us back into the 1990-2000's era of weak
encryption algorithms, when we used RC4 or single-DES." (Internal line
breaks omitted.)

The only responses to that were (1) a ludicrous claim that there have
been no "real-world MITM attacks on crypto protocols" (so the DigiNotar
attack doesn't count? how about the attack against TJMaxx exploiting
RC4? how about the Flame malware exploiting MD5?) and (2) a claim that
we don't have to worry about the spec's security risks since the spec
won't be deployed for a long time (this is contradicted by proponents
saying it's urgent to roll this out).

> deploying an hybrid signature algorithm requires certifying two keys
> for each server, which is a substantially heavier burden than just
> adding some extra computations

No. Such complexity claims suddenly appeared on list during WGLC, and
produced quotes such as the following in response:

    * Eric Rescorla: "Of course it would internally have multiple keys,
      but that's no different from existing algorithms whose keys have
      multiple components (e.g., RSA)";

    * Viktor Dukhovni: "in no case would you have to explicitly worry
      about multiple keys at the application layer";

    * Daniel Van Geest: "I implemented Composite ML-DSA in an OpenSSL
      provider and it Just Worked. No X.509 changes. No TLS changes.";

    * Mike Ounsworth: "crazy amount of mis-understanding of composites
      on display here".

In a legitimate engineering organization, this debate would have been
resolved. In IETF, what happened was very different, as I noted in my
complaint to the ADs and IESG regarding the chair claim of consensus:
"This debate wasn't resolved. Bogus complexity claims from proponents of
the spec were not retracted. Instead proponents ran out the clock, using
a time-limited voting process to skip resolution. The complexity debate
is just one example; various further arguments that suddenly appeared
during WGLC didn't even have time for discussion."

People on the last-call mailing list typically haven't been tracking WG
discussions. Given that (1) the chairs claimed WG consensus and that (2)
RFC 2418 says that WG disagreements "must be resolved by a process of
open review and discussion", most people will understand your message as
summarizing an agreement reached by the WG after discussion. But that's
not true. These claims suddenly appeared during WGLC and were disputed.
This dispute wasn't resolved within the WG. Your message is selectively
presenting just one side of the debate. That side is flatly wrong both
from an engineering perspective and a security perspective.

Note that there's no reason to expect that WG participants are on the
last-call mailing list. Procedurally, all of these messages should be
cc'ed to the WG mailing list, making it as easy as possible for WG
participants to track the discussion and to correct errors.

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

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.

Rationale: I'm fine with redistribution of copies of this document. The
issue is 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.