Sophie Schmieg writes:
> the described vulnerabilities are due to the usage of the Fiat-Shamir
> transform and are shared by all constructions that use the Fiat-Shamir
> transform as well as ECDSA

No. Some of them are, some of them aren't. Taking Ed25519 as a concrete
example: https://cr.yp.to/papers/mldsa-20260601.pdf#ecc-vs-pq already
reviews how various potential Ed25519 bugs have analogies for ML-DSA,
but it continues as follows: "Section 3 shows how easily bugs can appear
in various lines of ML-DSA code that don't seem to correspond to any
lines in Ed25519."

https://cr.yp.to/papers/mldsa-20260601.pdf#ecc-vs-pq also explains how
difficult it is to argue that ML-DSA bug rates in, say, 2027 will be as
low as Ed25519 bug rates in 2027: "The starting obstacle here is the
vulnerability-lifetime data from [49] and [2], where software
vulnerabilities often remain undetected for 5 or more years. ML-DSA is
suddenly adding many new lines of software. Ed25519 software has
typically been around for much longer, giving many more opportunities
for vulnerabilities to be discovered." The paper gives quantitative
estimates of these effects.

More to the point, the core argument against solo PQ is not that ECC is
less risky than solo PQ, but that ECC+PQ is less risky than solo PQ.
https://cr.yp.to/papers/mldsa-20260601.pdf#eccpq-vs-pq says "Here's the
basic point: even if one imagines the rate of ML-DSA vulnerabilities
somehow being as low as the rate of Ed25519 vulnerabilities,
Ed25519+ML-DSA usually forces the attacker to break ML-DSA _and_
Ed25519, which is less likely than being able to break just ML-DSA."

> ML-DSA is actually the most hardened version of
> this transform, using both entropy stored in the private key with the
> message as well as externally supplied entropy for computing its witness.

https://cr.yp.to/papers/mldsa-20260601.pdf#noncetest explains why this
makes it more likely for real-world libraries to skip known-answer tests
for signing---which in turn gives a free pass to many signing bugs, not
just nonce repetition.

> invent a fault at rhoprimeprime

Bug, not fault. https://cr.yp.to/papers/mldsa-20260601.pdf#nonceease
explains how easy this mistake is for an ML-DSA implementor to make. As
for "invent", this particular bug is just like the Sony PlayStation 3
ECDSA disaster.

> covered by test vectors

The question at hand is not whether your favorite library has tests
catching these bugs. The question is the security damage that would be
done by having TLS use solo ML-DSA rather than ECC+ML-DSA. That's a
question about many different libraries with haphazard collections of
tests. See https://cr.yp.to/papers/mldsa-20260601.pdf#coefftest.

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