On Tue, 02 Jun 2026, 23:08 John Mattsson, <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. > I think that security reviews in hybrid ed25519+mldsa 44 for openssh are welcome. What are the security issues you see in this pr ? https://github.com/djmdjm/openssh-wip/pull/64 > 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]> > wrote: > > 2026-06-02 16:23 GMT+02:00 Russ Housley <[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]> 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] > > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > > -- > > Sophie Schmieg | Information Security Engineer | ISE Crypto | > [email protected] > > -- > 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]
