HKP keyservers over SSL

[David Shaw]

On Apr 2, 2009, at 12:15 AM, Phil Pennock wrote:

> 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.

I quite agree.  It's just that SNI support in libcurl and friends does  
not yet exist in sufficient percentage of the "market".  We can't make  
the hkps==SNI guarantee.  We can strongly suggest it, and we will  
eventually get there once the newer libraries percolate through the  
world, but it's not a guarantee we can make today.

> 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 okay with this, except there isn't a good way to tell this at  
compile (or even run) time.  SNI in curl is hidden fairly deep under  
the covers.  Even if I do the inadvisable thing and warn for any  
version of curl older than 7.18.1, that doesn't really give a reliable  
answer, as curl might be linked against a SSL library that doesn't  
support it.

>> 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.

Oh, don't get me wrong: verification exists in the code today.  It's  
even on by default (another example of a least-unhappy choice).  I'm  
just pointing out that it's not my main desire.  If it meets someone  
else's desire, that's great, though.  I'm not writing this for me  
personally. :)

David