Keyserver/security bug 1447 (and 1446 too)

Daniel Kahn Gillmor dkg at
Sun Dec 2 17:13:33 CET 2012

On 12/02/2012 06:22 AM, Werner Koch wrote:
> On Sun,  2 Dec 2012 06:34, gnupg-devel at said:
>> Hi, wondering if the bug-tracker is considered stale and the devel
>> mailing-list is preferred, as there's been no reaction to a security
>> impacting bug (1447) while the lesser 1446 which was mentioned on-list
> I don't consider this a security bug.  Search for discussions related to
> TLS access to keyservers.  It has always been the case that you can get
> arbitrary data from keyservers.  Keyservers provide no security at all!
> They are just a convenient way to distribute keys which usually works.

I agree with Werner that the risk of tampering with the data is not an
issue here -- people can upload arbitrary data to the keyservers already.

But this is still a security issue.  In particular, people i've spoken
to want to use HKPS for one of (at least) two reasons:

 0) they trust the operator of a given keyserver to not leak or log
their queries.

 1) they know that a given keyserver is the place where revocation
certificates that they care about will be published (the keyserver in
question might not even be peered with the dominant pool).

For both of these, getting the identity of the keyserver right is
critical.  Being subject to DNS spoofing is not acceptable.

> Right, it might be used to inhibit the receiving of revocation
> certificates.  However, there are many other ways of doing that.  In
> case of a compromise, it is good practise to send out revocation
> certificates by private mail this has a better chance that they are
> actually noticed.

Not everyone who uses OpenPGP has an easy path from a mailbox to their
keyring.  And not everyone who needs to revoke their key knows everyone
they need to send the revocation certificate to.  It's a reasonable (and
simple) "best practice" to refresh your keyring from the keyservers
regularly to pull in updates.  HKPS lets you do this while potentially
limiting the exposure of your keyring contents to a single keyserver.


More information about the Gnupg-devel mailing list