Re: Service discovery (was Re: [Sks-devel] pool.sks-keyservers.net DNS unresponsive?)

[David Shaw]

On Jul 6, 2009, at 3:06 PM, Daniel Kahn Gillmor wrote:

> On 07/06/2009 12:04 PM, David Shaw wrote:
> > On the subject of the various "pool" keyserver addresses, I'm  
> > working on
> > (re) adding SRV support to GPG using DNS service discovery.
>
> Excellent news, thank you David!
>
> Are you thinking about using simple SRV records [0], or (as your use  
> of
> the term "service discovery" suggests) the more-complex DNS-SD [1]?
> DNS-SD (in conjunction with the rest of the zeroconf suite, and a
> well-implemented pubring-via-HKP daemon) could make it possible to
> quickly and easily share public keys and certifications between  
> neighbors.

DNS-SD can work with the zeroconf and mDNS stuff, but it is its own  
beast.  What I am doing should lay some groundwork if someone wants to  
take things a step further (find your keyserver automatically on a  
LAN, for example), but that's not what I'm shooting for today.

I'm aiming for two basic features:

1) A simple "keyserver sks-keyservers.net" (or whatever pool you like)  
should be able to balance across keyservers based on some useful  
criteria.
2) Port numbers should be provided automatically, so users never need  
to know if a keyserver is running on 11371 or 80 (and that applies to  
SSL as well)

And a third, somewhat more obscure feature, is:

3) The ability to ask a domain for its keyserver, so if you are  
mailing address@hidden, your GPG instance can ask example.com for  
its keyserver(s), and then contact that keyserver.  This is similar to  
the convention for storing keys in a LDAP server, where "ldap://keys. 
$domainname" contains the keys for $domainname.

The utility of #1 and #2 are clear.  The utility of #3 is less so, so  
it likely won't be in the first cut of this.

> It could also open up concerns about the ease of spoofing keyservers,
> but i think those concerns already exist on the 'net today -- using
> explicitly decentralized protocols like mDNS/DNS-SD is just taking the
> decentralized and unauthenticated gossiping keyservers model one step
> further.

I think it is essentially as secure as things are now.  We find  
keyservers via DNS today, and this wouldn't change that.  It's  
potentially two lookups vs one, but it's still dependent on the DNS  
not being spoofed.

>  We rely on client-side crypto to evaluate the legitimacy of
> returned signatures anyway, and that certainly wouldn't change.

Yes.

David