[openpgp] don't emit version armor header by default

ilf <ilf@zeromail.org> Mon, 03 May 2021 18:58 UTC

Return-Path: <ilf@zeromail.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 748B53A0542 for <openpgp@ietfa.amsl.com>; Mon, 3 May 2021 11:58:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.297
X-Spam-Level:
X-Spam-Status: No, score=-1.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eS588qo2WbuK for <openpgp@ietfa.amsl.com>; Mon, 3 May 2021 11:58:29 -0700 (PDT)
Received: from smtpin.nadir.org (fry.nadir.org [217.114.68.218]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A05ED3A04BC for <openpgp@ietf.org>; Mon, 3 May 2021 11:58:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtpin.nadir.org (Postfix) with ESMTP id 942627D220C for <openpgp@ietf.org>; Mon, 3 May 2021 20:58:24 +0200 (CEST)
Received: from smtpin.nadir.org ([127.0.0.1]) by localhost (fry.nadir.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1dDBVn8RI7c for <openpgp@ietf.org>; Mon, 3 May 2021 20:58:24 +0200 (CEST)
Received: from snail.zeromail.org (mail.zeromail.org [217.114.68.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpin.nadir.org (Postfix) with ESMTPS id 58DC37D21F3 for <openpgp@ietf.org>; Mon, 3 May 2021 20:58:24 +0200 (CEST)
Received: from [127.0.0.1] (localhost [127.0.0.1])ng TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by snail.zeromail.org (Postfix) with ESMTPSA id 11FEEBFB76 for <openpgp@ietf.org>; Mon, 3 May 2021 20:58:21 +0200 (CEST)
Date: Mon, 3 May 2021 20:58:15 +0200
From: ilf <ilf@zeromail.org>
To: openpgp@ietf.org
Message-ID: <YJBHx5fvQ3qOCSvN@zeromail.org>
Mail-Followup-To: openpgp@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/wwNIzmRlfqUcwJRxVDbLECKvS9s>
Subject: [openpgp] don't emit version armor header by default
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
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, 03 May 2021 18:58:34 -0000

(I'm not an expert if this is the correct time for this - I hope so. :)

Currently, Section 6.2 sais:

> Currently defined Armor Header Keys are as follows:
> "Version", which states the OpenPGP implementation and version used to 
> encode the message.

https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-03.html#section-6.2-10

I propose to add this sentence:

> To minimize metadata, implementations SHOULD NOT emit this key and its 
> corresponding value except for debugging purposes with explicit user 
> consent.

We discussed this on gnupg-devel in 2016 and here in 2019. Then, dkg 
explained:

> The version of GnuPG in use is not particularly helpful.  It is not 
> cryptographically verifiable, and it doesn't distinguish between 
> significant version differences like 2.0.x and 2.1.x.

> Additionally, it leaks metadata that can be used to distinguish users 
> from one another, and can potentially be used to target specific 
> attacks if there are known behaviors that differ between major 
> versions.

> It's probably better to take the more parsimonious approach to 
> metadata production by default.

https://lists.gnupg.org/pipermail/gnupg-devel/2016-August/031424.html

See this example for a real-world attack: 
https://www.csoonline.com/article/2904395/mistakes-that-betrayed-anonymity-of-former-dea-agent-and-silk-road-investigator.html

This is rough consensus and running code in all implementations I can 
find:

GnuPG: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=c9387e41db7520d176edd3d6613b85875bdeb32c
GPGTools: https://github.com/GPGTools/MacGPG2/commit/831c2ed77d2ce88134ad4d689414051dc99dc3b3
SKS: https://bitbucket.org/skskeyserver/sks-keyserver/commits/4af75b3526d9
LibTMCG: http://git.savannah.nongnu.org/cgit/libtmcg.git/commit/?id=2c8a6861ab839cb58b6483a04a7b584423a27811

If this gets adopted, we should probably remove it from this example: 
https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-03.html#name-example-of-an-ascii-armored

Thanks, and keep up the good work!

-- 
ilf

If you upload your address book to "the cloud", I don't want to be in it.