[openpgp] Re: WG: BSI view on KEM combiners

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

Paul Wouters writes:
      [ regarding draft-connolly-cfrg-xwing-kem: ]
> > > That draft will be adopted in CFRG.
> > Evidence?
> It seems to me, there is consensus for that document

Evidence? Links?

Here's contrary evidence. First, the CFRG discussion of KEM combiners
has had quite a few different proposals that haven't been withdrawn:
e.g., the generic Ounsworth proposal, the much more specific X-Wing
proposal that you're advocating (care to explain why?), and the
intermediate Chempat proposal.

The CFRG chairs proposed adopting the topic; that wasn't controversial.
They also proposed, basically, an informational document covering all
options---but that was controversial. Ultimately the topic was adopted
with a plan of pulling together a design team to evaluate desiderata for
a document:

   https://mailarchive.ietf.org/arch/msg/cfrg/ZYd_q7QP17EtHtvSj60eSeJvkX0/
   https://mailarchive.ietf.org/arch/msg/cfrg/b63jMnt_3VA-wFAGmVyrXTnDY2o/

In July, the design team proposed a path of (A) identifying relevant
security properties, (B) surveying the literature, and (C) specifying
some initial combiners in light of B and A, making sure to cover at
least specific combinations of {P-256,X25519,P-384} and Kyber:

   https://mailarchive.ietf.org/arch/msg/cfrg/CwrVvm-J7o85TEWkG9RJxZwfXDY/

It's certainly not obvious how X-Wing could fit into that plan, given
that X-Wing is by definition specifically X25519+Kyber768. But I
wouldn't say anything is settled here; I'd expect further discussion in
CFRG of how many ECC options should be supported.

Another issue is that, internally, X-Wing uses a combiner whose security
analysis relies on details of Kyber. I've raised objections to this from
a security-engineering perspective; but the more robust Chempat option
(which I favor) has triggered objections that it would cost Google
_millions_ of dollars. Again I wouldn't say anything is settled here.

Certainly no consensus has been declared yet on any specific options,
nor can I imagine how consensus could be declared at this point given
the actual contents of the discussions. When CFRG hasn't declared
consensus, it's weird to see an IETF AD claiming outside CFRG that CFRG
"will" adopt something or that consensus "seems" to exist in CFRG.

> You can always lend a helping hand to the people involved there or
> express your support for the document on the cfrg list to ensure the
> community there is aware.

I've already been providing detailed input to the discussion (see, e.g.,
https://mailarchive.ietf.org/arch/msg/cfrg/8rs9KcfxfKvgn6FKGs7jMenmPQA/)
and in particular pointing out issues in this particular document
(ibid). So I'm baffled by your sentence here.

---D. J. Bernstein