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]
