Re: Global PKI on DNS?

[Keith Moore <moore@cs.utk.edu>]

> > > OK, I'll bite.  What are those problems?
> >
> > where to start?  okay, first the fact that DNS RRs aren't very
> > extensible, so if you want to cram something new that doesn't quite fit
> > then you have an upgrade problem.
> 
> resolvers are transparent to new rr types, secondary servers are beginning
> to be transparent and primary servers of course need to support the rr
> types they are serving.

not 'of course'.   it's a design flaw in DNS.
either that or (so I've been told) limited extensibility was a deliberate
design choice.

it doesn't matter - it just means that DNS isn't a good tool for some
things, just like HTTP, or LDAP, or SNMP, or XML, or whatever your
favorite hammer-of-the-week is, isn't a good tool for everything either.

> > second, DNS queries don't let you specify any parameters other than DNS
> > name, class, and a single integer query type, which isn't exactly a good
> > fit for "find me a cert that is signed by one of the N CAs that I trust,
> > and which has these properties and/or does not impose these
> > constraints".
> 
> most applications would be enough with a simple query such as
> 'mail.foo.bar in cert ?' and can select the appropriate certificates out
> of what's returned themselves. 

I don't think so.  it would satisfy a few common apps, perhaps,
but that's not even close to "most applications".

> if response size would be a problem, one
> could use _srv style naming or some napstr-like indirect naming.

you can only do so much with naming.  why bother?  DNS isn't a good fit
anyway, and using DNS to retrieve keys doesn't save you from having
to upgrade either the server or the client end (which will need such
different libraries that the code savings is minimal).  you might get 
some mileage out of reusing the existing cache system, assuming that
you can squeeze certs into RRs of appropriate size, but I don't 
think that makes it worth the cost.
 
> > it's almost as fun as trying to get old protocols to do things that they
> > were never designed (and aren't well-suited) to do!
> 
> dns is pretty good at looking up some resource record, that do not change
> to often, based on a domain name.

... where the resource record isn't too large, and the RR format is 
already something that DNS supports, and you don't need much 
feed-forward in the query, and you need a very simple caching/expiration 
model, etc.

face it, dns was designed for name-to-address lookups.  even reverse
lookups were a kludge, and everything else that has been tacked on
since then have made it worse.  

we keep extending dns to do new things not because it's a good fit for 
the protocol, but because the name space that is attached to the protocol 
and to that network of servers is so valuable.  but sooner or later
we need to stop trying to shoehorn new things into DNS that are a really
lousy fit.

Keith