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.
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp