Stephen Farrell writes:
> D. J. Bernstein wrote:
> > IETF does not control software engineering. It_does_ control which TLS
> > options it will endorse. At that layer, there are currently two choices:
> > (1) common-sense ECC+PQ; (2) damaging security with solo PQ.
> I disagree. There's also: (3) experiment with PQ authentication in TLS
> while recommending against production deployment at this time.

Sure, one can consider any combination of answers to the following
questions:

    (A) What to deploy?
    (B) When to deploy it?

Considering combinations can be useful for seeing whether are
interactions between those two questions.

Regarding those combinations: The main graph

    https://cr.yp.to/papers/mldsa-20260601.pdf#breakable-keys

in my paper already addresses the question of what the attacker will be
able to break in future years, as does Section 1: "The main conclusion
is that far fewer Ed25519+ML-DSA keys will be breakable than ML-DSA
keys, not just before the first quantum attack but also continuing for
years after the first quantum attack. This conclusion is robust against
uncertainties in the underlying numbers, such as bug rates."

For example, deployment starting in 2028 or 2030 or 2032 will have far
fewer breakable keys if the choice is Ed25519+ML-DSA than if the choice
is solo ML-DSA, even assuming secret quantum attacks start in 2029. In
other words, solo ML-DSA is a security disaster whether we're talking
about now or years from now.

As for the question of whether Ed25519+ML-DSA or just _Ed25519_ is
safer, https://cr.yp.to/papers/mldsa-20260601.pdf#eccpq-vs-ecc explains
why this one is a close comparison, _not_ robust against changes in the
underlying numbers.

Why isn't Ed25519+ML-DSA automatically at least as safe as Ed25519?
Consider the fact that the current panic to deploy new ML-DSA software
could easily produce an exploitable buffer overflow. There are certainly
variable array indices in ML-DSA code: see, e.g.,

    https://github.com/cryspen/libcrux/commit/4eb8d4074be4b4c9eca2c40e33eae11534d43bfa

fixing a bad bounds check on a variable-index array access. The 2026/192
description of the bad bounds check as a vulnerability stops with some
irrelevant-to-TLS issues such as signature malleability---giving readers
the impression that there aren't more serious issues such as leaking
secret data from RAM after the signature, but I haven't seen anyone
giving a clear, detailed analysis of that. Anyway, my paper describes
broader reasons that it's hard to compare this type of risk to the
quantum risk.

---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 text is clear, and
cannot be limited by an informative section. BCP 78 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. This goes far beyond what
copyright law allows as fair use (such as giving quotes for purposes of
commentary). When I complained about the mangled document, the IETF
Executive Director responded not by apologizing but instead by asserting
that IETF management "has a license" to do anything it wants.