[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Jaap Akkerhuis <jaap@bartok.sidn.nl>
Cc: Jakob Schlyter <jakob@crt.se>, Randy Bush <randy@psg.com>, dnssec@cafax.se
From: Edward Lewis <lewis@tislabs.com>
Date: Wed, 2 May 2001 10:20:34 -0400
Delivery-Date: Wed May 2 17:29:21 2001
In-Reply-To: <200105011250.f41CoHP59313@bartok.sidn.nl>
Sender: owner-dnssec@cafax.se
Subject: Re: Keys at apex problem - New PUBKEY RR?

At 8:50 AM -0400 5/1/01, Jaap Akkerhuis wrote:
>Before we jump into solutions, we should first see do an inventory
>of what the possible problems are and wether more of these similar
>problems can be expected.
>
>That will give a better insight into what to do.

Since I'm enjoying my 2nd straight day in the office, I'll take a stab at this.
I'll list what I think are the questions, with an explanation of the
problem if need be.  I'll avoid hinting at solutions (which are prevalent
in this thread).

1) What is the scope of data held in DNS?  (E.g., do application-use public
keys belong in the DNS?)

The issue here is the complexity of a core element in the Internet.
Putting more and more features raises complexity and raises contention,
resulting in lower reliability and response time.  On the other hand,
centralizing the information in one place simplifies the use of the
infrastructure by applications.

2) Now that we have deployed name servers with (partial) DNS Security, how
do we improve on this in a graceful manner?

Another way to state this is "how to we retain backwards compatibility?"
There are two reasons why we don't want radical changes unless warranted.
One is the existing base of software.  The other is the IETF standards
process, we don't want to have to needlessly re-cycle at the lowest level
of standards.

Questions 1 & 2 are rather abstract.  The remaining are more concrete.

3) Where is the parent-generated signature over the child enter the DNS?
This was the original issue that spurred the issue spurring this thread.

Having the parent zone advertise the signature over the child key has been
proposed to alleviate operational issues such as parent key changes.  Since
the keys are signed set-by-set, this means all apex keys are in one set and
signed as a unit by the parent.

4) How do we avoid having the parent sign key records belonging to an
apex-host?

Ordinarily, zone's leave the apex as a non-host, i.e., no address records
are stored there.  But there are zones that do treat the apex as a host.
This is fairly common (yet in the minority) and legal under DNS
specifications.  A result of this is that certain host-based public keys
would then be put in the apex key set, which means that the parent would be
authorized to sign for the host's public keys.

There's a perceived distaste for having the parent zone now responsible for
securing data that is entirely child-specific.  A parent signing the zone
key of the child is acceptable, but not a co-located IPSEC key.

(Forgot this one originally)

4.5) Should the parent have a policy regarding what kinds of keys of the
child it will sign?

Should a parent refuse to sign a set with a non-zone key, or with no zone
keys?  Should this be left to the parent, child, and/or an IETF
recommendation?

The next questions are derived from the thread.

5) Do we separate zone keys from application-use keys?  If so, how?

The answer to the first is yes, but this issue of whether this is a
mandatory separation hasn't been settled.

Assuming we do separate the two kinds of keys, what approach is better?
Defining a new RR type to handle one of the kinds of keys, or, do we store
different keys under different names.

There are three sub questions here.

5a) How can we avoid the preceived pitfalls of record subtyping?
5b) How can we keep the added records to answers small (KEY in additional)
5c) How can we avoid sending application-use records to the parent for signing?

6) If DNS is not to hold application public keys, where is the best other
place to put them, maintaining application performance and security of the
lookup?

If DNS uses NAPTR (or SRV) to indicate another location, is there a
reasonable other location mechanism?  Is this other mechanism secured?  How
many configured keys and different verification algorithms will a client
need?

And here are some questions that popped up in side discussions.

7) What is the appropriate model for validating data?

If application-use keys are in the apex set (as is now specified), is it
still proper to rely on the parent signature to authenticate the keys?

8) If a child's apex key set has no zone keys in it, should the parent
insert a NULL key?

A careful reading of 2535 says a parent only has to insert a NULL key if a
child does not have the ability to hold keys.  If a child demonstrates it
can hold keys and does so by generating everything but a zone key, what's
the proper course?

....I still think there are one ot two questions I've missed.  This took a
lot longer to write than anticipated....

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: lewis@tislabs.com

You fly too often when ... the airport taxi is on speed-dial.

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



Home | Date list | Subject list