Re: Global PKI on DNS?

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

> On Wed, 2002-06-12 at 03:05, Keith Moore wrote:
> > > 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.
> 
> I'm aware of at least one DNS server (djbdns) which allows you to serve
> arbitrary new record types, if you don't mind including binary data in
> your data files.  I'm not a big fan of that software, but it does
> illustrate that the difficulty of supporting new record types is more of
> an implementation issue (and not a terribly difficult one) than a
> protocol issue.

true.  though the protocol does impose some limitations - e.g. a limited
space for RR and query types, and *very* simple queries.  of course you
can extend the protocol to overcome these limitations, it's just a SMOP....
as long as you're going to upgrade the servers, why not do so?  however
recent attempts to extend DNS have not exactly met with universal success,
which might tell us something about the fitness of this protocol for
further extension.  

> > > 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".
> 
> Experience has generally shown that providing simple, easy to understand
> functionality usually does the job, while providing complicated and
> difficult services either doesn't get implemented or doesn't get used.

now there's a broad statement.

it's entirely possible for a new service to be both simpler and more
extensible than DNS is.  it's also entirely possible to use another
existing protocol - say LDAP or HTTP - for certificate retrieval.
so it's not necessarily a tradeoff between an old service and a new
one, or between a simple and easy to understand service (not sure if 
DNS qualifies) and a complicated and difficult service.  DNS gets 
more complicated and difficult every time the protocol is extended.

> HTTP is a good example (even if not all aspects of it are simple and
> easy to understand).  The initial HTTP spec provided all sorts of
> complicated things you could request for, like which language you wanted
> a document to be returned in.  None of that cruft got used; HTTP servers
> simply implement a URL to document mapping, for the most part.

no.  the initial (pre-0.9) HTTP spec was extermely simple, but
it didn't adequately consider things like caching and content
negotiation.  a lot of extensions got added in an ad hoc fashion
by vendors.  the standards tried to rationalize them, with moderate
success.  many of the features that were added *are* used - 
they were added for a reason, after all - but we're still left with 
a mess of a protocol because it got stretched far beyond the
capabilities of the original design.
 
> > > 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're assuming your conclusion again ("it doesn't matter if my specific
> argument is invalid, because the general argument which it supports
> renders it irrelevant").  

no, that's not what I'm doing.  My conclusion that DNS isn't a good fit
comes from having tried to figure out how to use it for various purposes
(like URN resolution, which is similar to cert lookup) in a scalable fashion.

> And I think you're flat out wrong about the
> code savings; the code to marshal and unmarshal a record type is much
> smaller than the code to implement a new network service.

the code on the client end is about the same.  there is indeed more 
code on the server end with a new service, though you also gain something
in flexibility and efficiency if the new service is a better fit
for the problem than DNS.

see, what is happening is people are asking "how can we use DNS to
lookup certs?" rather than "what kind of functionality do we need to
support cert lookup for lots of applications?"  they're both valid
questions.  but the problem is that if you extend DNS to support
cert lookup with the idea that it only needs to support a common
few apps, then more apps will want to use it, and the result doesn't
scale because different apps have different needs.

> > > 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.
> 
> A long list of restrictions which are usually satisfied (except for the
> second one, which is highly debatable) doesn't really harm your
> opponent's position.

the restrictions aren't satisfied if lots of apps want to use this,
and the server has to return several certs because it doesn't (cannot)
know which of them will satisfy the app's constraints.

> > 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.  
> 
> See, to me, this is FUD.  My organization has been using DNS for "tacked
> on" stuff (Hesiod) for over a decade, and it works quite well.  Since we
> don't have a record type, we use TXT records; this is conceptually ugly,
> but who queries for ghudson.passwd.ns.athena.mit.edu TXT and expects
> anything other than Hesiod passwd data?  No one, of course.  You can
> imagine lots of nightmare scenarios involving lack of coordination, but
> they never happen.

right, but surely you've found that there are limitations associated
with trying to map every query onto a DNS name prefix?

and again, there's a difference between starting out with a facility
like DNS and saying "what can we use this for?" and trying to solve
a specific problem like "how do we lookup certs that apps need?".

Keith