[openpgp] Re: call for adoption of draft-ehlen-openpgp-nist-bp-comp?

["Hale, Britta (CIV)" <[e-mail]>]

All,

I have several concerns about this draft:

1) WG appropriateness.
There is very little in this draft that is unique to OpenPGP. While I applaud the early leaders in pushing PQ standards in the IETF for their efforts, in whatever working group would take initiative, now that things have come to a more mature standing and the first NIST standards are out, being systematic would be wise, so that the right WGs are reviewing and correlating these. Otherwise we risk a mayhem of individual standards draft spread across the IETF all offering their own versions of ‘ML-KEM’ or ‘ML-KEM’ hybrid unique to the different WGs.

Traditionally, the CFRG is the WG to set the guidelines for algorithms (which algorithm combiners still are). In my opinion, PQUIP for general coordination and the CFRG for specific algorithm drafts are the right places for this. It is not reasonable to assume that everyone in OpenPGP is tracking PQUIP or the CFRG, which can also be seen in the dearth of comments on the OpenPGP mailinglists. As a consequence, few here may pick up on the fact that the terminology in this draft differs from several documents already tracked by PQUIP, and the overlap with existing KEM and signature combiners is not made clear here. Such clarity would be well handled in CFRG if we do not break from the norm of algorithms going to them. Other combiners presented in PQUIP have been similarly sent to CFRG, so it would be concerning if a given non-CFRG WG presses ahead on a solo versions.

Note that this is equally important on substantive cryptographic drafts and non-substantive (i.e., regardless of how cryptographically invasive a combiner is or is not, or even whether or not there is a combiner at all). We need clarity and consistency in IETF algorithms, vs. 20 different “ML-KEM combiner” standards for 20 different WGs, and it requires responsibility by all WGs to ensure that does not happen. After all, we do not currently have 20 different standards for AES, so it is best to avoid incurring the ensuant complexity when going into post-quantum efforts. If this draft is sufficiently different from others in CFRG, then the clarity of different security or use goals, etc. will be handled there with guidance on ensuring the right language in the draft to make that clear.

2) Goal ambiguity.
The goals of this draft mix of KEM combiners and signatures. These are very separate algorithm types. We (the IETF, NIST standards, ISO, etc.) do not historically mix those into a single draft. This is even more important as the relative security goals aimed for each combiner in the draft are different: the KEM aims to achieve strong non-separability, whereas the signature combiner does not even aim to achieve weak non-separability. It would seem appropriate to break these into distinct drafts.

3) Overlap with other efforts.
There are multiple efforts in the CFRG and PQUIP for KEM combiners, signature combiners, etc. This draft does not reference any of those and I note overlaps in the proposed efforts. If the draft was routed through the correct WGs (e.g., CRFG and PQUIP) it could likely achieve deduplication and also consistency in terminology and presentation. Only protocol-specific draft (i.e., protocol combiners, not algorithm combiners) seem appropriate for other WGs – this goes back to item (1).

3) Lack of formalism and security goals clarity.
There is also a lack of clarity in formalism in this draft:  the signature combiners listed are a ‘parallel’ approach but their security is not stated as such (esp. see PQUIP drafts on this). Also, the signatures are listed as “composite” but are not according to the PQUIP terminology draft (they are hybrid only). The goals for doing combiners are frequently security goals, so precision on those is very important in order to assess whether or not the draft is even achieving its own intent.


Given all of the above, I recommend that the draft be moved instead to CFRG. If the combiner is an approved algorithm, then OpenPGP will be able use the code points for that and there is the added bonus that if it has wider applicability other WGs can also use them. If further protocol customization for *how* OpenPGP applies an algorithm is needed, that can be achieved in a separate draft, and does not seem to be a goal of this draft anyway.


Britta



From: Falko Strenzke <[e-mail]>
Organization: MTG AG
Date: Wednesday, August 28, 2024 at 5:55 AM
To: "[e-mail]" <[e-mail]>
Subject: [openpgp] call for adoption of draft-ehlen-openpgp-nist-bp-comp?

NPS WARNING: *external sender* verify before acting.


Dear OpenPGP Chairs,

at IETF 120 we presented our draft introducing the PQ/T composites with NIST and Brainpool curves https://github.com/openpgp-pqc/draft-ehlen-openpgp-nist-bp-comp.

In the meeting Stephen said the working group would be given some time to read the draft and then a call for adoption would be issued. Given that the content of the draft is not substantially new but is more or less the content that was branched off from the already adopted draft-ietf-openpgp-pqc, it seems to me that the six weeks that have since passed should be enough time. Are the chairs ready to issue the call for adoption any time soon?

Best regards,
Falko
--


MTG AG
Dr. Falko Strenzke

Phone: [phone]
E-Mail: [e-mail]<mailto:[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>