HKP keyservers over SSL

[Werner Koch]

On Thu, 12 Mar 2009 23:20, dshaw at jabberwocky.com said:

> annoyance for us.  If we needed some special TLS code in Curl, instead
> of doing something GPG-specific, it would be cleaner all around to
> implement the code in a general fashion and just give it to the Curl

Given that we "control" the then-to-be server code, we won't have any
problems with ugly servers which was one of the reasons to use Curl.
Actually the original GnuPG http code has support for GnuTLS and thus it
will be easy implement TLS directly.  The code might not be in GnuPG
proper, but I use copies of it in other projects.

One problem I have with Curl is that it is not GNU code and we would
like to have all main features of GNU software implemented by GNU code.
(Well, I know that David does not share this opinion.)

Anyway, we should first define the goals and then see how to accomplish
that.

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.

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.


Salam-Shalom,

   Werner

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