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

[Falko Strenzke <[e-mail]>]

Hi Britta,

thanks a lot for your valuable input to our proposed draft. However, we 
think there might be a general misunderstanding about the nature of 
draft-ehlen-openpgp-nist-bp-comp. Namely, this draft only adds further 
parameter sets to draft-ietf-openpgp-pqc and borrows all cryptographic 
constructions from there. This is stated in Section 1.4 
<https://www.ietf.org/archive/id/draft-ehlen-openpgp-nist-bp-comp-00.html#name-applicable-specifications-f> 
and specifically for the KEM combiner in Section 5.2.2 
<https://www.ietf.org/archive/id/draft-ehlen-openpgp-nist-bp-comp-00.html#name-key-combiner>. 
Note that the main document draft-ietf-openpgp-pqc has already been 
adopted by the WG, although it is not finalized, yet.

Accordingly, the general design choices have to be discussed with 
respect to the main document draft-ietf-openpgp-pqc and the only issue 
that really concerns draft-ehlen-openpgp-nist-bp-comp by itself is the 
choice of parameter sets or, like Daniel argues, questioning the need 
for additional parameter sets in the first place.

Our suggestion is that you read draft-ietf-openpgp-pqc and check which 
of your critique you want to bring to the OpenPGP working group. This 
draft also has a Security Considerations section which hopefully 
contains the justifications you are looking for.

We want to proactively address some of the concerns you raised under the 
assumption that you direct it against draft-ietf-openpgp-pqc as well.

     1. /WG appropriateness./

We clearly think it is appropriate for the OpenPGP WG to work on the PQC 
integration into OpenPGP. This is conformance with the current charter. 
And we are not specifying new cryptographic algorithms, thus there is 
not per se a need to ask CFRG. Our composite constructions are 
straightforward and come with security considerations. That being said, 
of course we are open to concrete proposals for change — any input is 
welcome.

     2. /Goal ambiguity./

Specifying encryption and signature in draft-ietf-openpgp-pqc was agreed 
on by the working group. We don’t see how this is violating any 
established principle. In OpenPGP this was already practiced for ECC in 
RFC 6637. We believe that such decisions are within the freedom of the 
working group.

     3. /Overlap with other efforts./

We are aware that there is a design team in CFRG working on KEM 
combiners and one of the authors of draft-ietf-openpgp-pqc is involved 
in the team. However, so far no concrete constructions have been 
presented. Once that is the case early enough in the process of 
finalizing draft-ietf-openpgp-pqc, we are happy to check whether we can 
adopt such a construction. Currently, we are awaiting the publication of 
[1]. We will then check if we can adopt a construction from NIST. This 
would be indeed our preferred choice. But ultimately, such decisions are 
up to the OpenPGP working group.

Furthermore, we are regularly in dialogue with the authors of the 
corresponding LAMPS drafts. In particular the considerations for PQC 
integration into the CMS protocol within LAMPS share some similarities 
to considerations for OpenPGP. Our dialogue with LAMPS is mainly thanks 
to Mike Ounsworth’s continued efforts to align the different groups 
regarding matters of the PQC integration. This sometimes happens in the 
official meetings, sometimes in GitHub issues in our draft repo, and 
sometimes in off-list discussions. We recently agreed to check a 
possible alignment of our KEM-combiner construction with LAMPS after the 
publication of SP 800-227 and to present the similarities and 
differences we end up with to other IETF groups (most likely in a PQUIP 
session).

You mention that there are “efforts in […] PQUIP for KEM combiners, 
signature combiners”. This sounds as if PQUIP was working on 
cryptographic mechanisms, which is something that is explicitly 
precluded by their charter.

     3. /Lack of formalism and security goals clarity./

These issues probably mostly concern the main draft 
draft-ietf-openpgp-pqc, unless the “lack of formalism” really applies to 
aspects of this draft that are not present in the “main draft”. We think 
that some of the issues you might have identified could already turn out 
to be covered by the “Security considerations” section of 
draft-ietf-openpgp-pqc but we acknowledge that it could be a good idea 
to refer (in the main draft, however) to your (more recent) work 
“draft-ietf-pquip-hybrid-signature-spectrums” and the security notions 
mentioned in it.

Best regards,

Falko and Stephan (as authors of draft-ehlen-openpgp-nist-bp-comp and 
draft-ietf-openpgp-pqc)

[1] National Institute of Standards and Technology (2024) 
Recommendations for key- encapsulation mechanisms, (National Institute 
of Standards and Technology, Gaithers- burg, MD), NIST Special 
Publication (SP) 800-227. [Forthcoming; will be available at 
https://csrc.nist.gov/publications]

Am 28.08.24 um 19:07 schrieb Hale, Britta (CIV):
>
> 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]
> 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>
>
>
> _______________________________________________
> 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>