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

[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.

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]