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

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

Falko et al.,

The response below does not change the original issues raised. Most notably, this is a quickly changing space and approaches and alignment throughout the IETF need to take that into account. As previously pointed out, there the early efforts in PQC are laudable, but obviously singular efforts in individual working groups will eventually backfire across standardization if not correlated. A lack of formality and clarity of security goals in earlier efforts is not a basis for continuance of such.

It is a good that you are taking the initiatives for coordination as described below, namely: “We recently agreed to check a possible alignment of our KEM-combiner construction…”. That is an excellent step towards better interoperability and consistency focus in standardization. However, I note that this is presented as a future effort and the call for adoption is now. That undermines its own goal. Moreover the agreement “… to present the similarities and differences we end up with to other IETF groups” does suggest mitigation of any differences, nor does presentation in PQUIP suggest such an effort since algorithms are not defined there. Algorithm coordination takes place in CFRG, if anywhere. It would be better to take stock in similarities and differences before divergence occurs and ensure consistency, as a precursor to adoption. Given that the goal of this draft is to “add parameter sets” only, it should not be onerous to achieve a more singular and coherent view in the IETF of such parameter sets. This allows for very short drafts on any WG-specific adjustments as has been done historically with other ciphers.

Britta


From: Falko Strenzke <[e-mail]>
Organization: MTG AG
Date: Tuesday, September 3, 2024 at 9:37 PM
To: "Hale, Britta (CIV)" <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "Ehlen, Stephan" <[e-mail]>
Subject: Re: [openpgp] Re: call for adoption of draft-ehlen-openpgp-nist-bp-comp?


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.

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

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

  1.  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]><mailto:[e-mail]>
Organization: MTG AG
Date: Wednesday, August 28, 2024 at 5:55 AM
To: "[e-mail]"<mailto:[e-mail]> <[e-mail]><mailto:[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>



_______________________________________________

openpgp mailing list -- [e-mail]<mailto:[e-mail]>

To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
--


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>