Bug#519333: gnupg: Please include support for encrypted keyserver queries [PATCH]

[Werner Koch]

On Mon, 23 Mar 2009 17:25, dkg at fifthhorseman.net said:

> Actually, i do run one of the public keyservers.  Even if i didn't,
> there are some keyservers run by organizations which i believe have my
> interests in mind more than others.  For example, i might prefer an
> organization who commits to the following behaviors:

Okay, so a reason for using TLS would be a private or company keyserver.
I can see that an the wish t use use TLS instead of a VPN.

> I agree that it should be impossible for a malicious keyserver to forge
> new signatures.  However, a malicious keyserver could non-detectably
> strip signatures (e.g. removing revocation certificates, or certificates

Which happened in the past oft enough due to buggy keyserver codes and
we can't be 100 percent sure that this won't occur in the future again. 

> But not all keyservers have enough guaranteed traffic, and not everyone
> wants to (or can afford to) saturate the network with filler queries.

Anonymity comes at a price.

> Furthermore, tor introduces an additional communications delay and a
> layer of fragility to keyserver queries.  Have you ever run "gpg
> --refresh-keys" on a keyring with several hundred entries?

Yes, this takes long even without TLS

> My threat model is a motivated attacker looking to glean information
> about the relationships of interest to a particular entity based on
> their keyserver queries.  Since many keyservers are on fairly public
> network segments (in colocation facilities, for example), the
> opportunity for sniffing traffic at the very least is high for an
> attacker with moderate resources.

A big local keyring will be helpful.  The only problem is that gpg is
too slow for this.  For refreshing keys you would randomly select some
keys to refresh in addition to those you really need to refresh.

> servers and clients using SSH and TLS).  Regular connections to a
> keyserver to check for updated keys, etc, can leak a significant amount
> of information about (for example) who is authorized to access a given
> service.  A large organization using OpenPGP for this type of

The question is how to setup a reliable revocation service.  I don't
think that keyservers are the proper solution.  Keyservers have a
similar problem as CRLs do.  OCSP has other problems - it is all a mess.

We better don't mix this up with the TLS thing; that might be useful
even without a reliabale revocation service..

> Could you point me toward some examples or something i should read up on
> to better understand the vulnerabilities?  Without functional revocation
> certificates, the OpenPGP infrastructure is significantly weaker than
> i'd like it to be.

We learned in the past that some keyservers garbled the OpenPGP keys.
We have some fixes in gpg to remove invalid packets and those packets
might be revocation certificates.  It does not happen often but
keyservers employ similar code and we don't know what people can do with
a targeted attack on the keyservers and thus eventually on gpg.  Right
that will be DoS - people will in turn not refresh their keys to avoid
the trouble of waiting to send out the encrypted mail.

> Could you propose a different mechanism that you feel is superior?  I'm
> happy to evaluate alternatives, as i quite like the public keyserver
> network as i understand it (though i'm concerned by your unsettling
> remark above about the ease of corruption of public keyservers).

The data on the keyservers will technically not get corrupted but a DoS
would add so man valid packets to a keyserver that the net effect of
such a DoS is the same as corrupted data.  Consider a well known key,
with a a couple of thousand bogus signature packets and the time it
takes for the keyservers and far worse for all clients to filter them
out.

> I hope moving this to gnupg-devel is the right place.  It may also be
> relevant to ietf-openpgp if you have serious qualms about the utility
> revocation certificates in general.  It may also be of interest to

OpenPGP provides the message format but no operational advice on how to
setup a PKI or a revocation services.  Thus this is out of scope for the
WG.  However, we have used the WG list for such discussion in the past
because all the OpenPGP people should be on this list, which is not the
case for gnupg-devel or sks-devel.  The format is not the problem, the
reliable service is the problem.


Salam-Shalom,

   Werner


ps.  Sorry, for the late replay, I was a bit too busy with other
projects the last weeks.

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.