HKP keyservers over SSL

[David Shaw]

On Fri, Mar 13, 2009 at 09:22:16PM +0100, Werner Koch wrote:

> What we want is to make it harder to see what keys are fetched from the
> keyserver: Obviously that should be done with TLS and we need to
> authenticate the server to avoid MITM attacks.  For the latter we have
> several options:
> 
>   1. Use a full fledged X.509 based TLS authentication in the standard
>      way, i.e. requiring the server to use a well known root
>      certificate.  This can be done using any GPLv3 compatible TLS code.
>     
>   2. Same as one but use an OpenPGP certificate.  This requires GnuTLS.
> 
>   3. Use a list of server certificate fingerprints and compare against
>      them.  For example in the DNS which is secure enough for our threat
>      model.  Recall that the servers can still track key requests.
> 
>   4. Extend X.509 to allow optional authentication using an OpenPGP
>      certificate.  This general mechanism can also be used for all kind
>      of projects.  It would allow to get better server authentication
>      while still keeping standard HTTPS semantics.  There are several
>      ways on how to implement it; for example by creating an OpenPGP
>      certificate with a user ID made up of the keygrip of the regular
>      X.509 certificate.
> 
>   5. Forget about this all and implement it properly using an anonymizer
>      service.  That service needs to batch up queries and insert dummy
>      queries.  Should not be to hard to get this implemented in TOR.
> 
>   6. Replace the keyserver stuff using a GNUNet service.  That would
>      soon lead to the question why not to replace encrypted email as we
>      are used to entirely by a p2p system.  So, better forget about this
>      for now.
> 
> The more I think about it, option 5 (enhanced TOR) looks more and more
> promising.  The basic question is why to come up with a limited
> anti-surveillance mechanism if we could get a strong one as well.  I am
> pretty sure that a few years after the major keyservers will speak TLS,
> real anonymity will be requested and then we can start from scratch.

Personally, I like both options 1 and 5.  I like the TOR idea (5) a
lot.  It's a clever way to work around some of the limitations of a
public keyserver network.  In the immediate sense, however, I see no
reason to not support some of the other options as well.  A
TLS-wrapped hkp (1) does not affect a TOR implementation (and can, in
fact, be used with a TOR implementation), and gives protection against
casual snooping by a third party of which keys are being requested.
So doing (1) does not block us from doing (5) either soon or in the
future, plus even in the absence of TOR, (1) means more encryption on
the wire, which is generally good for network hygiene.

> Regarding authenticated writes to the keyservers (user certificates): I
> don't think that this will ever take off.  It would be the first step to
> a managed PKI and we all know that PKIs don't work.  I see no benefits
> for that.

I can see a use case for user certs to create private keyservers, but
that's a fairly limited use case.

I wonder if client certs might be more useful for server to server
communications, rather than the client to server communications.  The
catch, of course, is that given how the keyserver gossip protocol
works, a given keyserver pool must be willing to exclude everyone who
does not similarly use client certs.

David