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

IESG hasn't announced that it is terminating this "last call". Important
disputes remain unresolved. Unfortunately, the [email protected] censor
has started issuing threats _and_ actively blocking messages. The other
appropriate mailing list, [email protected], is also censored. So, beyond
[email protected] and [email protected], I'm addressing this additional
last-call input directly to [email protected], plus [email protected] for
transparency. As before, the censorship of the appropriate mailing lists
triggers the "more appropriate list does not exist" provision of the
[email protected] charter, RFC 9245.

Muhammad Usama Sardar writes:
> /My/ current understanding is that both John and D. J. Bernstein are
> right, but talking about slightly different things, i.e., system-level and
> protocol-level, respectively.

Huh? I'm talking about a big real-world difference between solo ML-DSA
and ECC+MLDSA in how many keys will end up broken. See

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

and the underlying analysis. For TLS in particular, these breaks mean
that the TLS sessions involving those keys fail to achieve any of the
security goals stated in the TLS standard. Even small-scale attackers
will be able to break confidentiality and integrity of those sessions.

Meanwhile I see nowhere that John is talking about an actual attack on
draft-reddy-tls-composite-mldsa. Concretely, he objects that ECC+ML-DSA
as used in the draft, internally concatenating an ECC signature with an
ML-DSA signature on the same message, allows "trivial attacks on strong
unforgeability". Scary-sounding words, but what exactly is the supposed
attack _on TLS_?

When the hype words are stripped away, the "trivial attacks on strong
unforgeability" are as follows. An attacker with a quantum computer
looks at a concatenated ECC+ML-DSA signature on a message M and creates
another concatenated ECC+ML-DSA signature on the _same_ message M by

    * using the quantum computer to find the ECC secret key,
    * using that key to generate another ECC signature of M, and
    * concatenating that with the legitimate PQ signature of M.

How exactly is this an attack _against TLS_? What's the real-world
security property _of TLS_ that's supposedly achieved by TLS today and
that would supposedly be violated by this signature malleability in a
world of quantum computers and draft-reddy-tls-composite-mldsa? Where
exactly are the real-world attacks _against TLS_ enabled by the fact
that ECDSA, a commonly used part of the TLS standard today, allows
instant low-cost signature malleability? Why is signature malleability
supposed to matter for TLS more than endless format variations allowed
in the TLS protocol? Why should anyone take signature malleability of
this form of ECC+ML-DSA as weighing _at all_ against the damage that
solo ML-DSA will do to TLS security, never mind outweighing it?

Linking to papers on SUF-CMA doesn't answer these questions. Waving
vaguely at firewalls doesn't answer these questions. Repeating the
suggestion that ECC+ML-DSA would damage TLS security doesn't answer
these questions. Having IETF censors try to shut down the discussion
doesn't answer these questions. Readers not familiar with the technical
details can still see the pattern of non-answers and can arrive at the
correct conclusion.

John's most recent message claims that I'm arguing that "these technical
aspects should not be discussed in the TLS WG". That's backwards from
reality. To briefly review what happened:

    * He raised his (unfounded) objection to this ECC+ML-DSA spec during
      TLS WG "last call" for a spec of solo ML-DSA.

    * Many people had already objected to ML-DSA in TLS as frivolously
      incurring unnecessary security risks compared to ECC+ML-DSA. He
      was raising signature malleability of ECC+ML-DSA as a (supposed)
      counterargument.

    * RFC 2418 says that disagreements in a WG "must be resolved by a
      process of open review and discussion". So _of course_ the (lack
      of) merits of his objection have to be resolved in the WG.

The primary obstacles to settling this dispute in the WG have been the
chairs (1) censoring the WG mailing list and (2) replacing the mandated
consensus-building processes with a majority-voting process.

> Just a very quick check: It will stop the "attack" because the whole
> message-signature pair now acts as a message for the PQ signature (rather
> than appending two separate signatures), preserving its SUF-CMA properties
> of ML-DSA, right?

Right. But, again, this isn't an attack _against TLS_ to begin with.

> I appreciate the concern. I would be happy if you could share concrete
> feedback on the artifacts[2] to make them more comprehensive.

Those are symbolic analyses. As I wrote before: 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.

> > 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.
> For TLS, could you please clarify if "multi-user" refers to attacker (acting
> as client) opening multiple connections concurrently to the same server?

Or opening multiple connections to multiple servers. Either way, the
basic concern is the same: generic proofs say that an attack against
multiple independent targets in a cryptosystem can be converted into an
attack against a single target, but this conversion comes with a loss of
success probability, and this "looseness" often turns out to be
exploitable. For example:

    https://cr.yp.to/papers.html#bruteforce
    https://blog.cr.yp.to/20151120-batchattacks.html
    https://cr.yp.to/papers.html#footloose

The FrodoKEM attack in the third link caused enough damage to disprove
the official claim that "the FrodoKEM parameter sets comfortably match
their target security levels with a large margin". This is why FrodoKEM
in 2023 was renamed as "ephemeral FrodoKEM" (I guess "ephemeral" means
we're supposed to erase our memory of that cryptosystem) and replaced by
a new, different cryptosystem called "FrodoKEM" that's supposed to be
less vulnerable to multi-target attacks.

Some papers such as

    https://www.cs.ucdavis.edu/~rogaway/papers/exact.pdf

explain a careful way to use proofs: choose cryptosystem parameters so
that proofs quantitatively guarantee the claimed security level under
cryptanalysis-backed assumptions regarding the quantitative hardness of
the underlying problems. Given that

    * real attackers can and do attack multiple targets and
    * proofs of T-target security allow a loss factor of T compared to
      single-target security,

this careful approach means that if you're trying to protect against
a 2^128 attack and could have as many as 2^64 target sessions then you
take parameters beyond 2^128 single-target security against attacks
with probability 2^(-64). There are quite a few cryptosystems where
cryptanalysts have looked at low-probability attacks and found them
being much faster than high-probability attacks, so this ends up aiming
beyond 2^192 single-target security. There are a few cryptosystems with
gentler tradeoffs, but many more where the necessary cryptanalysts
simply hasn't happened.

For comparison, saying "oh, there's a proof so the system is safe", and
then picking parameters without looking carefully at what the proof says
quantitatively, leads to security failures such as the Sweet16 attack
against various ciphers (demonstrated against TLS) and the FrodoKEM
attack (discovered before any FrodoKEM deployment that I'm aware of, but
would otherwise have been feasible for large-scale attackers).

Occasionally the literature has proofs for specific contexts where the
loss factor is below T (https://cr.yp.to/papers.html#amac might be the
simplest example), and then the careful approach doesn't force as much
of an increase in parameters. Making this work for a full system is in
principle possible, but without comprehensive computer-checked proofs
it'll be awfully fragile; also, complication-induced bugs will end up
doing more damage than expensive attacks (although maybe not more damage
than, e.g., Sweet16).

My recommendation is instead to pick PQ parameters designed for 2^256
security, leaving a comfortable security margin. But the difference
between 2^256 and lower security levels isn't as obviously affordable as
the difference between ECC+PQ and solo PQ: one has to look at the cost
limits in applications to see that most applications can afford 2^256.

I hope these examples help explain why symbolic analyses---although
better than nothing---are far from satisfactory. Many more examples of
looseness causing failures appear in https://eprint.iacr.org/2019/1336
(along with many failures of computational proofs!).

> You agree above that it signs /more/ than just the key exchange, but still
> keep saying "signing the key exchange." This is confusing for me. It would
> be helpful to say something like signing the transcript hash.

Let me emphasize my perspective here. The security goals for the TLS
standard are server authentication (and optional client authentication),
data confidentiality, and data integrity. TLS protects data using keys
obtained from key exchange, but how does the client know it's exchanging
keys with the right server? For TLS (and SIGMA more broadly), the answer
is that the server signs the key exchange.

Because of various TLS complications, people often have trouble figuring
out which parts of the TLS protocol really qualify as the key exchange.
There's a security risk if some context relevant to the exchanged key is
missed. That's why TLS now signs the whole transcript---a simple way to
make sure everything is covered; no harm in signing more than necessary.
But the point is to sign the key exchange, so that the client knows it's
sharing a key with the legitimate server.

> Combining the above two, as I understand, attacker only computes part of the
> server's secret key, which is sufficient to produce valid signatures that
> the client will happily accept (and hence you call it 'equivalent secret
> key').

Right.

> Since the key is 'equivalent,' a reasonable symbolic model seems to be that
> the actual key gets leaked/is exfiltrated.Would that be a faithful model? If
> not, then why not?

That's a reasonable choice for a symbolic model. Regarding "faithful",
the online part of the attack (forging a signature) will be maybe 1.8x
slower than legitimate ML-DSA signing, but that's difficult to express
symbolically, and in any case this won't matter for TLS security since
this is much faster than a client timeout.

> > > 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.
> Maybe there is terminology mismatch here. Could you please clarify the
> "online part?"

The attack has two parts. There's an offline part where the attacker,
given the server's public key and two signatures, computes an equivalent
secret key. Then there's an online part where the attacker, given that
equivalent secret key and a message, forges a signature on the message.
The online-offline distinction is between computations that the attacker
carries out during the session where the attacker is impersonating the
server and computations that the attacker carries out before the
session.

> Something I still don't understand is that attacker can pre-establish two
> connections with the server, do all the calculations for 'equivalent secret
> key.' Much later in time, it can simply use that key without needing to do
> anything with the server at that later time. Do you still call it 'online
> part?'

Yes, the attacker is doing this online with the client even if the
attacker decides not to talk to the server at that moment.

Realistically, if a client is doing something like logging in to a
server, then the attacker will want to be in the middle of that to see
what's happening after the login. If the attack goal is instead, say,
sneaking into a software supply chain by replacing a software download
from a public repository with attacker-modified software, then the
attacker can build a copy of the repository at any moment and doesn't
need to talk to the server while sending malware to the client.

> Do you know of any more recent measurements of TLS client timeout behavior?

https://web.eecs.umich.edu/~genkin/papers/9lives.pdf is more recent and
says "30 seconds for almost all browsers".

The papers I'm pointing to had to do some serious work to get their
attacks below the client timeouts. It looks like this will also be the
case for quantum attacks: the first few years of quantum attacks won't
be able to carry out _active_ attacks against one-time X25519 keys _if_
software requires a response within 30 seconds of generating the key.
Reducing this to 10 seconds could buy those keys another year or two.
But it won't do anything to protect against passive attacks that are
reading traffic later, or against active attacks breaking high-value
long-term signing keys.

When low-cost attack demos are already below 1 second on 1 core, it's
not realistic for Internet-wide applications to try to set cutoffs that
will stop those attacks. Network round-trip times are often hundreds of
milliseconds (and sometimes longer), and some devices are very slow.
Trying to set a half-second timeout would cause enough connection
failures to have users screaming, and still won't actually stop the
attacks; most attacks are internally parallelizable.

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