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

[Loganaden Velvindron <[e-mail]>]

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]
>