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

Nick Sullivan writes:
> Please reply on-list with your
> position on each document: ready to publish as-is, ready with specific
> changes, or not ready, together with the technical reasons.

Not ready.

1. Combiners should rely on a single security target for KEMs. This
single security target should be IND-CCA2. IND-CCA2 is the most common
design goal for KEMs, and IND-CCA2 has been shown sufficient for a wide
range of protocols.

Mixing security targets is confusing and error-prone. Consider, e.g.,
Adam Langley's comment from 2018 that "CPA vs CCA security is a subtle
and dangerous distinction, and if we're going to invest in a
post-quantum primitive, better it not be fragile". It's easy to destroy
security by plugging a merely-IND-CPA KEM into a protocol that needs
IND-CCA2 (or software that's reusing ephemeral keys).

Similarly, it's easy to destroy security by plugging an IND-CCA2 KEM
into a protocol that actually needs something more, such as the "C2PRI"
target introduced in 2024. Having a combiner rely on C2PRI is begging
for security failures.

Does the popularity of IND-CCA2 necessarily mean that it's the right
target? No. But we should recognize the value of having a standard
contract between KEMs and their applications. Multiple targets are a
complication in this central interface, and adding such complications
needs a _really_ convincing justification.

It's common (although not universal) practice to reject IND-CPA for
these security reasons even though aiming for IND-CPA rather than
IND-CCA2 typically saves >50% of dec time. The dec time simply isn't
important enough to justify the security risks. The cost savings of
relying on C2PRI rather than IND-CCA2 are even smaller than that.

2. I see no justification for the complication of specifying more than
one combiner.

To be clear, I'm not saying that this combiner should be trivial
concatenation (even though concatenation suffices for some important
protocols such as TLS and SSH). What I _am_ saying is that a few extra
lines of code produce a unified combiner that, with negligible cost
beyond concatenation, handles every application handled by these specs.

The cost arguments that I've seen elsewhere for cutting combiner corners
do not hold up to scrutiny. Nobody has any examples of an application
where the cost differences are noticeable.

Meanwhile the complications of multiple options

    (1) unnecessarily offload a decision onto implementors who are less
        well positioned than CFRG to make those decisions,
    
    (2) create a more complicated API for libraries that implement all
        options to punt on the decision (I'd expect a unified combiner
        to end up with _less_ overall code in the ecosystem), and

    (3) feed straight into recent anti-hybrid arguments hyping how hard
        it is to settle on the "+" part of ECC+PQ.

As a side note, it's circular for proponents of solo PQ to add unneeded
complications into the "+" and then point to those as arguments against
ECC+PQ. Procedurally, CFRG should be trying to avoid perceptions of
conflicts of interest.

3. For the concrete KEMs, https://cr.yp.to/papers.html#safecurves
reviews how X25519 avoids various security dangers of NIST P-256. I see
no justification for the complication of allowing NIST P-256 as another
option.

I _do_ see justification for the complication of providing options at a
mix of security levels in case lower security levels are broken, but the
way the draft handles this is unnecessarily risky.

Public attacks over the past 15 years have chopped lattice security
levels down by roughly 1/3. We don't know where this will stop. We don't
know how far ahead attackers are. I'm horrified to hear about recent
claims along the lines of "I am unaware of any lattice cryptanalysts who
have 'gone dark' in a way similar to how Coppersmith did in ~2005" from
people who evidently (1) don't realize how systematically NSA has been
hiring mathematicians and (2) don't realize that Coppersmith by himself
is a formidable lattice cryptanalyst.

An application that can afford to use ML-KEM-1024 rather than ML-KEM-768
should be doing so. It's a mistake for the draft to tie this to the ECC
choice. An application that's satisfied with the maturity and security
of its existing X25519 code shouldn't have to choose between

    (1) preserving that on the ECC side and
    (2) obtaining an extra security margin on the PQ side.

I'm not saying that there's clearly no value in higher ECC security
levels. I'm saying that the considerations there are different from the
considerations in picking PQ security levels, and the draft creates
unnecessary risks by tying these choices together.

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