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

Ilari Liusvaara writes:
> With the composite KEMs and signatures, the issue is not the many
> combiners. It is the combinatorial explosion of algorithm pairs, all
> incompatible.

Huh? We have direct evidence of people pointing to the total number of
ECC+PQ choices as an argument to use solo PQ instead. This total number
of choices is affected by (1) the number of ECC choices _and_ (2) the
number of PQ choices _and_ (3) the number of combiner choices.

For example,

    https://web.archive.org/web/20260618215751/https://keymaterial.net/2026/06/18/on-hybrid-signatures/

states that "the biggest issue with hybrids" is a "combinatorical
explosion". The accompanying text reviews various ECC options, various
PQ options, and various combiner options, in the case of signatures.

Example of text that's clearly about combiner choices: "This property is
called separability, and our simple concatenation scheme is very much
separable. So are pretty much all constructions, to varying degree. And
that varying degree allows for discussion of the color of ampersands.
For example, we could introduce a domain separator into our hybrid
scheme, and hope that that would make component signatures unusable."

The current RGLC documents don't include tunable knobs at _that_ level
of obscurity (good!), but they still have more combiners than necessary
and more combinations than necessary---which, as I said, feeds straight
into anti-hybrid arguments.

Early in RGLC I objected to the core complications in these documents:
"Mixing security targets is confusing and error-prone. ... I see no
justification for the complication of specifying more than one combiner.
... I see no justification for the complication of allowing NIST P-256
as another option."

Where's the engineering rationale for all this? All I've seen are vague
allusions to supposedly important efficiency benefits as a reason to mix
security targets.

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