keyserver pools using SRV records for HKP and HKPS [Was: Re: hkps port]

[Phil Pennock]

On 2009-04-02 at 10:45 -0400, Daniel Kahn Gillmor wrote:
> On 04/02/2009 08:56 AM, David Shaw wrote:
> > Ideally, curl would support SRV internally.  It can do a better job than
> > we can do as a wrapper from outside, as it can properly walk the list of
> > returned servers until one answers.  The best we can do is do a SRV
> > lookup, run the selection algorithm, and then hope that the best choice
> > is actually running.  Still, it is better than nothing.  If I had more
> > spare time, I'd just write SRV for curl and donate it to them.
> 
> I agree that using SRV records is a good idea for HKP and HKPS.  And
> David's suggestion here is structurally the right way to go, even if
> we're not there yet.
> 
> But i also note that i don't see any keyserver pools publishing their
> pool as SRV records at the moment -- only A records.  If we're going to
> say that we're making a least-unhappy choice (which is bound to make
> some operators unhappy), and that SRV records will be the mitigating
> factor, we should probably clearly encourage keyserver pool operators to
> publish their pool as SRV records directly in addition to A records.
> 
> Or are they already doing this, and i'm just querying the wrong way?
> 
>   dig -t SRV _hkp._tcp.pool.sks-keyservers.net
>   dig -t SRV _hkp._tcp.keys.gnupg.net
> 
> both return empty sets.

Well, there's already a well-established port for 11371 so there's been
no need to, really; sure, port numbers can be published but there's no
point if most clients won't actually use the port number.  The issue was
what to do with hkps.

At the moment, hkps *can* be done with a reverse proxy in front of the
KHP service providing the SSL stuff (and probably query-logging too).
So it's plausible to develop a client which can be tested in use.

Developing native SSL support in the servers could do with client
support to test against.  And since David has kindly written this for
us, we just need to wait for the next release to test.

While I don't run any public pools I do know what's involved, as for
self-education I maintain a pool name (under a deliberately long DNS
name to discourage use); really, exporting hostnames as well as IPs
would be trivial and once hkps support is in SKS, including the port on
the stats page and including that in the results will also be trivial.

Of course, I don't issue SSL certs so probably shouldn't publish hkps
records.  ;-)

-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/20090402/070c23fb/attachment.pgp>