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.