[TLS] Re: [Last-Call] Re: Re: Last Call: <draft-ietf-tls-mldsa-03.txt> (Use of ML-DSA in TLS 1.3) to Informational RFC

[Soatok Dreamseeker <[e-mail]>]

At a glance, I found a bug.

This isn't the worst bug, but as of
https://github.com/djmdjm/openssh-wip/pull/64/commits/3f46d7e044f736dd04f7b03a795c2709f5f2c1ae,
at least, crypto_sign_mldsa44_ed255199_keygen_seeded() silently discards
keygen failures.

https://github.com/djmdjm/openssh-wip/blob/3f46d7e044f736dd04f7b03a795c2709f5f2c1ae/ssh-mldsa-eddsa.c#L58-L83

The "goto out" for lines 66-70 doesn't change the return value from 0.

This is the sort of thing I'd expect the OpenSSH team to find in a code
review, but since you asked.

On Tue, Jun 2, 2026 at 3:24 PM Loganaden Velvindron <[e-mail]>
wrote:

>
>
> On Tue, 02 Jun 2026, 23:08 John Mattsson, <john.mattsson=
> [e-mail]> 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 <sschmieg=[e-mail]>
>> *Date: *Tuesday, 2 June 2026 at 19:59
>> *To: *Filippo Valsorda <[e-mail]>
>> *Cc: *IETF TLS <[e-mail]>; [e-mail] <[e-mail]>
>> *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 <[e-mail]>
>> wrote:
>>
>> 2026-06-02 16:23 GMT+02:00 Russ Housley <[e-mail]>:
>>
>> 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 <[e-mail]> 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 -- [e-mail]
>> > To unsubscribe send an email to [e-mail]
>>
>> _______________________________________________
>> TLS mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>>
>> _______________________________________________
>> TLS mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>>
>>
>> --
>>
>> Sophie Schmieg | Information Security Engineer | ISE Crypto |
>> [e-mail]
>>
>> --
>> last-call mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>