Re: [openpgp] Bug#931238: hot armor: please drop "Version: " header

ilf <ilf@zeromail.org> Mon, 08 July 2019 10:49 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 6F06C120152 for <openpgp@ietfa.amsl.com>; Mon, 8 Jul 2019 03:49:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 M2drck9h_rxF for <openpgp@ietfa.amsl.com>; Mon, 8 Jul 2019 03:49:00 -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 098DD12014F for <openpgp@ietf.org>; Mon, 8 Jul 2019 03:48:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtpin.nadir.org (Postfix) with ESMTP id 5ACB57CAAA5; Mon, 8 Jul 2019 12:48:56 +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 a-AqMHU6r086; Mon, 8 Jul 2019 12:48:56 +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 203CD7CA980; Mon, 8 Jul 2019 12:48:56 +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 676C1BFE19; Mon, 8 Jul 2019 12:48:55 +0200 (CEST)
Date: Mon, 08 Jul 2019 12:48:52 +0200
From: ilf <ilf@zeromail.org>
To: openpgp@ietf.org
Cc: 931238@bugs.debian.org
Message-ID: <20190708104852.GH1362@zeromail.org>
Mail-Followup-To: openpgp@ietf.org, 931238@bugs.debian.org
References: <87zhm1o0f7.fsf@fifthhorseman.net> <20190706133941.tw3znn74q4iseiyo@scru.org> <54525144-b7bf-fa79-c497-ca8fbf77f89d@gmx.net> <8d960bb1-0fe8-c2e3-fcf4-4d00ed4adfce@rub.de> <1562550125588.27272@cs.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="jRdC2OsRnuV8iIl8"
Content-Disposition: inline
In-Reply-To: <1562550125588.27272@cs.auckland.ac.nz>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/WynQyL-9vfVFLe2Jau3jxpT83g8>
Subject: Re: [openpgp] Bug#931238: hot armor: please drop "Version: " header
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, 08 Jul 2019 10:49:05 -0000

Peter Gutmann:
> "An attacker knowing that you're running out- of-date software" barely 
> qualifies as a threat - they can just try and attack you anyway - and 
> I can't see what other purpose it serves. 

We had this debate three years ago over on gnupg-devel.

dkg posted a patch - which was merged in upstream GnuPG:

> 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

These were the original arguments:

> Since "Pervasive Monitoring Is an Attack" [2], let's minimize metadata 
> as much as possible, especially if it's unencrypted *and* not 
> cryptographically verifiable.
> The riseup.net "OpenPGP Best Practices" [3] refer to a gpg.conf [4] 
> which already implements "no-emit-version". I and many other people have 
> been using this with many implementations on many plattforms for a long 
> time, without any problems. So I see no technical reason against the 
> proposal.
> Even RFC 4880 lists no pressing reason for including this by default:
>> The Armor Headers are pairs of strings that can give the user or the 
>> receiving OpenPGP implementation some information about how to decode 
>> or use the message. [5]
> I can't see how "Version: GnuPG v2" tells me or an OpenPGP 
> implementation "how to decode or use the message".
> Let's just drop it.
> 2. https://tools.ietf.org/html/rfc7258
> 3. https://riseup.net/en/security/message-security/openpgp/best-practices
> 4. https://raw.githubusercontent.com/ioerror/duraconf/master/configs/gnupg/gpg.conf
> 5. https://tools.ietf.org/html/rfc4880#page-55

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

After it was merged, a pratical attack was published:

> Werner Koch:
>> You are right, the "Version:" has no technical meaning.
>> I just pushed dkg's patch to master.
> Thanks again for this. Even after the decision, I want to add a 
> real-world example of why this change helps against de-anonymization:
>> Both "French Maid" and Force (operating as "Nob") used the exact same 
>> brand of PGP software, a free brand called GnuPG. There are different 
>> brands of PGP software so it is noteworthy that both Force (operating 
>> as "Nob") and "French Main" used the same brand. Not only did Force 
>> and "French Maid" both use the same brand of PGP software, they also 
>> both used the same outdated version of that software, 1.4.12. Version 
>> 1.4.12 was released on January 2012, and was replaced with a new 
>> version by December 2012, and was one of several versions of GnuPG 
>> software. As such, both "French Maid" and Force (as Nob) were using 
>> the specific, older version of the GnuPG software, and neither of them 
>> replaced it with the other (free) version of GnuPG that came out 
>> thereafter. […]
>> There are also additional similarities between Force's (Nob's) and 
>> "French Maid's" PGP patterns. Both "Nob" and "French Maid" left 
>> certain default settings on their PGP software. For one thing, both 
>> "French Maid" and Force (Nob) left a "tag" that appeared on every 
>> message authored from their PGP key revealing the brand and version of 
>> PGP software they were using. This is akin to, for example, leaving 
>> the phrase "sent from my iPhone" on the bottom of one's emails but 
>> with greater detail: it would be akin to leaving a phrase like "sent 
>> from my iPhone 6 iOS 8.0.1." Leaving this "tag" on typically reveals 
>> that one is dealing with a fairly inexperienced user of PGP, because 
>> someone that regularly uses PGP to communicate would normally have 
>> changed their settings to omit this tag.
> http://www.justice.gov/sites/default/files/opa/press-releases/attachments/2015/03/30/criminal_complaint_forcev2.pdf
> http://www.networkworld.com/article/2904395/microsoft-subnet/mistakes-that-betrayed-anonymity-of-former-dea-agent-and-silk-road-investigator.html

After that, the OpenPGP "Version:" header was dropped across the 
ecosystem:

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

To sum up:

- there is no valid technical reason for it
- there are active attacks which have put people in jail
- it's now ecosystem standard not to generate it

So please:

1. let's drop it by default in other implementations, like hOpenPGP
2. let's edit rfc4880bis to "SHOULD NOT emit a Version: header"

-- 
ilf

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