HKP keyservers over SSL

[Phil Pennock]

On 2009-04-01 at 11:27 -0400, Daniel Kahn Gillmor wrote:
> Put another way:
> 
>  * HKP-over-TLS only really makes sense when connecting to a known,
> identifiable keyserver.

My understanding is that part of the rationale for HKP-over-TLS is
simply to defeat traffic snooping and to talk to a set of keyservers
somewhat trusted to respect privacy and that total privacy is not a
major driver.

I can well see people wanting to talk to keys.gnupg.net and just to have
some reasonable confidence that the communications are private, ie that
they're talking to the keys.gnupg.net pool so no MitM to sniff.  So a
private CA supported by the client works here.  The pool maintainer can
add certs.  The only issue is revocation, which is an issue what exists
whether the server certification is done via host PGP identities or via
x509 certs -- ie, the same issues exist for both and the client
verification logic needs to exist for both, so the complexity is
equivalent.

> If we're talking about doing more work to support a TLS extension, I'd
> rather see RFC 5081 be adopted (using reasonable certificates) than 4366
> (ways to use multiple unreasonable certificates).

First, note that curl natively and automatically supports SNI if the SSL
library supports it, AFAICT.  NSS might be an exception.  GnuTLS support
is used, and if OpenSSL is recent enough and built with support for SNI
then curl will automatically use it.  Yesterday I wrote patches for some
common tools to support using SNI as a client -- it's extremely simple:
check the hostname isn't an IP address, then issue one call against the
handle to add some metadata that will be used later on.

So the SNI support requirement for GnuPG is to make sure that non-Curl
shims support this (trivial) and to document that hkps verification to
pools is dependent upon the backend -- GnuTLS always works, OpenSSL
depends upon the install (version and build options) -- again trivial.

Second, where does this "unreasonable" spring from?  If the CA is the
pool operator, so any pool operator is their own CA with no costs to
enter the "market" beside perhaps getting the tool vendors (GnuPG) to
include their CA cert when shipping then there's no artificial barriers
to participation, no artificial revenue streams and things work simply
using existing, tested, tools and libraries.

> However, i think that the arguments for using HKPS tend to suggest that
> a user would want to use a single known keyserver (or at least a pool
> maintained by the same administrator who can give them all the same host
> keys or get them all independently certified).

Perhaps some will.  And they'll pay for access to a pool of resilient
servers because it's worthwhile to them.  Heck, client SSL verification
comes in.

As I understand matters, as a keyserver operator, it's rare for any
organisation to run more than one or two keyservers.  Most pools are
just collections of keyservers run by someone else.  HKPS lets you talk
to those pools without your local network traffic showing, in the clear,
who you want to talk to.

I use a laptop.  I use wifi.  For work access, I have a VPN.  For
private stuff, I have SSH, SMTP-Submission-STARTTLS, IMAP/SSL and
IMAP/STARTTLS, HTTPS to private websites, etc.  If I compose email and
retrieve keys for the mail, at the moment the key retrieval is the only
part which leaks, over the coffee-shop wifi, anything to do with who I'm
communicating with.  The IMAP and SMTP all go to fixed servers.

I want to be able to have that be private too, whether it's at a
cafe/diner or at a conference filled with people giving demonstrations
of wifi traffic interception.

So a design which supports remote endpoint verification to have privacy
with MitM protection and which lets the pool maintainers be different
from the keyserver operators is a win; if the design can offer more than
that, great, but if it can't offer that much, it loses.  With SNI, each
keyserver can be part of various pools for various constituencies
affiliated with the keyserver operator without any one acting to inhibit
membership in another pool (at a technical level; conflicting
hypothetical maintenance certification standards could reintroduce
that but then the keyserver operator can choose, in a *free* market,
which pools matter most to them and if they, eg, want to just run two
keyservers).

-Phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: </pipermail/attachments/20090401/88f47610/attachment.pgp>