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

[Simon Josefsson <[e-mail]>]

Ilari Liusvaara <[e-mail]> writes:

> On Fri, Jul 10, 2026 at 05:44:07PM -0700, Eric Rescorla wrote:
>> 
>> Exactly. 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.
>
> The difficult part of that is what those guarantees should be.
>
> The requirements vary a lot from protocol to protocol. This ranges from
> needing OW-CONF (met by any useful KEM), to needing very exotic
> properties (that are very rarely met).

Indeed.  I think a requirement that "other KEMs should have the same
shape as ML-KEM" is in practice just another way of saying that we
should only have ML-KEM, since there is likely to be some way to
identify a particular shape of some KEM to be different from ML-KEM.

We don't really know an exhaustive list of all properties that future
consumers of KEM may need.  Nor can we reasonable know this today.
Consumers of the KEMs will need to figure out their requirements.  For
any applications, this will rule out some set of KEMs, but allow others.

For the majority of IETF applications, I think that almost any of the
common KEMs suffice though, especially when used with a hybrid combiner
like Chempat.

/Simon