Re: [openpgp] a new draft overlapping the WG draft

Werner Koch <wk@gnupg.org> Fri, 30 September 2022 11:42 UTC

Return-Path: <wk@gnupg.org>
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 62615C159A1F for <openpgp@ietfa.amsl.com>; Fri, 30 Sep 2022 04:42:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org
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 ixeFduGBT1Ec for <openpgp@ietfa.amsl.com>; Fri, 30 Sep 2022 04:42:15 -0700 (PDT)
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD7EC159828 for <openpgp@ietf.org>; Fri, 30 Sep 2022 04:42:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=jslHDt6mLNrgerVfa4uT3Wyd9OcxVV0/pXFGGnJzE18=; b=PN2PwcaApgBjIxpgby27vVUa5u 2HVolzedDmEkvZbJdW0sBmWTqQ81yjNpK3doiWOEtNDJsWNwUtD0veZbgoGNnl+nwLvG4uQ5hZulQ zeRFqRnouQ85WeOcUTFEIxEnbDJsH6suvlSqRCZ/REd1i94Z1A/C8RP7kHp5iPHLTrPM=;
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1oeEPA-0000hE-B2 for <openpgp@ietf.org>; Fri, 30 Sep 2022 13:42:08 +0200
Received: from wk by wheatstone.g10code.de with local (Exim 4.92 #5 (Debian)) id 1oeEOZ-0005yI-2D; Fri, 30 Sep 2022 13:41:31 +0200
From: Werner Koch <wk@gnupg.org>
To: Daniel Huigens <d.huigens=40protonmail.com@dmarc.ietf.org>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Peter Gutmann <pgut001@cs.auckland.ac.nz>, Kai Engert <kaie@kuix.de>, "openpgp@ietf.org" <openpgp@ietf.org>
References: <b8ddeb1e-fdbb-edab-3693-722c9e14f3d8@cs.tcd.ie> <SY4PR01MB6251E251B8E78D409D0EB4B6EE559@SY4PR01MB6251.ausprd01.prod.outlook.com> <4c1eb849-b699-6193-7018-f0e2a1e2b279@cs.tcd.ie> <tn-vD_NhJKfgTLH14qinAAV1DqqH82Z8bktVEYj_pwsWFj0bV1WgeuC30W30Ru20WlnEs2pJYR70itNmUMbhkXk9mY8Ro9DM0D0dets4lBk=@protonmail.com>
X-message-flag: Mails containing HTML will not be read! Please send only plain text.
Jabber-ID: wk@jabber.gnupg.org
Mail-Followup-To: Daniel Huigens <d.huigens=40protonmail.com@dmarc.ietf.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, Peter Gutmann <pgut001@cs.auckland.ac.nz>, Kai Engert <kaie@kuix.de>, "openpgp\@ietf.org" <openpgp@ietf.org>
Date: Fri, 30 Sep 2022 13:41:24 +0200
In-Reply-To: <tn-vD_NhJKfgTLH14qinAAV1DqqH82Z8bktVEYj_pwsWFj0bV1WgeuC30W30Ru20WlnEs2pJYR70itNmUMbhkXk9mY8Ro9DM0D0dets4lBk=@protonmail.com> (Daniel Huigens's message of "Tue, 27 Sep 2022 15:41:19 +0000")
Message-ID: <87edvtdr8b.fsf@wheatstone.g10code.de>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=Macintosh_Internet_chaining_Yakima_primacord_Active_Nerve_agent=Hali"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/4jYV0gnSt1JV7avWlx_rY0q6VmY>
Subject: Re: [openpgp] a new draft overlapping the WG draft
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: Fri, 30 Sep 2022 11:42:19 -0000

Hi!

and sorry for responding a bit late.  Kai called me to point me to this
discussion.  I simply missed that my openpgp folder had new activity.

On Tue, 27 Sep 2022 15:41, Daniel Huigens said:

> minus the parts that Werner thinks the DT got wrong". It's simply a
> continuation of ietf-rfc4880bis-10, without any of the changes the DT
> made after that (afaict). Perhaps that means Werner thinks the DT got
> everything wrong, I don't know.

Right and wrong: It is a continuation of ietf-rfc4880bis-10 but with the
changes the DT agreed upon up until only editorial changes were in the
queue and I left the DT.  Here is the list:

 - Rename the Additional Encryption Subkey key flag
 - Add Literal Data Meta Hash subpacket.
 - AEAD chunk size update as per openpgp-dt meeting on 2021-08-20
 - Explain the reset back to rfc4880bis-10.

The only major thing from the DT is the "AEAD chunk size update".  IN
fact that was the reason why the design time was set up after a
discussion between Stephen, dkg, and me on how to get out the stuck
rfc4880bis process we had been in for years after -10 (or maybe -08)
when new people turned up in the WG.

I left the DT after we agreed that only minor changes are left to be
done, like describing 448 exactly.  It came very much to a surprise when
I noticed that almost everything had been thrown over later on.

My new draft specifies what has been implemented and deployed by GnuPG
and RPN for many years now.  There is one additional thing (Literal Data
Meta Hash) which can help to fix a sometime claimed problem for signed
only data.

The next revision will include an updated AEAD spec for protected
private keys in case people really send protected private keys without
using an additional container.  I think 448 needs to be added too.

> In general, there are a number of things in the crypto refresh that seem
> to have strong indications of WG consensus. For example, there was a

Please don't forget that for each iteration of 4880bis we had a
consensus in the WG as well.  The new crypto-refresh thing has been
thrown into the WG without much discussion.  The original idea of the DT
was to get out of a lock/conflict in the WG but it turned out that the
private discussion and work by DT introduced more questions than it
should have solved.

> refresh (or some open MRs intended to update it) reflects the consensus
> better than rfc4880bis.

I am likely not the only one here who doubts that merge request are a
good way to discuss changes to a protocol.  Thus I challenge the idea
that there is a roigh consensuns in the WG on the crypto-refresh.

> reading of this suggestion would mean to keep neither of them. I think
> (almost) everyone in the WG agrees we want AEAD, and it's also part of

The question here is whether to add a third mode (GCM) instead of
restricting the new AEAD thing to just one mode (OCB) and dropping EAX
which is not needed anymore.

To me GCM is a no-go for OpenPGP.  It is bad enough that CMS seems to
have settled for it; no need for OpenPGP to follow that faulty path.

> OTOH, for AEAD encrypted private keys (using S2K identifier 253), the
> definitions in rfc4880bis and the crypto refresh are currently clashing.

Frankly, I see no problem to modify the use of AEAD to protect private
keys because that part has not been widely deployed and our suggestion
has always been not to rely on that protection.  Exchange of private key
material is anyway very special and requires organizational effort.


Salam-Shalom,

   Werner


-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein