[CFRG] Re: Per-KEM security considerations: drafts received, and a two week comment period

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

Eric Rescorla writes:
> One could think of this as notionally providing an API with certain
> guarantees and one ought to be able to (1) analyze a protocol based solely
> on those guarantees without knowing the details of the KEM and (2) swap
> in any approved KEM as long as it provided those guarantees.

Surely the choice of shared API should pay attention to the literature
that has already accumulated a wealth of protocol analyses, the primary
basis for decisions of which protocols are safe to deploy.

IND-CCA2 is already used in thousands of papers. There are endless
theorems saying that protocols meet their basic promises of integrity
and confidentiality for the end user, where the cryptosystem hypotheses
in the theorems say IND-CCA2. Unsurprisingly, IND-CCA2 is also the most
common security goal for public-key cryptosystems, whether PKEs or KEMs.

The literature explores weaker alternatives and stronger alternatives,
shifting the balance of work in various ways between cryptosystem
designers and protocol designers. This exploration has been going on for
a very long time: see, for example,

    https://www.di.ens.fr/david.pointcheval/Documents/Papers/1998_crypto.pdf

in 1998 saying that "IND-CCA2 has already proven to be a better tool
for protocol design" compared to various alternatives. The enduring
popularity of IND-CCA2 decades later comes from the fact that it seems
to minimize the total work involved in meeting the aforementioned basic
promises. This also makes failures more likely to be caught by audits.

I'm not saying that this works perfectly---there are certainly screwups
where a cryptosystem claiming IND-CCA2 turns out not to provide it (see,
e.g., https://cr.yp.to/papers.html#hila5) or where a protocol turns out
to need more than IND-CCA2---but all available evidence is that moving
from IND-CCA2 to another contract, whether weaker or stronger, would
produce _more_ security failures.

For example, moving down to IND-CCA1 (for PKEs; it's the same concept
for KEMs) or IND-CPA (which is weaker for both PKEs and KEMs) doesn't
have enough benefit for cryptosystem designers to justify the pain
inflicted on protocol designers and the resulting risks. The issue isn't
merely as in AGL's 2018 quote---"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"---but also that protocol designers
use CCA for static keys (see, e.g., the basic Proposition 5 in
https://cseweb.ucsd.edu/~mihir/papers/modular.pdf, which some people
here will recognize as KEMTLS/AuthKEM). Similarly, moving up to some
property beyond IND-CCA2 would throw away the majority of existing
cryptosystems and would distract cryptosystem designers who already have
too much on their plate (see, e.g., https://cr.yp.to/papers.html#qrcsp)

What would be even worse than shifting from IND-CCA2 to a contract with
higher failure rates would be shifting to a mess of multiple contracts.
Having a single clear IND-CCA2 contract in the middle instead

    * lets protocol designers simply assume IND-CCA2 instead of being
      faced with a complex "whatever cryptosystems provide" property;

    * lets cryptosystem designers focus on providing IND-CCA2 instead
      of being faced with a complex "whatever protocols need" target;

    * modularizes the security analysis, with KEM analysis focusing on
      whether IND-CCA2 is achieved and protocol analysis focusing on
      whether IND-CCA2 is sufficient; and

    * provides interchangeability, letting users easily choose other
      KEMs to move along other axes (e.g., better performance or
      avoiding patents) without tying this to the choice of property.

I'm not saying that it's objectionable per se for cryptosystems to
provide a property beyond IND-CCA2---this might save the day in case of
protocol screwups---or, vice versa, for protocols to rely on a property
weaker than IND-CCA2. But treating these ad-hoc changes as changes in
the _contract_ between cryptosystems and protocols has big downsides,
regressing towards 1980s protocol design.

As I wrote before in commenting on the hybrid-kems call: "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."

For the security-considerations call, I'd like to emphasize that I'm
happy with adopting the topic as I mentioned before, and none of my
comments on details are meant to object to adoption; maybe other people
commenting could also clarify their positions on this?

I think there was already ample support for adoption stated a while ago,
plus all the new documents obviously favoring adoption; it's not clear
to me that there are any objections to adoption---I _think_ the whole
discussion now is of details that people are also fine discussing after
adoption---but maybe I'm misunderstanding. If there _are_ objections to
adoption then of course we have to investigate those objections.

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