*Pinches bridge of nose, exhales through teeth* I agree with Filippo. But seriously, I think the level of vitriol is getting off the charts, and it’s (again) sad to see because Dr. Bernstein is an inspiring scientist with a wonderful track record, and I wish people would stop dragging him through the mud like this.
But he’s wrong here. The best way to address these potential issues in ML-KEM is through improved known-answer tests and other such testing methodologies: https://github.com/C2SP/wycheproof/pull/242 Sophie’s email is very much on point, too. Come on, guys, it’s just a signature scheme. Let’s all be nice! Nadim Kobeissi Symbolic Software • https://symbolic.software > On 2 Jun 2026, at 9:05 PM, John Mattsson > <[email protected]> wrote: > > Agree with Filippo and Sophie. I do not think the IESG should take any action > based on this paper. It does not present anything that has not already been > discussed publicly. ML-DSA is clearly a much better algorithm than ECDSA and > EdDSA. If the IETF were to recommend anything, it could be the use of a > higher security level, but ML-DSA-44 already provides a substantial security > margin when used in end-entity certificates. For long-term roots of trust, I > would use standalone SLH-DSA. > > Well-designed and properly implemented hybrid schemes can provide clear > benefits. However, while X25519MLKEM768 is both cryptographically sound and > widely implemented, there is currently nothing even close to mature for > hybrid signatures in TLS. Several TLS libraries have stated on the TLS > mailing list that they will not implement draft-ietf-lamps-pq-composite-sigs. > Ericsson can be added to that list: we will not support > draft-ietf-lamps-pq-composite-sigs in any of our libraries, products, or > services. In our view, draft-ietf-lamps-pq-composite-sigs is neither > technically nor legally deployable. This should not be interpreted as > opposition to hybrid approaches in general. We strongly support > X25519MLKEM768 and have implemented our own non-composite hybrid signature > solutions for other use cases. > > I wish that those in academia advocating hybrid signatures had spent some > effort producing technically sound and deployable hybrid specifications, > rather than devoting enormous amounts of time slowing the urgently needed PQC > migration in industry. > > While Bernstein focuses on implementation errors in untested reference code > from 2017, and one can speculate about future attacks on ML-DSA, we at > Ericsson have already encountered multiple real-world vulnerabilities in > hybrid signature systems that vendors have attempted to sell to us. Hybrid > signatures are not automatically better. In fact, it is trivial to see that > draft-ietf-lamps-pq-composite-sigs sacrifices several important security > properties of ML-DSA (non-malleability and BUF), properties whose absence > from traditional signatures has contributed to significant practical > vulnerabilities in the past. > > Moreover, the objective of draft-ietf-lamps-pq-composite-sigs is _not_ to > increase security, it is to allow vendors to market FIPS-validated RSA and > ECDSA as "quantum-resistant" even when only the quantum-vulnerable component > has been validated. This is, at best, a highly questionable business practice > and should not be endorsed by the IETF in any way. > > Cheers, > John Preuß Mattsson > > From: Sophie Schmieg <[email protected]> > Date: Tuesday, 2 June 2026 at 19:59 > To: Filippo Valsorda <[email protected]> > Cc: IETF TLS <[email protected]>; [email protected] <[email protected]> > Subject: [TLS] Re: [Last-Call] Last Call: <draft-ietf-tls-mldsa-03.txt> (Use > of ML-DSA in TLS 1.3) to Informational RFC > > Note that the described vulnerabilities are due to the usage of the > Fiat-Shamir transform and are shared by all constructions that use the > Fiat-Shamir transform as well as ECDSA, which is similar, but legally > distinct from Fiat-Shamir. ML-DSA is actually the most hardened version of > this transform, using both entropy stored in the private key with the message > as well as externally supplied entropy for computing its witness. This is why > djb has to reach deep into the implementation and invent a fault at > rhoprimeprime, while much easier to trigger faults exist in EdDSA (simply > supplying an inconsistent public and private key to an implementation is > enough to trigger the fault there). Unless we have similar warnings for ECDSA > and EdDSA, I would not bother with adding them. This behavior is well known > and covered by test vectors, for all Fiat-Shamir variants I'm aware of. > > On Tue, Jun 2, 2026 at 10:38 AM Filippo Valsorda <[email protected] > <mailto:[email protected]>> wrote: > 2026-06-02 16:23 GMT+02:00 Russ Housley <[email protected] > <mailto:[email protected]>>: > 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. > > There is no need anyway. > > Bernstein looks for severe bugs in ML-DSA implementations, and only finds one > in a 2017 implementation of Dilithium 1.0, and then invents three bugs that > resemble it. All four would be found by running any KATs for any signing > interface, including the high-level non-internal deterministic signing one. > > This paper could have been a few uninteresting entries in a muzoo > <https://github.com/FiloSottile/mostly-harmless/tree/main/muzoo> mutations > folder. > > Some of the surrounding 50 pages of stuff make claims that are at best > confused and at worst intentionally obtuse. For example on page 15 he claims > he can't see how to use a test vector that provides (seed, public key, > message, µ, signature) > <https://github.com/C2SP/wycheproof/blob/878e5366008753df2064d40c49f8e2f50f9c6af7/testvectors_v1/mldsa_44_sign_seed_test.json> > to test a signing interface that does (seed, message) => (signature) or a > key generation interface that does (seed) => (public key). These > misunderstanding seem to mislead other parts of the paper such as claiming a > trivially-caught bug "can’t be caught by the nonexistent ML-DSA keygen tests > in [Project Wycheproof]" or that "[Project Wycheproof] seems to require a > nonstandard interface to test ML-DSA signature generation, and it doesn’t > test ML-DSA key generation at all." > > These bugs are so easy to find that they would be caught by the vectors in > the body of draft-celi-acvp-ml-dsa > <https://pages.nist.gov/ACVP/draft-celi-acvp-ml-dsa.html>, without even > accessing actual ACVP vectors provided by NIST at > https://github.com/usnistgov/ACVP-Server/tree/master/gen-val/json-files, > which Bernstein somehow wrote a 59-page paper about testing ML-DSA without > referencing. > > Russ > > > On Jun 1, 2026, at 4:42 PM, D. J. Bernstein <[email protected] > > <mailto:[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] <mailto:[email protected]> > > To unsubscribe send an email to [email protected] > > <mailto:[email protected]> > > _______________________________________________ > TLS mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] <mailto:[email protected]> > > > _______________________________________________ > TLS mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] <mailto:[email protected]> > > > -- > > Sophie Schmieg | Information Security Engineer | ISE Crypto | > [email protected] <mailto:[email protected]> > > _______________________________________________ > TLS 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]
