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

[Falko Strenzke <[e-mail]>]

@ Dan Thanks for summarizing the history of events in CFRG regarding the 
KEM combiner question, that saved me the effort of doing something 
similar myself. Further comments inline...

Am 09.09.24 um 16:56 schrieb D. J. Bernstein:
> 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.

Our proposed construction in draft-ietf-openpgp-pqc is indeed based on 
the generic construction that was the first input to CFRG in this 
discussion (as I recall it) (see for instance 
https://mailarchive.ietf.org/arch/msg/cfrg/OSG9rayj_-FAmIIXa8BuJ39HvWo/) 
The security of the construction was never in question. The only recent 
points of discussion were a) whether to use KMAC or raw SHA-3 and b) the 
NIST compliance. KMAC uses SHA-3 internally, so the essential security 
properties of the constructions do not differ. NIST compliance has an 
interdependency on a) due to the way the SP 800-56C defines the key 
shares. Furthermore, NIST conformance requires specific orderings on the 
input of the key shares. All of these details we have been working on 
are only cosmetics. As I understand it, the different proposals in CFRG 
are not due to different views on what is a secure construction and what 
not, rather they are looking for the most efficient ones under certain 
assumptions – just as Dan explains in his response.

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

So far the vote of the OpenPGP (as the authors of draft-ietf-openpgp-pqc 
have understood it) was to specify a reusable KEM combiner, neither only 
a fixed combination of PQ and T algorithms nor a combiner that is 
restricted to a specific algorithm (or set of algorithms). The working 
group may of course change their opinion. So far only Paul (and Daniel 
Huigens?) have voiced the concrete interest in the X-Wing construction.

However, in the view of the upcoming NIST recommendations for KEMs in SP 
800-227, I propose to wait before the WG starts to engage in this 
discussion. It makes more sense to discuss this matter when a concrete 
standardized option is on the table – that is at least my view.

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

I share this view and I plead in favour of only considering in OpenPGP 
at maximum adopted work of other WGs, and ideally only such that has 
already reached a substantial degree of stability.

Best regards,
Falko

>> 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
>
> _______________________________________________
> openpgp mailing list [e-mail]
> To unsubscribe send an email [e-mail]
-- 

*MTG AG*
Dr. Falko Strenzke

Phone: [phone]
E-Mail: [e-mail]
Web: mtg.de <https://www.mtg.de>

------------------------------------------------------------------------

MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde

This email may contain confidential and/or privileged information. If 
you are not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email.Unauthorised 
copying or distribution of this email is not permitted.

Data protection information: Privacy policy 
<https://www.mtg.de/en/privacy-policy>