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.