Re: [TLS] Re: [Last-Call] Last Call: <draft-ietf-tls-mldsa-03.txt> (Use of ML-DSA in TLS 1.3) to Informational RFC

Muhammad Usama Sardar writes:
> Please tell me explicitly what's wrong in my firewall reasoning in [0].

I guess that when you wrote "blocked client (acting as attacker) can
bypass allowlist by using another certificate with same contents" you
meant blocklist rather than allowlist, and concretely that you're
alluding to CVE-2026-25793, which says the following:

> > > Nebula is a scalable overlay networking tool. In versions from 1.7.0 to
> > > 1.10.2, when using P256 certificates (which is not the default
> > > configuration), it is possible to evade a blocklist entry created against the
> > > fingerprint of a certificate by using ECDSA Signature Malleability to use a
> > > copy of the certificate with a different fingerprint. This issue has been
> > > patched in version 1.10.3.

I don't see how this is an attack against any of the security goals in
the TLS standard. Even if we assume that this Nebula tool is using TLS,
I don't see how this is an attack _against TLS_.

RFC 8446 says that it "represents the consensus of the IETF community"
and says what the TLS security goals are. I see nothing there about
network blocklists.

But suppose we say: there's a common problem of blocklist implementors
screwing up and banning clients by _signature on the client ID_ rather
than correctly banning clients by _client ID_. Network-blocklist evasion
by formerly authorized users in these screwup cases causes enough damage
to warrant banning ECDSA everywhere, including TLS. (For the record, I'd
be happy to see ECDSA disappear, but not for this reason.)

It's _still_ a giant mistake to equate this with signature malleability
of ECC+ML-DSA via a _quantum attack_ replacing the ECC signature. The
first quantum computer will cost roughly a billion dollars and will
break roughly 2^15 ECC keys per year; there are far more than 2^15 ECC
keys having higher value than breaking a network blocklist.

But, well, suppose we say: quantum attacks will be much cheaper someday,
and then attackers with quantum computers will run out of higher-value
targets and get around to using the quantum computers to break our
network blocklists whenever blocklist implementors screw up.

Even in this scenario, it's _still_ a giant mistake to address this by
using solo ML-DSA rather than ECC+ML-DSA. As I said before, a minor
tweak to the internals of ECC+ML-DSA, namely using ML-DSA to sign the
(message,ECC signature) pair, means that ECC+ML-DSA signature
malleability is as difficult as ML-DSA signature malleability. (Mothma,
which I've been recommending for a while now, does this plus various
other conceivably useful features, with just a few lines of extra code.)

Meanwhile solo ML-DSA is going to produce a tremendous volume of _real_
security failures _the moment it's rolled out_ because attackers will
find and exploit ML-DSA software vulnerabilities. This won't wait for
quantum computers. It won't be limited to attackers who can afford a
quantum computer. It will break the security goals that are actually
in the TLS standard, including data integrity _and_ confidentiality.

Amusingly, the vulnerabilities that have been announced recently in
ML-DSA software include ML-DSA signature malleability. If signature
malleability is supposed to be a severe issue then this contradicts yet
another argument we've seen for solo ML-DSA, namely the claim that we
shouldn't expect any severe vulnerabilities in ML-DSA code since there
haven't been any severe vulnerabilities in ML-DSA code. (That argument
is flawed for other reasons: it's wrong to extrapolate from the lack of
known severe vulnerabilities in new code; also, the original Dilithium
code had a severe vulnerability.)

> I am really surprised that I am repeatedly being pointed to a 13-years
> old attack as an attestation that my formal proofs are 'advertised'
> and 'marketing.' I have no objection to these labels as long as you
> justify these claims. So please do justify.

Here's what I actually wrote: "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."

My previous messages give many examples of attacks where quantitative
security levels are important (Sweet16, for example). Computational
proofs don't always get this right but symbolic analyses essentially
never do. Meanwhile computational proofs are worse than symbolic
analyses in coverage of protocol details and much worse in the level of
computer checking, so it's not as if there's anything putting TLS
security analysis on really solid ground.

> As per AD instruction, the discussion should happen at TLS.

The TLS list should be included in any case, but other lists are also
appropriate. A single AD cannot close a last call announced by IESG.

> So if I have missed something on these lists, please let me know.

I've sent various messages to the TLS and last-call mailing lists that
the TLS censors blocked from the TLS mailing list. The last-call censor
is now blocking that list too (improperly: IESG hasn't announced that
it's closing last call for this spec), so I'm sending messages to the
main IETF mailing list.

> FWIW, I view symbolic and computational methods as /complementary/, as I
> mention in [4]. Putting in all cryptographic details in the symbolic model
> defeats the entire purpose of symbolic analysis.

I disagree. With enough work (and whatever protocol fixes are needed),
it should be possible to produce a computer-checked proof that covers
all protocol details as in a perfect symbolic analysis _and_ covers all
cryptographic details as in a perfect computational proof.

The current situation is that, to limit the amount of work invested,
people normally either skip protocol details (and computer-checking in
most cases) to be able to prove something about cryptographic details
such as quantitative security levels, or skip cryptographic details to
be able to analyze more protocol details. But these are _sacrifices_
that people make to get something done; they aren't the _purpose_.

You were asking whether the proofs indicating that EUF-CMA is sufficient
for TLS (and the lack of any papers arguing that it isn't) are central
to what I'm saying about the irrelevance of signature malleability. For
me, the limitations of the proofs and symbolic analyses available for
TLS mean that this material _must not_ be central to a risk analysis.
Trusting such material is what led to most of the failures described in
https://eprint.iacr.org/2019/1336. I instead look from first principles
at what TLS is doing with signatures and how this can go wrong. I look
at the existing analyses as sanity checks.

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