HKP keyservers over SSL

[Phil Pennock]

On 2009-04-01 at 22:42 -0400, David Shaw wrote:
> I'm not against this, but there are a few practical caveats.  Libcurl  
> added SNI support around a year ago in 7.18.1 (assuming of course   
> that the backend crypto library supports it).  A year isn't very long  
> at all, so there are loads of libcurl installations that don't yet  
> have the proper version of libcurl (and/or openssl, etc).  On those  
> systems, we (meaning libcurl, really) can only do common name and  
> subject alternate name checks.  The three systems I just checked had  
> libcurl 7.16.3 (no SNI), 7.19.4 (SNI), and 7.15.5 (no SNI).  That does  
> not bode well for quick adoption.

hkps support is not out there now.  If hkps support means, in practice,
SNI support, then operators can rely upon this.  If it doesn't, we're
just perpetuating the continued poor state of affairs.

How about some notes on this in the README's "BUILD INSTRUCTIONS"
stating pretty much what you just said and strongly recommending this?
Ideally with ./configure CAPS WARNINGS if hkps support is requested but
this support is not present?

(I'm not requesting work of others and doing nothing myself; I worked on
better SNI support in a variety of tools yesterday and am planning on
extending the Perl/Python patches today/tomorrow to include server-side
support).

> Having said all that, I'm not sure if all this peer validation isn't a  
> bit of overkill.  My main desire for hkps is that the data on the wire  
> is encrypted to avoid casual snooping, and you don't need any peer  
> validation for that.

When some hotel or wifi AP has played funny buggers with DNS because
they don't understand that Internet != Web, it's useful to have tools
gracefully report the problem.  I like it when tools are able to report
that the problems are because it couldn't actually get an unmolested
connection to the server, rather than something else being wrong.  So if
verification is a simple enough hack, I'm all for it.

> Anyway, I might feel differently if it required a major code  
> commitment in GPG, but as things stand now, if the keyserver operators  
> want to band together and make sure their servers have a particular  
> cert setup and make the proper cainfo data available for clients who  
> want to use it, why not?

Okay, once SKS 1.1.1 is out with IPv6 support, my next patching effort
there is likely to involve TLS.

Thanks,
-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/385a27c7/attachment.pgp>