Muhammad Usama Sardar writes:
> I believe no amount of code review, testing, formal analysis of specs,
> formal verification of implementation, following BCPs, etc. can lead to a
> guarantee of /bug-free/ code.

As I said: "Occasionally code is backed by mechanisms providing very high
assurance of zero bugs." For example, the s2n-bignum implementation of
X25519 has very high assurance of zero bugs. For my review of that, see
https://cr.yp.to/talks.html#2025.10.07.

Btw, please get in the habit of quoting what you're replying to, so that
readers can more easily track the discussion. Thanks in advance.

> Software is getting so complex that all of these may likely still miss
> some bugs.

Right. I said "occasionally". Programming practices vary. Tools for very
high assurance are getting easier to use but are still expensive, so
most code doesn't even try to use them. Typically programmers just write
something, write a test, observe the test failing, find a fix, and
repeat until tests pass; many bugs slip past the tests.

That's why suddenly expanding the cryptographic ecosystem by >100000
lines of new ML-DSA code is guaranteeing many bugs, sometimes severe.
The ML-DSA CVEs have already begun; it's simply a matter of time until
we see severe ML-DSA CVEs; it's not plausible that the public will find
and universally patch all the severe ML-DSA software vulnerabilities in
time to stop real attacks. What _will_ reduce the damage is ECC+ML-DSA.

Of course, there's also the risk of the ML-DSA spec being broken, but
assessing that risk relies on more specialized expertise than seeing the
definite problem of bugs. For example, one of the claims recently cited
as evidence of lattice security was "General lattices, such as used in
FrodoKEM, being broken is pretty much all but equivalent to proving
P = NP"; very few readers will understand how implausible this supposed
connection is given https://cims.nyu.edu/~regev/papers/cvpconp.pdf etc.

The claims suggesting that there won't be bugs are much weaker, such as
an unquantified claim of "exceedingly few bugs" in software for ML-DSA.
Typical readers can easily check how big ML-DSA software is, already
know that assurance practices vary, and conclude that there will be
severe ML-DSA software vulnerabilities.

> Confidentiality /and/ integrity of /what/? and /how/? Could you please
> explain the concrete attack trace in simple words?

Sure. To review the setup: Imagine rollout of ML-DSA in TLS, not inside
ECC+ML-DSA but as solo ML-DSA. Servers will use many different ML-DSA
implementations, in some cases with severe vulnerabilities.

When I say "severe", I mean that the attacker can pick any message and
rapidly forge a signature on that message, a signature that passes
verification under the legitimate server's public key. When I say
"rapidly", I mean quickly enough to generate forgeries before a TLS
client times out. (The online part of this is from the message where a
signature is being forged to the signature; message-independent attack
computations can happen in advance.)

As a concrete example, consider the AABBCC software bug---a bug that was
in both official Dilithium 1.0 implementations and passed the
known-answer tests used for those, a bug that my paper

    https://cr.yp.to/papers.html#mldsa

shows is again an easy mistake to make for Dilithium 3.4 (ML-DSA) and is
exploitable in <1 second on 1 laptop core. My Sage exploit scripts
running at this speed are open-source for anybody to try. I expect a C
exploit to be <1ms, but this is overkill.

(As a side note, this particular exploit requires the attacker to see not
just the public key but also _two_ legitimate signatures under that key,
so you might imagine stopping this particular attack by throwing the
server's public key away after _one_ signature and having the server
obtain a certificate for a new public key. I think it's safe to assume
that most real-world TLS usage won't look like that in the near future.
Furthermore, there's no rule saying that attacks need two signatures.
The AABBCC bug already degrades security after just one signature by
chopping lattice dimensions in half; one of the bug patterns I showed
would produce AAAABBBB even more easily, chopping lattice dimensions in
half again; offhand I'd think that's already feasible to exploit with
one signature, although I didn't run through the calculations.)

I'll make one simplifying assumption, namely that the attacker is in
control of one of the routers between the client and the legitimate
server. The attacker now poses as the legitimate server---sending
attacker responses to the client packets while not letting those packets
through to the legitimate server.

The client, believing the TLS promise of confidentiality ("Data sent
over the channel after establishment is only visible to the endpoints"),
then encrypts confidential data to what it thinks is a key shared with
the legitimate server. In fact, that key is shared with the attacker,
and the attacker simply reads the data.

The client also receives data under what it thinks is a key shared with
the legitimate server. The client checks an authenticator on that data
and believes the TLS promise of integrity ("The server side of the
channel is always authenticated ... Data sent over the channel after
establishment cannot be modified by attackers without detection"). In
fact, the data is simply forged by the attacker.

This is a conventional man-in-the-middle attack. The only protection
that TLS tries to provide against this attack is a signature, under the
legitimate server's public key, of the session's key exchange. The
attacker forges that signature.

Please note that Simon Josefsson, one of the 14 TLS WG participants who
objected to this security-damaging spec before the end of the specified
WG "last call" period, already summarized this type of attack during
that period in response to a claim that signature schemes "can only be
exploited once a CRQC exists":

> > > > They can be exploited when, for example, any pre-quantum implementation
> > > > bug is identified.
> > > > 
> > > > You can't have end-to-end confidentiality without authentication, and
> > > > TLS uses signatures for authentication.
> > > > 
> > > > Thus you could make an argument that PQ-hybrid signatures is more
> > > > important than PQ KEMs, since signatures are a requirement to have ANY
> > > > kind of confidentiality guarantees.
> > > > 
> > > > Otherwise we are back to the old 1990's world of no protection against
> > > > active man-in-the-middle attacks.

There was no reply to that message. The claim that signature schemes
"can only be exploited once a CRQC exists" was neither defended nor
withdrawn.

> # *Gentle reminder for outstanding objection to EUF-CMA*
> Unless I missed something, I haven't seen an answer to my question in [4].
> Also, John has kindly provided substantial technical response with concrete
> references in [5], to which I haven't seen a reply. Did I miss something?

I'm not the only person who has already explained that those complaints
about signature malleability are irrelevant to TLS.

Here's the simplest way to see that those complaints are off topic:
ECDSA is allowed in TLS. ECDSA signatures are malleable. Nobody has any
TLS attacks exploiting this malleability (or, in deceptive terminology,
exploiting a lack of "strong unforgeability"). 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. That's also why proofs end up relying solely on EUF-CMA.

Procedurally, it's problematic that the complaints about signature
malleability are being repeated without the answers to those complaints
being addressed. Asking people to repeat the answers isn't the right
approach; this just exacerbates the already excessive error-correction
burden. It's much better for every objection to be officially tracked,
as in ISO etc., with a requirement of the group settling on a response.

My own tracking chart https://blog.cr.yp.to/20260221-structure.html
already covers the "trivial attacks on strong unforgeability" argument
(along with many other arguments). But an unofficial tracker doesn't
have the same power as an _official_ tracker backed by enforcement of
RFC 2418's rule that disagreements "must be resolved by a process of
open review and discussion".

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