Re: Let's assume DNS is involved

[Greg Hudson <ghudson@MIT.EDU>]

On Fri, 2002-04-05 at 20:11, James Seng wrote:
> ps: something to think abt: what is the "problem" to add more stuff into
> DNS?

Technical issues:

  * DNS has no provisions for congestion control when run over UDP. 
Using it for new purposes could (though I don't think it's likely)
degrade Internet performance as a whole.

  * DNS only supports limited-size messages when run over UDP. 
Practically speaking, this means you only want one key or cert in a
given RR set, and some day even one key might overflow the UDP packet
size limit.

  But you probably want to have multiple keys associated with a domain. 
That means they either have to be of different types (see below), or
we'd have to do srv-style name mangling, which nobody in the DNS working
group is very happy about.

  * Adding new record types to the DNS requires adding code to
authoritative name server implementations.  Many people who operate
authoritative name servers don't like to upgrade very often; hence, it
may be practically difficult to get data of new record types into the
DNS.

  * Due to historical bugs in BIND, adding new record types can also
require adding code to slave servers.  Fortunately, this problem is
disappearing.

  * Some people believe that adding new functionality to a critical
deployed service isn't good engineering--nothing specific beyond that.

Most of the above problems are solved if we put smallish key
fingerprints into the DNS and use a different service to retrieve the
keys.  That's a lot more work for the client, of course.

Security risks:

  * The DNS only has one root, and thus the DNSSEC hierarchy has only
one trust root, which is not particularly trustworthy.  Certificates
would allow users to pick different trust roots without using different
domain names.

  * DNSSEC does not allow for cross-certification, multiple parent
certification, or anything like that.  You have a straight single-parent
hierarchy leading up to the point of out-of-band key sharing (which is
typically the root).

  * Users often assume that DNS names are what they sound like.  Is
bankofamerica.com owned by the Bank of America?  Probably, but Verisign
doesn't promise anything of the sort.  Encouraging users to put more
trust in DNS names could lead to greater potential for abuse.

All that said, I support putting keys or key fingerprints into the DNS. 
I find the following two arguments to be more compelling than any of the
above:

  * If DNSSEC is deployed, it will be the only large-scale hierarchical
trust infrastructure we have.  (The web server certificate
infrastructure is not hierarchical.)

  * X.509 certificates are tainted by ASN.1 and are (because of that and
in their own right) way way more complicated than keys in DNS would be. 
Security systems are better when they're simple.