(ML-DSA, not ML-KEM, obviously. Sorry.) Nadim Kobeissi Symbolic Software • https://symbolic.software
> On 2 Jun 2026, at 9:41 PM, Nadim Kobeissi <[email protected]> wrote: > > *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]
