Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-00.txt

From: Edward Lewis <[email-masked]>
Date: Mon, 10 Dec 2001 17:41:03 -0500

At 7:04 AM -0500 11/7/01, [email-masked] wrote:
>	Title		: Limiting the Scope of the KEY Resource Record
>
>This document limits the KEY resource record to only DNS zone keys.

I think there is a good reason to restrict the KEY RR.  But I disagree with
the way the draft describes it.

The good reasons to restrict the KEY RR is that the KEY RR incurs special
processing by name servers when the KEY RR is a zone key and that the
resolver handles zone keys in special ways.

The draft lists other "reasons" which aren't really germain.  Specifically:

>        o    They serve different purposes.
>        o    They are managed by different administrators.
>        o    They are authenticated according to different rules.
>        o    Faults/key compromises have different consequences.

The four blurbs why these reasons aren't reasons...
1) Reusing data structures for different purposes is sometimes "good."
2) The same admin may be the one doing DNS and (say) installing SSH.
3) The default (RFC 3007/8) rules do differ between data and zone keys, but
   not application keys and data.
4) This is too loose a statement to have meaning.

I'm picking on the rationale because issuing a post-definition restriction
is not something to be taken lightly, so there should be a good rationale.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Opinions expressed are property of my evil twin, not my employer.

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

---

From: Edward Lewis <[email-masked]>
Date: Wed, 12 Dec 2001 16:11:21 -0500

One other reason for resticting the KEY RR is something I learned after a
discussion with Rob Austein (I hope I phrased this right):

Overflowing UDP is a bad (but not dangerous) thing in DNS - it usually
causes a fallback to TCP.  Larger data sets increase the likelyhood of
overflow.  Individual keys are large, it doesn't take too many to trigger
an overflow of the packet.  Therefore, steps need to be taken to limit the
size of the KEY RR set as this has an impact on the operation of DNS.

Hmm...just a thought, this doesn't necessarily mean that KEY should only be
used for dnssec.  A more direct answer to this particular reason is to
restrict a KEY RR set to only one key protocol value (ie just dnssec or
just ipsec or just...), which at a zone apex effectively is a restriction
to just dnssec.

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 12 Dec 2001 16:51:54 -0500

> just ipsec or just...), which at a zone apex effectively is a restriction

It is extremely common to put hosts and such at zone apexes.  

One *could* use naming conventions like the ones used with SRV records
to move the keys away from the name uttered by the user..

				- Bill

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 12 Dec 2001 23:56:35 +0100

Making the owner name of the KEY RR be application specific, to solve
the UDP overflow problem, has also been discussed.  If the RR's are
named differently for each application that uses KEY RRs, you won't
overflow UDP [unless the application needs several KEY RRs].

Seen from a design point of view, moving the semantic meaning of the
KEY RR "protocol field" outside the protocol field (and into the owner
name) is perhaps not optimal, altough it would solve the issue without
modifying the protocol.

---

From: Matt Crawford <[email-masked]>
Date: Wed, 12 Dec 2001 17:26:33 -0600

> to move the keys away from the name uttered by the user..

I sure think that's the way to go.  You cn keep each app's keys at a
different name, which keeps RRset sizes down and permits a
"first-come, first-serve" policy for names rather than a stricter
policy for RR type codes.

	_ssh._key.fqdn
	_ipsec._key.fqdn
	...etc...

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 13 Dec 2001 05:00:58 +0100 (MET)

> to move the keys away from the name uttered by the user..

this might be the way to go to avoid subtyping using RDATA, but I do not
think we should do this using the KEY.

we should write down the requirements for application keys in DNS and then
proceed further. we might end up with something like APPKEY, but that will
probably need more discussion and feedback from apps-people.

	jakob

---

From: Edward Lewis <[email-masked]>
Date: Wed, 12 Dec 2001 23:25:31 -0500

Before we spend a lot of time on this again, I'd like to point out that we
just had this discussion a few months ago and wound up rat holing.  The
message from Olafur at the end of the meeting Monday was that this issue
should (for the time being) be punted out the WG.

A few of us have begun to do some work on this outside of the mantle of the
DNS* WG's.  Word on a mailing list should appear in the near future.

(What I'm trying to say - a lot of good points have been raised, but let's
not continue to clutter up namedroppers with this.)

---

From: Randy Bush <[email-masked]>
Date: Thu, 13 Dec 2001 13:11:20 -0700

> not continue to clutter up namedroppers with this.)

considering the plenary discussion of when design groups become cliques,
and that this is a dnsext document, i believe this suggestion, though
well-meant, to be inappropriate.

randy

---

From: Edward Lewis <[email-masked]>
Date: Thu, 13 Dec 2001 12:32:30 -0500

I do think that restricting keys as described is a good idea.  My comments
(all previously stated, so I'll just categorize) are that:

1) Adjust the introduction so that we document that we are doing this for
the right reason.

2) I felt impelled as an engineer to point out that there is another
approach to solving the overflow problem.  The document should capture the
alternative and state why it was not pursued.  (I like credit for my bad
ideas.)

<soapbox on document preparation>
My overall concern is that any document capture as much as possible the
history and other considerations behind technical recommendations so that
the actions are understood through the years.  The more I work on DNS the
more I hear about subtle design considerations.  This oral histroy is
"important" and (by definition) covers stuff not in the RFCs and other
documents.  Having to get oral history from the people in the know is nice,
but ususally comes after a lot of work going down wrong paths.

At 12:04 PM -0500 12/13/01, Daniel Massey wrote:
>Let's get rid of the sub-type for the KEY record by restricting
>it to DNSSEC zone keys.  As stated in the draft, this can be
>done with only minor changes.  The format of KEY is not changed
>and the use of DNSSEC keys is not changed.  It seems like Jakob's
>[email-masked] is a good place to discuss application keys.
>The only constraint added by restrict-key is that application
>keys can't use the KEY record.

---

From: Daniel Massey <[email-masked]>
Date: Thu, 13 Dec 2001 12:04:09 -0500

Hi,

With respect to using naming conventions for the KEY record, 
I don't think anyone has suggested storing DNSSEC zone keys 
in _dnsseczone._key.fqdn. (please don't!) So the naming 
convention change to KEY would result in a sub-typed record 
where only SOME of the sub-types use a naming convention.  

When we begin to apply naming conventions to SOME sub-types,
I think we need to back up and ask whether the record
is trying to do too much.  

Dan

---

From: Edward Lewis <[email-masked]>
Date: Thu, 13 Dec 2001 21:08:22 -0500

I think my statement wasn't clear.  I was referring to discussing "how to
put application keys in dns," not the draft's rationale based on the desire
to avoid the application key problems. (???)

---

From: Robert Elz <[email-masked]>
Date: Fri, 14 Dec 2001 16:24:15 +0700

Date:        Wed, 12 Dec 2001 16:51:54 -0500
    From:        Bill Sommerfeld <[email-masked]>
    Message-ID:  <[email-masked]>

  | One *could* use naming conventions like the ones used with SRV records
  | to move the keys away from the name uttered by the user..

One could, but one certainly should not.

It is becoming clear to me that putting application keys in the DNS
is simply the wrong solution.

Attempting to do it in the simple way causes packet size problems.

Attempts to avoid that by bending the namespace (aside from being obscene
to begin with) causes problems later if the desire is to have more that
one app share the same key - there's no way in the DNS for two different
names to have the same RDATA, short of duplication or CNAMES.   Duplication
(especially of large data that might need to be duplicated very many times)
causes zone size blowout, and dramatically reduces the effectiveness of
caching.  And I'm not sure I would want to rely an awful lot on a KEY that
was fetched from some random location after following a CNAME (and even
then, the CNAME is extra data to have to store and send around - even if
it would typically be much smaller than a key).

And it seems that no-one wants to propose a separate RR type for every
different application (which would have the same data size problems as
bending the namespace, if not the same mangling of the DNS namespace).

Just design a new protocol and be done with it - it doesn't need to be
very complex, it can start with security mandated in it so the key
can really be trusted ...   By all means define a new DNS RR (or use the
SRV RR) to allow apps to locate the key server for a domain (and note:
a domain includes any DNS label).

Just keep anything other than the keys needed for the DNS itself out
of the DNS (and I'm not sure even those shouldn't be moved).

kre

---

From: Greg Hudson <[email-masked]>
Date: Fri, 14 Dec 2001 10:25:22 -0500 (EST)

> it would typically be much smaller than a key).

I will counterargue that:

  1. Sharing one keys between two apps is usually considered egregiously
bad security juju anyway.  (The two keys can be part of the same signature
hierarchy, but they shouldn't be the same.)

  2. Your argument that "there's no way in the DNS for two different names
to have the same RDATA" is purely an implementation issue, since we're
talking about two different names in the same zone.

  3. You haven't provided any justification for trusting a key less
because you followed a CNAME to get it.  (Yes, following a CNAME means
potentially adding more vectors of attack to compromise the key, but not
if the CNAME is just to a different application name for the same
hostname.  And besides, you never had any assurance to begin with that
your original source didn't pick up the key from any old random source;
simply because they tell you where that source is shouldn't decrease your
trust.)

  4. You already provided a convincing counterargument to the size example
yourself.

I think bending the namespace is unfortunate, but hardly obscene.  Having
to bend the namespace does suggest that we're using DNS for something
it wasn't designed for (specifically, looking up a pair of strings instead
of just one string), but it's a relatively minor adaptation.

> a domain includes any DNS label).

I'd be okay with this if we allow an application key in the DNS for the
key server (but no other applications).  It can be a separate RR
type from KEY.  Without this, there is no way to chain the DNSSEC security
infrastructure to the key server's, so you need two signing authorities
instead of one.

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 14 Dec 2001 11:12:35 -0500

> is simply the wrong solution.

Others (including myself) will respectfully disagree.

> one app share the same key 

Sharing the same key between multiple applications is, in general, a
bad idea -- compromise of one key will compromise the other.

> Duplication (especially of large data that might need to be
> duplicated very many times) causes zone size blowout

If this becomes a problem, dns implementations can adapt by sharing
storage.

> and dramatically reduces the effectiveness of caching.  

I don't see how this follows.  "dramatically" overstates the case,
particularly when we're only talking to one app per server..

> a domain includes any DNS label).

Except that by your absolute "no app keys in the DNS" rule, we can't
chain trust from the DNS into this application...

					- Bill

---

From: Robert Elz <[email-masked]>
Date: Fri, 14 Dec 2001 23:09:13 +0700

Date:        Fri, 14 Dec 2001 10:25:22 -0500 (EST)
    From:        Greg Hudson <[email-masked]>
    Message-ID:  <[email-masked]>

  |   1. Sharing one keys between two apps is usually considered egregiously
  | bad security juju anyway.

Whether that's true or not, for keys that are going to be stable long
enough to stick in the DNS, it will happen...

  |   2. Your argument that "there's no way in the DNS for two different names
  | to have the same RDATA" is purely an implementation issue, since we're
  | talking about two different names in the same zone.

Well, not necessarily, if the name bending was added (that's creating
sub-domains, and any sub-domain could be delegated).   But that's an
unlikely problem...   More seriously, it isn't just the primary server
that matters here, there's also the secondaries (neither AXFR nor IXFR
have any way to denote "the same data as that other RR") and there's also
all the caches.

  | I'd be okay with this if we allow an application key in the DNS for the
  | key server (but no other applications).

One application key - ie: a keyserver key for a domain (which then wouldn't
need namespace mangling) I could tolerate.

kre

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 14 Dec 2001 19:03:55 +0100

> Attempting to do it in the simple way causes packet size problems.

If this is the reason, do you regard IPv6 and DNSSEC as equally bad
because they also cause packet size problems?

We do have 
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-message-size-04.txt
that discusses this problem though.

Are there other arguments against storing application keying material
in DNS?

> a domain includes any DNS label).

This only works if the new protocol replaces DNS for name lookups as
well.

I believe that the same service that provide name to address mappings,
be it DNS or something else, must also provide a mapping between name
(or address) and application keys.  Otherwise we'll just end up with
the same problem we have now: that knowing the address (hostname, IP
address or email address) is not sufficient to get the application
keying material for the address.  And this is something that would be
needed if we want opportunistic encryption to happen.

This is not saying that the keys themselves really MUST be stored in
DNS, a SRV record that points to a LDAP server, or something similar,
would work equally well.  The point is that these solutions doesn't
seem to work now, so we should consider other solutions.