[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]>]

One of my objections is to the "complication of specifying more than one
combiner". One of the reasons I stated for this objection is that the
complications of multiple options "feed straight into recent anti-hybrid
arguments hyping how hard it is to settle on the '+' part of ECC+PQ".

The following comment from Sophie Schmieg (from another thread) is an
example of this data flow:

> My main criticism of hybrid signatures is and remains that there is no
> clear alternative that has enough political capital behind it to make it
> worthwhile to bet on, especially while pure constructions continue to make
> progress. Having even more hybrid constructions beyond the original LAMPS
> RFC feels counterproductive when it comes to that. If proponents of hybrid
> signatures could chose just one combination and construction, it would be
> far easier to implement and throw support behind. With KEMs, this is what
> happened with X-Wing (and the TLS hybrid), but so far with signatures,
> every time I look there is yet another incompatible construction that yet
> another even smaller splinter group would like to see supported.

That's pointing to the existence of many hybrid options as the primary
justification for an anti-hybrid position for signatures. It's saying
that the KEM situation is better.

What happens to this if there are more complications added to the KEM
situation? Somehow documents have ended up in CFRG "last call" with more
combiners than necessary and more combinations than necessary.

If the answer is supposed to be that using ECC+PQ is already common
practice for KEMs today and won't be threatened by more options: Sorry,
no, ECC+PQ is already under assault. For example, one commentator claims
to "represent a major vendor" at "$100B+ scale"; advocates usage of solo
ML-KEM today; and claims that instead using ECC+ML-KEM "will consume
literal years of my life, and countless engineering hours and dollars".

Also, as I mentioned before, CFRG should be trying to avoid perceptions
of conflicts of interest. Readers see that the people in power over
CFRG's ECC+PQ documents include proponents of controversial proposals of
solo PQ; that those documents are adding unnecessary complications into
the "+"; and that such complications keep showing up as arguments for
solo PQ. This is not a good look. Recusal is clearly warranted.

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