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

Justus Winter <justus@sequoia-pgp.org> Wed, 28 September 2022 10:27 UTC

Return-Path: <justus@sequoia-pgp.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 DA268C15C509 for <openpgp@ietfa.amsl.com>; Wed, 28 Sep 2022 03:27:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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
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 U2icZIqhIpNb for <openpgp@ietfa.amsl.com>; Wed, 28 Sep 2022 03:27:34 -0700 (PDT)
Received: from harrington.uberspace.de (harrington.uberspace.de [185.26.156.85]) (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 D2B09C1522AE for <openpgp@ietf.org>; Wed, 28 Sep 2022 03:27:33 -0700 (PDT)
Received: (qmail 9385 invoked by uid 500); 28 Sep 2022 10:27:30 -0000
Authentication-Results: harrington.uberspace.de; auth=pass (plain)
From: Justus Winter <justus@sequoia-pgp.org>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, "openpgp@ietf.org" <openpgp@ietf.org>
In-Reply-To: <SY4PR01MB6251E251B8E78D409D0EB4B6EE559@SY4PR01MB6251.ausprd01.prod.outlook.com>
References: <b8ddeb1e-fdbb-edab-3693-722c9e14f3d8@cs.tcd.ie> <SY4PR01MB6251E251B8E78D409D0EB4B6EE559@SY4PR01MB6251.ausprd01.prod.outlook.com>
Date: Wed, 28 Sep 2022 12:27:21 +0200
Message-ID: <871qrvn69i.fsf@europ.lan>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Rspamd-Bar: -
X-Rspamd-Report: R_MISSING_CHARSET(0.5) MIME_GOOD(-0.2) SIGNED_PGP(-2) BAYES_HAM(-0.199912)
X-Rspamd-Score: -1.899912
Received: from unknown (HELO unkown) (::1) by harrington.uberspace.de (Haraka/2.8.28) with ESMTPSA; Wed, 28 Sep 2022 12:27:30 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/SxOY73ly0tBG54Nbpa-dSSlLetk>
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: Wed, 28 Sep 2022 10:27:38 -0000

Peter Gutmann <pgut001@cs.auckland.ac.nz> writes:

> Stephen Farrell <stephen.farrell@cs.tcd.ie> writes:
>
>>It's come to our attention that a new draft [1] has been published that
>>basically aims to be an alternative to the WG draft. [2]
>
> Is anyone involved in the drafts able to do a tl;dr of the significant
> differences?

I want to shed some light on the process of how we got here.

I think it is informative to first look at the difference between
draft-ietf-openpgp-rfc4880bis-10 and
draft-koch-openpgp-2015-rfc4880bis-00:

% rfcdiff draft-ietf-openpgp-rfc4880bis-10.txt draft-koch-openpgp-2015-rfc4880bis-00.txt
% diff -u draft-ietf-openpgp-rfc4880bis-10.txt draft-koch-openpgp-2015-rfc4880bis-00.txt| head -n 39
--- draft-ietf-openpgp-rfc4880bis-10.txt        2021-01-11 13:46:29.817657601 +0100
+++ draft-koch-openpgp-2015-rfc4880bis-00.txt   2022-09-28 11:16:25.000000000 +0200
@@ -4,21 +4,35 @@

 Network Working Group                                            W. Koch
 Internet-Draft                                                GnuPG e.V.
-Obsoletes4880, 5581, 6637 (if approved)                       B. Carlson
-Intended status: Standards Track                                R.H. Tse
-Expires: 4 March 2021                                             Ribose
+Obsoletes: 4880, 5581, 6637 (if approved)                     B. Carlson
+Intended status: Standards Track
+Expires: 11 March 2023                                          R.H. Tse
+                                                                  Ribose
                                                              D.A. Atkins
+
                                                             D.K. Gillmor
-                                                          31 August 2020
+                                                        7 September 2022


                          OpenPGP Message Format
-                    draft-ietf-openpgp-rfc4880bis-10
+                 draft-koch-openpgp-2015-rfc4880bis-00

 Abstract

    { Work in progress to update the OpenPGP specification from RFC4880 }

+   { This version is on the Git head with rfc4880bis-10 before the great
+   refactoring.  That refactoring, dubbed crypto-refresh, basically
+   started from scratch with lots of re-formatting and switching to a
+   Gitlab based approach with merge requests mainly prepared in advance
+   by one of the chairs.  This was done despite that -10 was basically
+   ready for last call after a long iterative process adding feature by
+   feature with rough consent from the WG.
+
+   Due to the IETF submission system the draft has a new name but
+   nevertheless is the direct successor of draft-ietf-openpgp-
+   rfc4880bis-10 }

So, the only thing that draft-koch-openpgp-2015-rfc4880bis-00 adds is an
attack on dkg.  That alone should raise some concerns.

The text claims that the merge requests were mainly prepared by dkg.  Is
that correct?  Querying the forge reveals that 84 MRs were created by
dkg [0], and 129 MRs were not created by dkg [1].  Clearly, while dkg
was very active (in stark contrast to Werner, more on that later), the
MRs were *not* mainly prepared by dkg.

0: https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests?scope=all&state=all&author_username=dkg
1: https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests?scope=all&state=all&not[author_username]=dkg

Let's quickly rehash who was part of the design team.  As can be seen
from the first of many weekly reports sent to the openpgp-dt@ list,
Werner was part of the design team [2].

2: https://mailarchive.ietf.org/arch/msg/openpgp-dt/yFnDnsDCtqxj_p3OVTRiRZJx16A/

However, Werner showed up only twice, on 2021-07-30 [3] and 2021-08-13
[4], and then he delegated representing GnuPG in the design team to
Niibe [5].

3: https://mailarchive.ietf.org/arch/msg/openpgp-dt/QWQBj9bPnv89Yc16MDJEngK9hBA/
4: https://mailarchive.ietf.org/arch/msg/openpgp-dt/3tnIRWJ0UT6JLdjlIVJyioOvwgI/
5: https://mailarchive.ietf.org/arch/msg/openpgp-dt/Pm3V9q35vj3H3DuCxcTbMUgKqyM/

I think it is rich to on the one hand forgo participation in the design
team and not doing a years worth of work on the text, and on the other
hand attacking someone who did.

Let's now look at what dkg did.  As a starting point for the
crypto-refresh, dkg ported the document to a new toolchain (there was a
problem building the document with the old toolchain, which Werner
denied and ignored for months [6]).  Then, to make sure we didn't
accidentally miss any additions that were made in
draft-ietf-openpgp-rfc4880bis-10, dkg created a branch which contained
all changes in a fine-grained fashion suitable for discussion and
cherry-picking [7].  Combined with the toolchain work, this amounts to
185 commits by dkg.

6: https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/7
7: https://gitlab.com/openpgp-wg/rfc4880bis/-/commits/step-by-step/

Then, dkg grouped the commits, and offered them for consideration to the
design team as merge requests.  Often, when there was no immediate
consensus in the design team, he would create more than one merge
request per topic for our consideration.

This is what Werner refers to as "preparing merge requests in advance"
and "reformatting".  If anything, dkg should be complimented for doing a
great job combing through the old document, guiding our discussions
around individual topics, and doing generally annoying janitorial work.


Daniel did a great job summarizing the technical changes between the
documents [8].  I won't repeat those here.  The gist is that the
crypto-refresh is more secure, has more features, enjoys the broad
support of the implementer community (because the design team represents
all major implementations).  The changes that made the document are well
documented in the Gitlab project [9] with lots of discussion.  The
design team documented their work using weekly notes.  There is nothing
unbecoming to the process as Werner seems to imply.

8: https://mailarchive.ietf.org/arch/msg/openpgp/aqBy97lj2P4DVxTds0eKZDVdmms/
9: https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests?scope=all&state=merged

Clearly, draft-koch-openpgp-2015-rfc4880bis-00 was posted in bad faith
and tries to undo a years worth of work by the design team.


Best,
Justus