Nadim Kobeissi writes:
> I think everyone agrees that we will see severe vulnerabilities in
> *all* software.

That sounds exaggerated to me. Occasionally code is backed by mechanisms
providing very high assurance of zero bugs. Some further code ends up
bug-free through being small enough, well enough reviewed, and well
enough tested. But then tons of code is big, poorly reviewed, and poorly
tested. The variations matter for evaluating security risks---and, in
particular, evaluating the damage done by solo PQ.

> This is a risk we mitigate against through
> best-practice software engineering, through better research and
> through test vectors.

_And_ taking further mitigation steps recognizing that there are still
vulnerabilities, often context-specific steps such as deploying VMs,
deploying firewalls, and making sure that PQ is rolled out as ECC+PQ.

ECC+PQ is an example of how these further steps often produce dramatic
real-world security improvements. CECPQ2b, for example, rescued tens of
millions of user sessions. The _only_ reason that the SIKE break didn't
break those sessions is that CECPQ2b was ECC+SIKE rather than solo SIKE.
There's no reason to think that serious attackers such as NSA wouldn't
already have figured out the attack before those sessions happened.

The SIKE break was via a mathematical break of the spec, but software
bugs can easily be even worse---more attackers finding and exploiting
the bugs; even less computational time for the attacks, allowing the
attacks to be scaled to many more targets. And, of course, an attacker
figuring out how to break _signature_ software used for TLS then gets to
break confidentiality _and_ integrity.

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.

We'll see more ML-DSA CVEs. Some will be severe. Some will be found and
exploited by attackers before the public finds them. Can IETF escape
responsibility for this damage by blaming the libraries that aren't
doing best-practice software engineering? No, this would violate an IETF
promise: "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."

> > I prefer to put most of my testing efforts into more advanced test
> > mechanisms that systematically cover larger classes of software flaws
> > and are easier to scale to large volumes of code.
> Fantastic! Do it!

I guess you're asking for some pointers. See, e.g., SUPERCOP (continual
test improvements; now covering 4913 implementations contributed by
hundreds of people; the test mechanisms are also deployed in lib25519,
lib1305, libmceliece, and libntruprime); saferewrite (used for cryptoint
et al.); djbsort (which I already suggested that you look at to get an
idea of what I think is a reasonable level of quality assurance).

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