IETF Logo Mail Archive

Re: [openpgp] To bind or not to bind

Andrew Gallagher <andrewg@andrewg.com> Mon, 25 March 2024 11:47 UTC

Return-Path: <andrewg@andrewg.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 AD365C14F60D for <openpgp@ietfa.amsl.com>; Mon, 25 Mar 2024 04:47:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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=andrewg.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 1QRQxPkp_4WU for <openpgp@ietfa.amsl.com>; Mon, 25 Mar 2024 04:47:28 -0700 (PDT)
Received: from fum.andrewg.com (fum.andrewg.com [135.181.198.78]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D815C14F5E4 for <openpgp@ietf.org>; Mon, 25 Mar 2024 04:47:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=andrewg.com; s=andrewg-com; t=1711367245; bh=aQamLLtuN/mQWTeIuyuaK4DfSjlbasxqwnMaGt3vgVQ=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=rvUEgqHfr/2dVVmwYcaP+PV/p1lpLmEmc9ExAZB9rGexkOhi32lkOCIO9sXr5A1s3 Db1Hz4//yO7XlXOFxmqF3ouU2T1FWNU3Vkn1GIv7uMTWe63Yj4bEEVWr+BE68IXJ2A 2+1fM5501GMoeUl39diu23RfgV2YmBKIbpEHx84bwhR8JbzwrTnO9t7pin0E24BQ4v dWp+soq0pFDEUKdIM3vHISpS21jWBCGKeUk2Hloj97UpxHEiOa8CKBxDjCSiPvP+J6 BIffbYrFX9kIIJ4wpMThRcocM+xcD9Lvo9Kyz6cZWhmV2LBdpCEQZ3kxrEunBJfEpu WZTf6a2ggE0wQ==
Received: from smtpclient.apple (serenity [IPv6:fc93:5820:7349:eda2:99a7::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by fum.andrewg.com (Postfix) with ESMTPSA id 253405DC44; Mon, 25 Mar 2024 11:47:25 +0000 (UTC)
From: Andrew Gallagher <andrewg@andrewg.com>
Message-Id: <377BC725-0ACD-41F5-A034-4AE63AE33A4A@andrewg.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_26077E93-DCDE-4C7E-AA0D-FDCDCBB95284"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.1\))
Date: Mon, 25 Mar 2024 11:47:06 +0000
In-Reply-To: <10d79118-00ac-4192-8068-ded4a75c6350@mtg.de>
Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, IETF OpenPGP WG <openpgp@ietf.org>
To: Johannes Roth <johannes.roth@mtg.de>
References: <EGivTgyfjNm_TAvhds1OPA2c0O6LP9lFnkwWHHKLJY8ReJOgtDh3tnYsCSR8yrrBLbpeehtUgIJEhynae8L3daRimNiGO7BAb3cVvC66q-4=@wussler.it> <87y1a938fl.fsf@fifthhorseman.net> <10d79118-00ac-4192-8068-ded4a75c6350@mtg.de>
X-Mailer: Apple Mail (2.3731.700.6.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/sfatWRJB4Nk7CPLTX4i26VIPeAk>
Subject: Re: [openpgp] To bind or not to bind
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Mar 2024 11:47:32 -0000

On 25 Mar 2024, at 11:30, Johannes Roth <johannes.roth@mtg.de> wrote:
> 
> A non-SEIPDv2-capable PQC implementation does not seem surprising *if* we decide to allow PQC encryption for v4 keys since then you can implement it independently from the Crypto Refresh.

Agreed. If the entire point of v4 PQC is to enable the fastest possible rollout of PQC encryption, then restricting it to implementations that have already implemented (parts of) crypto-refresh would be counterproductive.

The analogy with the presumed SEIPDv1 feature flag is flawed, because the SED to SEIPDv1 upgrade is cryptographically urgent, i.e. we already say that people MUST NOT generate SED packets. We do not have a similar urgency for SEIPDv1 to SEIPDv2, so we do not have an equivalent justification to presume the SEIPDv2 feature flag. If we agree that PQC is compatible with SEIPDv1 for the purposes of accelerating PQC rollout for multi-recipient messages, then surely it is also compatible for the purposes of accelerating PQC rollout for single-recipient messages.

A

v2.23.0 | Report a Bug | By Email