[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:
> If that is your position, you are free to use only the U* combiners.

Sure, and if I think RSA-512 is not acceptably secure then I'm free to
use something else.

Saying that an option isn't mandated is not responsive to an objection
that the option carries security risks. It's simply ignoring the content
of the objection.

> Others in the working group argued that the efficiency benefit of the C*
> combiners was worth the additional assumption.

These claims don't stand up to scrutiny.

> There was a clear consensus call to support both models about a year
> ago

First, I don't know what call you're referring to. Second, a last call
is a chance for WG participants to point out issues that were missed
earlier. Third, the CVEs we've seen this year for post-quantum software
obliterate the notion that adding options is safe. Every option needs a
good reason to exist; saving a few picodollars of CPU time per KEM call
is not a good reason.

> the document is clear on the limitations of C*.

We are nowhere near universal deployment of test mechanisms that enforce
these security requirements. Putting a warning into a document is not an
adequate substitute.

> 2. "I see no justification for the complication of specifying more than one
> combiner."
> Here is the justification: As I said in my message to Simon, there is
> already work using the CG and CK combiners,

That's a circular argument, not a justification. "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."

> and the U* combiners are there
> to accommodate those who, like you, do not wish to rely on the C2PRI
> property of the PQ KEM.

Covered above.

> 3. "I see no justification for the complication of allowing NIST P-256 as
> another option."
> Here is the justification: Some implementers want to use P-256, e.g., the
> MLS working group.

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

> It's not CFRG's position to limit options, just to
> provide information to WGs about which options are safe,

Huh? CFRG limits options all the time, sometimes because of chairs not
calling for action on other options and sometimes because the group
rejects other options.

> and P-256 is.

Then how do you explain, e.g., CVE-2023-6135?

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