Re: gpg blindly imports keys from keyserver responses

[Daniel Kahn Gillmor <dkg () fifthhorseman net>]

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

Attachment: signature.asc
Description: OpenPGP digital signature