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

Daniel Huigens <d.huigens@protonmail.com> Wed, 28 August 2024 18:30 UTC

Return-Path: <d.huigens@protonmail.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9B3C169439 for <openpgp@ietfa.amsl.com>; Wed, 28 Aug 2024 11:30:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.103
X-Spam-Level:
X-Spam-Status: No, score=-7.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaoFTksYNHMr for <openpgp@ietfa.amsl.com>; Wed, 28 Aug 2024 11:30:43 -0700 (PDT)
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB32C14CF12 for <openpgp@ietf.org>; Wed, 28 Aug 2024 11:30:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1724869841; x=1725129041; bh=I37s6U6693Xvuk765MDQB1Iw+q/NSYFmrYhYAk+PRug=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=EMHg8Yv57Pby8OlxA/af2AJw3THNhxR9qvAGzfuseUWRb6xN08lCHD2MhWCoETGAe ClmaNzeVZTHH9WXyrrSADKKgMAQVvJ/yHeWlOTNqBCdj/29u5Hl9ho47gkIYFqH1yl v/h5vC5Eci+qEwda7lZRpmspL83r38pxVJULhcRV+wquiVPqA8icrpy/bfikw6duzv dvxyCtEUZTolBl6F+4WEX9LGIUsN2DRRNredrPX2KenKYOsfXgPhcUbbcp89N9MeDZ ggNvrPV9H02Bzp/H+9KBJXVvxIaB5Ql6GMEQ+OjW+WRxNGD4f56QpDKaN8ObyykJnc 7EJG/FjReBFDA==
Date: Wed, 28 Aug 2024 18:30:36 +0000
To: "Hale, Britta (CIV)" <britta.hale@nps.edu>
From: Daniel Huigens <d.huigens@protonmail.com>
Message-ID: <7P85siRUVGN1rH3B41I7xtttbhCKXSdwl1aYHp6L7CmeBkIUa9bueefXsR2y2Xo27J5JZocIvz71oik_Nh9v_5k695Cky_8hEEpFXQsNqVk=@protonmail.com>
In-Reply-To: <D753AC29-A81C-49D8-B9A0-7FF0E443D3B8@nps.edu>
References: <563556e4-6a57-41e5-a8da-ae1ff27c08c6@mtg.de> <D753AC29-A81C-49D8-B9A0-7FF0E443D3B8@nps.edu>
Feedback-ID: 2934448:user:proton
X-Pm-Message-ID: 1bb9bc023b30da5c4c5037950372561b4fc0be1f
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_TfpvKQ5NiL6CSG5kulpN2Z2vUnuMotmdoquGEAQC2U"
Message-ID-Hash: JFBLZUR23MXFXMV3EV4JRGV33QAM2IRL
X-Message-ID-Hash: JFBLZUR23MXFXMV3EV4JRGV33QAM2IRL
X-MailFrom: d.huigens@protonmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-openpgp.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Falko Strenzke <falko.strenzke@mtg.de>, "openpgp@ietf.org" <openpgp@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [openpgp] Re: call for adoption of draft-ehlen-openpgp-nist-bp-comp?
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/SXYCQOb8tA43vnJhnWfiXBphWnU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Owner: <mailto:openpgp-owner@ietf.org>
List-Post: <mailto:openpgp@ietf.org>
List-Subscribe: <mailto:openpgp-join@ietf.org>
List-Unsubscribe: <mailto:openpgp-leave@ietf.org>

Hi all,

I (perhaps predictably) have another concern, which may need to be discussed in the CFRG instead as Britta suggests.

As I've said in the last meeting, in my view the traditional (non-PQ) component of the hybrid algorithms is there purely as a fallback, and thus there should be less of a need for flexibility there. Therefore, in my view this draft doesn't add much beyond [draft-ietf-openpgp-pqc](https://www.ietf.org/archive/id/draft-ietf-openpgp-pqc-03.html).

Compliance concerns have been brought up, but AFAIU it's been established that NIST requires only one component of a hybrid algorithm to be FIPS-compliant, and as for the BSI, [my last message on the topic](https://mailarchive.ietf.org/arch/msg/openpgp/Ktjhk3TGU4EIgeE3yeqmIwaENmw/) wasn't answered, so it seems to be unclear.

I understand that, given that the OpenPGP algorithm registries have been marked as "Specification Required", anyone could register these algorithms if the Designated Expert (which we don't have yet) agrees, but I would still prefer not to endorse them in the WG, as they seem superfluous to me.

Alternatively, if there's a reason for adding these algorithms that I've missed, I think it would be good to add a clearer justification of the need for this draft before the call for adoption, either here or in CFRG.

Best,
Daniel

On Wednesday, August 28th, 2024 at 19:07, Hale, Britta (CIV) <britta.hale@nps.edu> wrote:

> 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 <falko.strenzke@mtg.de>
> Organization: MTG AG
> Date: Wednesday, August 28, 2024 at 5:55 AM
> To: "openpgp@ietf.org" <openpgp@ietf.org>
> 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: +49 6151 8000 24
> E-Mail: falko.strenzke@mtg.de
> 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)