[CFRG] Re: RG Last Call on draft-irtf-cfrg-hybrid-kems-12 and draft-irtf-cfrg-concrete-hybrid-kems-04

["D. J. Bernstein" <[e-mail]>]

Richard Barnes writes:
> The specific question of "should we have both C2PRI-reliant and
> non-C2PRI-reliant combiners" was posed to the RG at IETF 123

That falls very far short of having a consensus call on list, never mind
the point that last call can review everything.

> If you think there is specific new information that the RG should
> consider, please present that information in some manner more concrete
> than "the CVEs we've seen this year".

I wrote "the CVEs we've seen this year for post-quantum software
obliterate the notion that adding options is safe". Normal readers would
try searching CVEs for "post-quantum" and "ML-KEM" and so on, and would
easily find endless examples of the damage done by unnecessary code
complexity, such as CVE-2026-10097 and CVE-2026-46590. Neither of these
is a subtle bug: the first _would have_ been caught by simple tests that
are in some (but of course nowhere near all) test frameworks, and the
second _would have_ been caught by simple (but again nowhere near
universal) type discipline. Neither of them _was_ caught before release.

> And please explain how that information bears on
> the specific question of whether implementers will make bad choices
> about which algorithms to combine, ignoring clear advice in the
> relevant specification.

We're being flooded with examples of vulnerability announcements
stemming from simple programming mistakes in recent code, and you're
expecting every implementor to read a spec carefully enough to see and
understand a warning about "C2PRI"? C'mon, that's not realistic. (See
also the notes in my previous message regarding reading comprehension.)

The spec warning might _occasionally_ stop the problem, but its main
function is an excuse for shifting blame. I would rather work on
removing unnecessary traps for implementors---starting with asking
which options have a real justification.

> 2. "IETF participants use their best engineering judgment to find the best
> solution for the whole Internet"
> This doesn't mean there's one uniform solution that works for the
> whole Internet.

As I said before, specifically regarding combiners: "a few extra lines
of code produce a unified combiner that, with negligible cost beyond
concatenation, handles every application handled by these specs".

If your "works for the whole Internet" comment is meant to say that, no,
a unified combiner _wouldn't_ work for the whole Internet, then where's
the evidence for that?

> (Also, this is the IRTF, not the IETF.)

I took the "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" quote
from

    https://web.archive.org/web/20250528213926/https://www.ietf.org/blog/ietf-llc-statement-competition-law-issues/

which is a page arguing that the corporate collusion in IETF falls
within the standardization exception to antitrust law. Surely "IETF"
there is meant in the broader includes-IRTF sense (as in statements that
IRTF is the "research arm" of IETF) so as to also protect the collusion
that occurs within IRTF, rather than in the narrower excludes-IRTF sense.

> No cryptographic algorithm can prevent all software bugs.

The point is to _manage risks_. Head-to-head comparisons such as
https://blog.cr.yp.to/20191024-eddsa.html show that X25519 and Ed25519
software are less likely to have security problems in the real world
than ECDH P-256 and ECDSA P-256 software respectively. The reasons for
this are also well understood.

---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 had the power to do whatever it wanted.