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

> > > > 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.
> I actually don't understand how this works with multiple servers unless
> there is the assumption that these multiple servers have the same public
> key.

Sorry, I thought you were asking about the "mu-EUF-CMA" concept used in
the TLS analysis https://eprint.iacr.org/2020/1029 that I mentioned.

Yes, the specific attacks in my paper are single-target EUF-CMA attacks.
The attacks use a few signatures under the _same_ public key.

> FWIW, that does not seem right to me. Please see Fig. 1 in RFC8446bis [1]
> which clearly shows that the two messages in key exchange are ClientHello
> and ServerHello. I don't see what Certificate message has got to do with the
> key exchange. That's clearly related to authentication.

Again, the point of signing the key exchange---including all relevant
context---is to authenticate the server. The client then knows it's
sharing a key with the legitimate server. That key, in turn, is used to
protect the confidentiality and integrity of subsequent data.

The point of straightforwardly signing the entire transcript in current
TLS is to make sure that all relevant context for the key exchange is
covered, rather than getting into error-prone evaluations of which
context seems relevant. There's no harm in the server signing too much.

> I noticed that you did not confirm 4 steps of attack vector outlined in [2]
> in my understanding. Could you confirm my understanding?

Offhand I'd say that sounds right, but if I write a TLS-specific demo
then I'll probably end up with some tweaks to the description.

> So in the 4 steps of attack in [2], steps 1 and 2 are offline and steps 3
> and 4 are online, right?

Yes, that's how the offline-online terminology is typically used.

> > 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.
> That sounds like a concern. Could you possibly explain more?

Downloads of public software are often protected solely by TLS (even
when software authors provide PGP signatures). The attacker downloads a
copy of the web site providing the software, replaces the software with
malware, and then exploits a bug in (say) ML-DSA to pose as the server
and deliver this malware to the client downloading the software, either
an end user or, often more interestingly, an intermediate developer.

Of course, revoking the compromised key doesn't magically undo those
malware downloads. Also, malware is typically designed to be persistent
and hard to detect; I've seen people spend months trying to clean up
after intrusions, and there's no real reason to think they succeeded.

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