Here's further support for what I'm saying about bugs. An official NSA
document

    https://web.archive.org/web/20220524232250/https://www.nsa.gov/Portals/75/documents/resources/everyone/csfc/threat-prevention.pdf

emphasizes the value of using two independent layers of security "to
mitigate the ability of an adversary to exploit a single cryptographic
implementation". The types of security listed as important to protect
in this way include not just encryption to protect against "Passive
Threats" but also authentication to protect against "Active Threats".

Of course, signatures are only one piece of TLS, but having two TLS
signature layers still helps mitigate the ability of an adversary to
exploit a single cryptographic implementation. Looking at costs such as

    * 1312-byte keys, 2420-byte signatures: ML-DSA-44
    * 1344-byte keys, 2484-byte signatures: Ed25519+ML-DSA-44

illustrates that, compared to PQ, ECC+PQ is easily affordable. The ECC
code is sitting around anyway; the point is to simply keep using it as
an extra layer of security in case of security failures in the PQ part.

John Mattsson writes:
> Please point to a concrete technical ECC+PQ TLS signature solution

draft-reddy-tls-composite-mldsa will result in far fewer TLS sessions
being broken than draft-ietf-tls-mldsa.

> and explicitly acknowledge that any such hybrid approach would
> significantly delay PQC migration, to the extent that industry would
> miss European 2030 deadlines.

No. There's a very small software difference between the following two
options:

    (1) adding support for "sign the key exchange with ML-DSA" on top of
        the existing "sign the key exchange with ECC";

    (2) adding support for "sign the key exchange with ECC and ML-DSA"
        on top of the existing "sign the key exchange with ECC".

Either way, the new code is primarily the ML-DSA code. The "and" part
adds far fewer lines of code; it makes no sense to attribute multi-year
delays to that.

As I wrote before, it's circular for proponents of solo ML-DSA to slow
down endorsement of ECC+ML-DSA and then use this slowdown as an argument
in favor of solo ML-DSA. Proponents instead need engineering arguments.
"IETF participants use their best engineering judgment to find the best
solution for the whole Internet, not just the best solution for any
particular network, technology, vendor, or user."

Procedurally, there's no consensus at the moment on either option, so
neither option can move forward in IETF. Labeling either option as
"consensus of the IETF community" would be fraud. But I would hope for
the opponents of hybrids to drop their objections so that we can move
forward with cheaply mitigating the ability of an adversary to exploit a
single signature implementation.

> That standalone SLH-DSA or standalone ML-DSA would damage security is
> very speculative.

I've posted quantified estimates of the damage from solo ML-DSA in

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

backed by a detailed explanation of where my numbers are coming from.
Are you disputing the number of lines of ML-DSA code? The statistics
from https://arxiv.org/abs/2107.04940 on the number of CVEs and severe
vulnerabilities per line of code added to cryptographic libraries? The
speeds of the ML-DSA exploit demos in my paper?

When there's a sudden expansion of the TLS software ecosystem to include
>100000 lines of new ML-DSA code (thousands of lines per library times
many libraries), how can you claim that there _won't_ be any severe
vulnerabilities in this code?

> What is very clear is that draft-ietf-lamps-pq-composite-sigs would
> 100% damage important security properties

Your complaint about the ability to modify signatures _for the same
message_, whether this is phrased as "signature malleability" or as
"violation of strong unforgeability" or as damage to "important security
properties", is irrelevant to draft-reddy-tls-composite-mldsa (as the
spec has said since February: "does not impact TLS"), same way that it's
irrelevant to the existing ECDSA.

In April, during WG "last call" for the spec on solo ML-DSA in TLS, you
raised this complaint about "trivial attacks on strong unforgeability"
from the simplest mechanism of signing twice. Falko Strenzke promptly
challenged your claim that this was relevant to the security of
draft-reddy-tls-composite-mldsa:

    https://web.archive.org/web/20260604124009/https://mailarchive.ietf.org/arch/msg/tls/OqDxZ15uLi2sgKdQGoXmtfoptY0/

But you didn't reply. I've been looking through subsequent versions of
your complaint, and so far I didn't find where you answered any of the
counterarguments.

Here's my most recent effort to concisely explain why your complaint is
irrelevant: "TLS is _signing the key exchange_ to ensure _integrity of
the key exchange_, while integrity of the _signature_ is irrelevant.
That's also why proofs end up relying solely on EUF-CMA." Can you please
answer this, either by explaining which step you disagree with or by
retracting your complaint?

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