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

I'm sorry, your cries of "censorship" are the kind of hysterics which won't win you any sympathy from me.  The TLS list will accept your emails if you turn off your incompatible with reasonable people signature and qsecretary soverign-citizen nonsense.  I'm through with discussing things with you, and I have a lot of sympathy for your position but your behaviour on the list has been way out of sympathetic.  You're welcome back when you're willing to behave like a member of a community rather than a deus-ex-cathedra with your own way of doing things.

And the last-call list is happy to see discussion of documents in last-call.  The time frame was set by the original post, the time is up.  If the IESG re-opens a last-call on the document, then discussion on the last-call list will be back in scope.  Until then, take it to the TLS ist.  Behave yourself like an adult and post email without legal mumbo jumbo boilerplate, and enjoy your membership if the community.

Regards,

Bron.

On Sun, Jun 7, 2026, at 12:41, D. J. Bernstein wrote:
> 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.
> 
> 

--
  Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC
  [email protected]