Re: Let's assume DNS is involved

[Simon Josefsson <simon+keydist@josefsson.org>]

As Greg and I seem to agree that putting keys (or key fingerprints) in
DNS is useful, my answers below are mostly directed to those who are
still skeptical, and justify their standpoint using one of the
arguments discussed here.

Greg Hudson <ghudson@MIT.EDU> writes:

> 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.

1) Transferring keys with DNSSEC will be larger than UDP limit, so
   using TCP by default isn't unreasonable.  (Unless EDNS0 is
   available.)

2) I don't understand why it would degrade Internet performance as a
   whole.  For the example in question, a SSH client would look up one
   A record as it does today, plus one APPKEY/CERT record.  Compare
   this to what MTAs do to find MX hosts when sending a mail.  Mail is
   used more than SSH, and DNS still work.

>   * 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.

This is not specific to key distribution.  Even a query for a single A
record with DNSSEC will overflow the UDP packet limit. "dig
www.josefsson.org a +dnssec" results in a 641 byte response.  We have
EDNS0 or fallback to TCP to solve this problem.

>   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.

It would be good if the arguments against srv-style name mangling
could written down.  Collective knowledge is easy to refer to, but
difficult to assert the value of.

>   * 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.

Name servers should handle unknown RR types.  Also, people storing
keys in DNS will make sure their software handles it.  Problem solved.

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

Again, people storing keys in DNS is likely to make sure their
software handles it as well.  Not a problem.

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

This (that some people believe this, that is) seems to be the main
problem.

> 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.

Not that much, I think it could work.  However, the size difference
between a key fingerprint and the key itself seems small, so if you
really believe a fingerprint would solve most of the problems with
DNS, I don't see why storing the entire key would cause such enormous
difference.  Key fingerprint would be SHA1 = 20 bytes, an RSA key = 75
bytes.

I doubt a 55 byte size difference in a DNS response is the difference
between no problem and total collapse of the Internet.

> 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.

1) A single root may be sufficient for integrity protection, just like
   we trust it for integrity protection of A records.

2) Applications aren't restricted by this.  I can configure my SSH
   client with my corporation's DNSSEC key, and get authenticated key
   distribution for SSH.

>   * 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).

This can be solved by configuring campus A's DNSSEC key in campus B's
resolver.

>   * 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.

This might be a problem.