A few procedural notes first, then moving on to specific content.

This spec is going to be a security disaster. When the victims are
looking for accountability, they will want clear records of who made
this happen. This includes records not just of who non-consensually
rammed this spec through IETF, but of who censored and/or terminated
discussions of security objections to the spec.

14 people were already on record objecting to the spec in the WG before
the end of "last call" in the WG. The WG chairs fradulently claimed
consensus. IESG then issued its own "last call". The ensuing discussion
has featured important unresolved disputes; using time limits to
terminate the discussion would be procedurally improper.

IESG's "last call" said "Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-06-01." Is this saying that
2026-06-01 is a time limit that will be used to cut off discussions? No.
Has IESG issued a statement saying that it's ending the "last call" and
will now ignore input? No. Would it be proper to use a time limit to
avoid resolving disputes? No.

So I'm continuing to address IESG via last-call@ietf.org. I'm also
continuing to address the WG via tls@ietf.org---which the TLS WG chairs
have been improperly censoring, but hope springs eternal.

My understanding is that the last-call censor is threatening censorship
on the basis of a message _by one AD_ (not a message from IESG) aiming
to terminate discussions, and in particular will either (improperly)
stop this message from appearing on that list or will (improperly)
retaliate for this message.

Either way, the fact that the appropriate mailing lists are being
censored triggers the "more appropriate list does not exist" provision
of the ietf@ietf.org charter, RFC 9245. IETF promises transparency; I'm
copying ietf@ietf.org both in pursuit of transparency and in the hope of
helping other interested parties continue to participate in discussion.

With that said, I'll now move on to addressing some questions that were
addressed to me regarding the (outrageous, indefensible) security damage
that this spec does compared to draft-reddy-tls-composite-mldsa.

> To focus on what I was actually asking, I am assuming that you are not
> aware of any follow-up paper which challenged/refuted/invalidated
> the claims that EUF-CMA is /sufficient/ for TLS. Could you please
> explicitly confirm? To my naive understanding, that seems to be the
> central part of your claim on this matter.

For me what's central is the statement of security goals in the TLS
standard: the "server side of the channel is always authenticated";
"Data sent over the channel after establishment is only visible to the
endpoints"; "Data sent over the channel after establishment cannot be
modified by attackers without detection".

Here's how TLS tries to achieve those goals: There's authenticated
encryption of data using, e.g., AES-GCM or ChaCha20-Poly1305. The keys
used for that are established by key exchange. To make sure that the key
exchange is with the server rather than an impostor, the client checks a
signature under the server's public key on a transcript that includes
the key exchange. To make sure that the server's public key is from the
server rather than an impostor, the client checks a signature under an
X.509 CA's public key on the server's name and public key. Et cetera.

The goal of each signature verification here is to make sure that the
message being signed was in fact legitimately signed. For example, the
goal of checking the signature under the server's public key is to make
sure that the transcript was actually signed by the server.

In cryptographic jargon, asking a signature system for "EUF-CMA" is
asking the signature system to prevent attackers from forging signatures
on any messages that haven't been signed by the legitimate signer.

("CMA" says that the environment might allow attackers to influence,
maybe even completely control, messages given to the legitimate signer
to sign. For example, in TLS, an attacker can connect to the server and
see a signature under a message partially chosen by the attacker. But
this doesn't count as a forgery; breaking EUF-CMA means that the
attacker signs a message that the legitimate signer _didn't_ sign.)

Connecting the dots: Given how TLS was designed and what EUF-CMA means,
every attack on the TLS security goals via attacking the signature
system will be an EUF-CMA attack on the signature system.

EUF-CMA similarly suffices for many other protocols. This is also why
one finds, e.g.,

    https://web.archive.org/web/20161219102132/http://csrc.nist.gov/groups/ST/post-quantum-crypto/documents/call-for-proposals-final-dec-2016.pdf

saying "NIST intends to standardize one or more schemes that enable
existentially unforgeable digital signatures with respect to an adaptive
chosen message attack. (This property is generally denoted _EUF-CMA
security_ in academic literature.) The above security definition should
be taken as a statement of what NIST will consider to be a relevant
attack."

There are some exceptions---protocols asking for further properties of
signature schemes---but those properties are irrelevant to TLS. For
example, consider the fact that ECDSA and many other signature systems
allow anybody to turn a signature into another signature _on the same
message_. One can find protocols where this "signature malleability"
(hyped as "violation of strong unforgeability", abbreviated as
"violation of SUF-CMA"; note that "SUF" is not "EUF") is a security
problem; but the same property is not an attack on TLS.

As another "signature malleability" example, consider a signature system
that internally does trivial concatenation of an ECC signature and a PQ
signature on a message into an ECC+PQ signature, with the verifier
internally checking whether both signatures verify. Maybe the attacker
comes up with another signature on the same message as follows:

    * use a quantum computer to find the ECC secret key;
    * use that to generate another ECC signature of the same message;
    * concatenate that with the legitimate PQ signature of the message.

This doesn't break TLS. What TLS cares about is whether the message was
legitimately signed---which in this case it was---rather than whether
this particular signature was the one that the signer produced.

Starting in mid-April, John Mattsson has claimed many times that this
quantum "attack" on draft-ietf-lamps-pq-composite-sigs and on
draft-reddy-tls-composite-mldsa is a problem. But calling this an
"attack" is wrong. We're talking about TLS. This is not an attack on
TLS. The (far less expensive) signature malleability of ECDSA etc. also
isn't an attack on TLS.

I don't see where he has ever substantiated his claim or answered the
responses to the claim. My security objection to draft-ietf-tls-mldsa
doesn't actually rely on this---a minor tweak to ECC+PQ to first sign
with ECC and then use PQ to sign the message-signature pair, which is
one of the recommendations in, e.g.,

    https://pqcrypto.eu.org/deliverables/d2.5.pdf#subsection.3.3

in 2018, would stop this "attack"---but, more importantly, it's not an
attack on TLS in the first place.

Of course, cryptography can fail because of any tiny detail that hasn't
been adequately checked, so it's good to have (1) people going carefully
through all protocol details, (2) people writing proofs that the TLS
security goals are achieved if signatures provide EUF-CMA and ciphers
are secure and so on, and (3) computers comprehensively checking those
proofs, since humans often miss errors in proofs (see, e.g. the errors
listed in https://cr.yp.to/proofs/errors.html)

TLS 1.3 was advertised as insisting on proofs. The reality wasn't as
comprehensive as the marketing---there wasn't an insistence on proofs
covering all protocol details and reaching a satisfactory quantitative
security level and being computer-checked. "Computational" proofs are
sometimes quantitatively satisfactory (good) but usually miss protocol
details and are rarely computer-checked. "Symbolic" analyses habitually
use computers (good) but unfortunately do this by skipping not just
quantification but many other cryptographic details---and we know quite
a few examples such as https://cr.yp.to/papers.html#rc4biases where
feasible TLS attacks were allowed by those details.

Nevertheless there was some serious effort at risk reduction, such as
https://eprint.iacr.org/2020/1029 looking closely at TLS handshakes.
Unsurprisingly, Theorem 7.1 from that paper asks the signature system
solely for EUF-CMA. (This is quantified as "mu-EUF-CMA", which is a
"multi-user" version of EUF-CMA where the attacker wins by breaking one
out of many uses of signatures. If there are 2^50 signatures then this
might amplify success probability by as much as 2^50 compared to
attacking a single signature---which is one of the reasons that cutting
security margins close is a terrible idea.)

You ask whether I'm aware of any paper challenging the idea that EUF-CMA
is sufficient for TLS. No, I'm not, nor do I have any idea how such a
challenge could be justified, given how TLS uses signatures.

> > [...] This isn't because of a lack of study; it's because TLS is
> > _signing the key exchange_ to ensure _integrity of the key exchange_,
> > while integrity of the _signature_ is irrelevant.
> **The first part does not seem right to me. In TLS 1.3, CertificateVerify is
> not just signing the key exchange, it's signing /all messages/ up to and
> including Certificate message.

Sure, TLS is also signing more, but my point applies to all of the
messages signed in TLS. What matters about signatures for the TLS
security goals is simply that each of the signed messages was in fact
signed by the legitimate owner of the public key.

> Do you consider /all/ examples John has provided with references in
> [3] to be irrelevant

I don't see where he's listing any attacks, or even _potential_ attacks,
against the TLS security goals.

> FWIW, what we have in ProVerif proofs is ideal signatures and SUF-CMA
> makes it closer to the proofs.

Well, it's not rocket science to do a symbolic analysis that allows
signature malleability, but either way the symbolic analysis is at best
a simplified analogy of an EUF-CMA analysis or an SUF-CMA analysis.

> # *Implementation bugs*
> Setting the above theory aside, a core argument in your attack seems to be
> implementation bug, where the implementation was not correctly following the
> spec. If that is correct, others (e.g., [3]) have raised substantial
> technical issues in the implementation of
> draft-ietf-lamps-pq-composite-sigs. So I view it as in the category of
> 'risk' too.

My new paper https://cr.yp.to/papers.html#mldsa explicitly considers the
impact of bugs in combiner code. The basic reason that this ends up
being less important than the risk of ML-DSA software disasters is that
there's much more ML-DSA code than combiner code. See also

    https://blog.cr.yp.to/20240102-hybrid.html#morecomplicated

covering this comparison in the KEM context, along with the risk of ECC
bugs, which is also accounted for in my new paper.

> # *Attack setup and assumptions*
> Also to focus discussion, please talk about your latest attack on ML-DSA
> (Section 6 of your paper in my understanding) and not on Dilithium 1.0 so
> that we don't confuse things:

My paper carefully distinguishes these, for example saying "This paper
shows that a small change in ML-DSA software creates an ML-DSA version
of the Dilithium 1.0 software vulnerability"; all of the attack analyses
and demos in my paper take ML-DSA-44.

> What are your assumptions -- if any -- on the key exchange part of TLS in
> the attack? Do you assume KEMs or DHKE or hybrids?

Doesn't matter. The only way TLS stops an attacker from posing as the
server is by signing the key exchange under the server's public key. A
universal forgery attack, such as the demos in my paper, breaks this
protection no matter which cryptosystem is used for the key exchange.

> Could you please clarify "equivalent secret key" in the paper?

As the paper says, the attack "recovers an equivalent key---part of the
secret key---and uses the equivalent key to rapidly forge signatures on
arbitrary attacker-chosen messages, signatures that verify under the
original ML-DSA-44 public key"; Section 4 says concretely what's being
recovered; the paper's supplement includes attack demos.

> From TLS perspective, does it mean attacker recovers the server's
> long-term private key?

No: "This attack does not recover 'the secret key' (and does not justify
[87]'s claim regarding that)". However, as the paper says: "some extra
work in signing lets the attacker compute 'hints' that pass verification
even without knowing the rest of the secret key". Full details are in
the attack demo.

The key-recovery claim from [87] strikes me as implausible, although
overall I've spent very little time looking at the six incompatible
versions of Dilithium; maybe there was some reason that the Dilithium
1.0 software really did expose the entire secret key, rather than merely
exposing enough of the secret key to allow universal forgeries. But for
TLS security this distinction doesn't matter.

> If the private key is recovered, then why the online part is required.
> Attacker can simply keep signing anything with that key and fully
> impersonate the legitimate server rather than MITM.

I'm not sure what distinctions you're drawing here. Impersonation is an
active attack with an online part. MITM is an example of that where the
attacker is also talking to the server.

> ## *Two legitimate signatures*
> I may be missing something cryptographically, but can you please explain
> what exactly you mean by two legitimate signatures under that key?

The server signs two messages (concretely, two key exchanges) under its
public key. The attacker sees those two signatures, the messages, and
the public key.

> Does it
> mean for /any/ connection for /any/ message using /that/ key? Would this not
> be sufficient for an attacker (acting as client) to establish two
> connections with the legitimate server to get these two signatures 

Yes, that suffices.

> At the /symbolic/ (not cryptographic) level, if you have above 4
> assumptions, I don't understand why you need two legitimate signatures under
> that key? To be on the same page, are you saying that it is a pre-condition
> to one of the above 4 assumptions (#2 maybe?)?

I don't understand your #1/#2/#3/#4 division: e.g., #4 sounds like it's
talking about the Dolev--Yao abstraction, but #1 sounds like it's
talking about the real world; more to the point, the forgeries in my
attack demos (which you seem to have under #2) rely on specific software
bugs (which you seem to have under #1), so these aren't independent
assumptions.

The first attack demo in my paper generates forgeries after inspecting
two legitimate signatures. The second attack demo has that effect about
80% of the time; in the other cases, it uses a third signature; in rare
cases it would use more signatures.

> ## *Practicality of attacks*
> Do you have practical numbers on what is:
>  * typical client time out from standard TLS libraries with references

https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf exhibited attacks
involving roughly a minute of online computation; typical clients were
not timing out that quickly.

There's something to be said for trying to enforce short timeouts to
stop attacks, but realistically trying to set a timeout below 1 second
would be an interoperability nightmare, so for faster attacks than that
it isn't necessary to study client behavior---there will certainly be
many vulnerable clients.

>  * time to forge signatures in your attack: as I understand, it is 1s.

The _demos_ run in under 1s per signature on a laptop core. The paper
explains how to make the _attacks_ run much more quickly; 1ms should be
easy to beat.

For modeling the damage done, the paper assumes 1s. Speedups would move
the flat blue upper-left part of

    https://cr.yp.to/papers/mldsa-20260601.pdf#breakable-keys

up to the red level, since then the attack would be limited purely by
the number of vulnerable keys rather than computational time.

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

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 "has a license" to do anything it wants.