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.