With the notice that you attached to this note, it cannot be used to improve the Security Considerations of draft-ietf-tls-mldsa-03. As such, this is very unhelpful.
Russ > On Jun 1, 2026, at 4:42 PM, D. J. Bernstein <[email protected]> wrote: > > I've just finished a paper titled "Exploiting ML-DSA bugs": > > https://cr.yp.to/papers.html#mldsa > > Let me gently suggest that IESG extend the current "last call" and ask > the TLS WG chairs to stop censoring my messages to the TLS mailing list. > > The abstract of the paper is as follows: > > At least four Dilithium software vulnerabilities have been announced > so far, including an identical vulnerability in each of the two > official Dilithium 1.0 implementations and two different > vulnerabilities in a "verified" implementation of Dilithium 3.4, > also known as ML-DSA. However, there do not appear to have been any > demos showing exploitability of any of these vulnerabilities. > > This paper shows that a small change in ML-DSA software creates an > ML-DSA version of the Dilithium 1.0 software vulnerability, can > occur by accident as in the original vulnerability, interoperates > with authentic ML-DSA, passes typical tests, and is exploitable in 1 > second on 1 laptop core. This paper provides an open-source attack > demo that inspects a public key and two signatures, obtains an > equivalent secret key, and uses this key to rapidly forge signatures > on attacker-chosen messages. > > This paper also shows that another small change in ML-DSA software > creates a different software vulnerability, can occur by accident as > in the Sony PlayStation 3 ECDSA vulnerability, interoperates with > authentic ML-DSA, passes typical tests, and is exploitable in 1 > second on 1 laptop core. This paper again provides an open-source > attack demo that rapidly forges signatures on attacker-chosen > messages, after inspecting a public key and a few signatures. > > This paper then uses standard techniques to estimate exploitability > rates for ML-DSA software, and to estimate the number of ML-DSA keys > that the attacker will be able to break in year Y, as a function of Y. > > This paper also reviews evidence in the literature regarding quantum > timelines, costs of quantum attacks, and non-quantum security > failures in ECC, so as to estimate the number of Ed25519+ML-DSA > double-signing keys that the attacker will be able to break in year > Y. The main conclusion is that, even years after the first quantum > attack, this number will still be much smaller than the number of > breakable ML-DSA keys. > > Qualitative security benefits of ECC+PQ compared to solo PQ have > been pointed out before, but not with quantified estimates of the > number of breakable keys. Some recent postings gave arguments > disputing these benefits; this paper closes by pointing out flaws in > those arguments. > > ---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 is clear, and cannot > be limited by an informative section. BCP 78 also 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. There's no legitimate excuse for > that, and it goes far beyond what copyright law allows as fair use, such > as giving quotes for purposes of commentary. > > -- > last-call mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
