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.
- Re: [openpgp] Bug#931238: hot armor: please drop … Clint Adams
- Re: [openpgp] Bug#931238: hot armor: please drop … Heiko Stamer
- Re: [openpgp] Bug#931238: hot armor: please drop … Marcus Brinkmann
- Re: [openpgp] Bug#931238: hot armor: please drop … Daniel Kahn Gillmor
- Re: [openpgp] Bug#931238: hot armor: please drop … Daniel Kahn Gillmor
- Re: [openpgp] Bug#931238: hot armor: please drop … Peter Gutmann
- Re: [openpgp] Bug#931238: hot armor: please drop … ilf
- Re: [openpgp] Bug#931238: hot armor: please drop … Marcus Brinkmann
- Re: [openpgp] Bug#931238: hot armor: please drop … ilf
- Re: [openpgp] Bug#931238: hot armor: please drop … Heiko Stamer
- Re: [openpgp] Bug#931238: hot armor: please drop … Daniel Kahn Gillmor