[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5404F7F5.8060609@fifthhorseman.net>
Date: Mon, 01 Sep 2014 18:49:25 -0400
From: Daniel Kahn Gillmor <dkg@...thhorseman.net>
To: oss-security@...ts.openwall.com
CC: Werner Koch <wk@...pg.org>, pkg-gnupg-maint@...ts.alioth.debian.org
Subject: Re: gpg blindly imports keys from keyserver responses
On 09/01/2014 02:33 PM, Thijs Kinkhorst wrote:
> Stefan Tomanek reported to Debian that GnuPG accepts any key as a response
> from a keyserver, regardless of whether that key was actually requested:
> https://bugs.debian.org/725411
>
> There's some discussion about the issue; we believe that the primary way to
> verify key ownership is still the web of trust and manual fingerprint
> verification. It is however argued that as a user, requesting keys based on
> specifying the full fingerprint is a safe way to retreive a key for a known-
> good fingerprint. But this argument is again somewhat countered by an attack
> on V3 keys which allows generating such fingerprints, making such a request
> dubious again.
v3 keys themselves are a hazard because of this fingerprinting forgery,
but i think that's a separate issue. But it's not possible to generate
a v3 fingerprint that matches a full v4 fingerprint because the length
of the fingerprint differs (v3 fingerprint is 128 bits, v4 is 160 bits).
So in some sense, it is reasonable to suggest that when requesting a
given key from the keyservers explicitly by fingerprint, users should be
able to rely on gnupg only adding *that key* (and the related OpenPGP
certificate) to the local keyring, if the remote keyserver provides a
matching key.
However, there are two problems: the most common situation where the
keyservers are queried by key (rather than by user id) is upon receipt
of a signed message that they can't verify. In this case, the only
thing the client has access to is the issuer id (the low 64 bits of the
fingerprint) which is not a particularly strong indicator (see recent
64-bit keyid collisions published by David Leon Gil).
Additionally, the "and related OpenPGP certificate" part is problematic,
even with correctly-functioning keyservers, because anyone could upload
a certificate with another pre-existing key as its subkey. A
well-behaving keyserver would be forced to return both the "legitimate"
certificate and the certificate with the extra subkey.
So avenues for third parties to force undesirable keys on users exist
even with this streamlining.
--dkg
Download attachment "signature.asc" of type "application/pgp-signature" (950 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
