Subject: Re: Admitting more documents: application keys in DNS

From: Robert Elz <[email-masked]>
Date: Thu, 01 Nov 2001 12:49:22 +0700

In general I have no great problems with adding new RR types in
the DNS - if they turn out to be rubbish (perhaps 50% of the
assigned RR types are) they don't cost all that much (really
just some implementor effort in the servers to support them, and
for most RR's that's pretty trivial).

On the other hand, I very much don't like bending the naming tree
to support new applications.   SRV was bad enough, with its extra
names for protocol elements that have to be introduced, but it is
general enough, and needed enough, that there was little other choice.
But we should never need to do that again.

So, if any new RR type fits the normal naming tree, and has some kind
of a plausible possible use, then let it be defined, no-one needs to
implement it just because it is defined, only if the users actually want
to use the thing.

On the other hand, any new RR type that wants to bend the naming tree,
that is, which requires magic names, ought to be told that what it is
doing is really inventing a new protocol, and ought to be using some
port other than 53 - and then use (if relevant) SRV to find that port
(and server).

It is a little hard to see how an application key can be stored in the DNS
without adding something to identify the application - that's bending the
naming tree, and so should be done some other way, using some kind of
key server, which can itself be located using the DNS, rather than
being implemented directly in the DNS itself.

On the other hand, if one needs keys, certificates, or anything else, that
map directly from the domain names we have now (my company's certificate
or something) then I see no harm in defining an RR type to carry that.

I also see no merit at all in the argument that adding a new server is
somehow more difficult than adding new RR types to the DNS, so requiring the
former would be imposing n insurmountable barrier to implementation.

The problem (the barrier) is getting people to actually decide that they
need to make keys/certificates/... available in the first place.  Once
they have decided they should do that, whether the method to do it is to
stick a whole bunch of new RR's in the zone file, or to build some other
kind of database and run a new server to return records from it is pretty
close to irrelevant.  As long as someone supplies the recipe, they will
follow it - after they're convinced to take any kind of action at all.

kre

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Greg Hudson <[email-masked]>
Date: Thu, 01 Nov 2001 08:45:16 -0500

> to support new applications.

Essentially, you seem to be saying that DNS should only talk about
hosts (and mail domains).  This is a valid position, if perhaps a
little disappointing to someone like me who is used to using DNS to
talk about users, printers, network filesystems, and so forth
(Hesiod).

> I also see no merit at all in the argument that adding a new server
> is somehow more difficult than adding new RR types to the DNS, so
> requiring the former would be imposing n insurmountable barrier to
> implementation.

Assuming we ever deploy DNSSEC at the root, the diference has to do
with the technical mechanisms of trust, not implementation difficulty.
Here are two rough scenarios for an application which requires some
global notion of authentication, one using a DNS RR for a key and one
using a separate server:

  1. The root signs edu (NS,KEY) which signs mit.edu (NS,KEY) which
     signs error-messages.mit.edu (A,KEY or APPKEY) which is used to
     contact some application.

  2. The root signs edu (NS,KEY) which signs mit.edu (NS,KEY) which
     signs _keyserver._tcp.error-messages.mit.edu (SRV) which points
     to keyserver.mit.edu (A) which is also signed by mit.edu.

     Separately, some CA root signs a certificate which is used to
     contact some application.  (Or maybe there's a chain of
     certificates involved; the point is that the application key has
     no trust relationship to the DNS.)

In scenario 1, the DNS root has ultimate control over all application
keys, and delegates that control through DNS zones.  In scenario 2,
some CA root has ultimate control over all application keys, and may
delegate that control in some way not necessarily related to DNS
zones.

Some of us have argued that any kind of standard enabling scenario 1
is a bad idea--that it is never appropriate, or that it is too
dangerous to justify the limited situations where it is appropriate.
Some others of us have argued that it is a good idea, or at least
interesting enough to pursue, and that it was already envisioned by
RFC 2535.

Either way, framing the argument as purely one about implementation is
deceptive.  I guess it's *possible* to follow the trust chain from DNS
to another protocol without signing keys in the DNS, but at the very
least it would involve sharing a private key between the
implementations of two different protocols (the private key for
mit.edu KEY would have to be used to sign both DNS records and data
for some key server protocol), and I don't think anyone would be happy
with that.

---

From: Robert Elz <[email-masked]>
Date: Thu, 01 Nov 2001 21:13:14 +0700

Date:        Thu, 01 Nov 2001 08:45:16 -0500
    From:        Greg Hudson <[email-masked]>
    Message-ID:  <[email-masked]>

  | Essentially, you seem to be saying that DNS should only talk about
  | hosts (and mail domains).

No, not at all.   Rather that I should be able to name anything and
everything in my DNS domain in any way I see fit - allocating names
to anything I like, or not.   If you choose to do that for users, etc
that's just fine (MB was one of the original RR types of course).

Where things go wrong is where something tells me that I have to
reserve this particular name for some specific purpose, because there's
some protocol out there that simply assumes it can construct names
(within some domain) for its own ends.   That's broken.

That's also SRV, where the impact is lessened by the use of the _ chars
in the constructed names (lessened, not avoided).   That kind of technique
could perhaps be used once or twice more - then the results would start
to become absurd.

It is bad enough when this is a convention (like www.) it is truly horrid
when it is a protocol element (which it would need to be for applications
to be able to locate the relevant key).

  | Assuming we ever deploy DNSSEC at the root, the diference has to do
  | with the technical mechanisms of trust, not implementation difficulty.

I was replying to one minor point I noticed during this long discussion,
but never mind...

And yes, trust chains are important, but things are rarely as black and
white as suggested here.

Assuming that one buys the argument that domain names are a suitable
identifier for a unit of trust, there's no reason at all that a DNS RR
(DNSSEC signed, etc) that contains an organisation's public key, or
CA signed certificate, or whatever the security needs, which can then be
used to authenticate all of the organisation's application keys, obtained
from some completely different mechanism.

What's more, the DNS might be just one way to obtain that data, CA's
might offer other methods for you to obtain a verified organisation
certificate that you can then use to validate all the rest of their
keys.

Certainly just because DNSSEC exists, and has its trust model, is no
reason that it needs to be used exclusively to validate everything that
might possibly exist.

What counts here is that the data being put into the DNS fits it
logically already.  Then the part that doesn't make a good fit is
done other ways.   That is assuming that DNS names are in fact the
right kind of identity to use (if they're not, then obviously the
whole question of using the DNS becomes irrelevant).

kre