Subject: Delegation Points

From: Mark Gritter <[email-masked]>
Date: Wed, 2 Jun 1999 16:02:22 -0700 (PDT)

I see a potential problem with the handling of keys at delegation
points.  (In reference to section 2.3.4 of RFC2535.)  Suppose 
the RRset "gritter.stanford.edu, KEY" has three records.  The first
key is for an email address ([email-masked]'s public key), the
second is a host key, and the third is a zone key for the 
*.gritter.stanford.edu subdomain.

The RFC suggests that these nodes occur in both master files--- for
the stanford.edu domain and for the gritter.stanford.edu.
However, in the second paragraph of that section:
> There MUST be a zone KEY RR, signed by its superzone, for every
> subzone...
[snip]
> For all but one other RR type[s] the data from the subzone is more
> authoritative so only the subzone KEY RR should be signed in the
> superzone if it appears there.  The NS and any glue address RRs SHOULD
> only be signed in the subzone.  The SOA and any other RRs that have the
> zone name as [the] owner should appear only in the subzone and thus are
> signed only there.

Does this require that other KEY RRs with the same owner also be
signed with the superzone key?  The KEY RRset must be signed as a unit,
unless the resolver is explicitly required to recognize and deal with
such a situation.

I would think the host key (#2) should be signed
with the "gritter.stanford.edu" zone key (#3), but is this not the intent?
On the other hand, if the "gritter.stanford.edu" zone key is used to
sign the RRset, the key has "signed itself".  Resolvers must not accept 
such a signature as valid.

I would appreciate your comments on this--- I find the section confusing.

Also, I would favor a stronger statement in section 6.3, "Chaining
Through the DNS" than the current "it should be possible to retrieve
signed keys..."  If every zone key is signed by its superzone key
(as required in 2.3.4) then simple "downward" chaining from the root zone
_is_ (not "should be") sufficient to find all zone keys.

Mark Gritter
[email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Wed, 2 Jun 1999 20:35:35 -0700

Sigh.  A short answer - the RFC is confusing in many places.  As an
implementer, I do not agree with much of section 6.  Hence, I won't arge
the spec.

You raise a situation I hadn't considered though - stuffing non-zone keys
in the apex.

I am in the midst of writing a key handling document for the DNSOP
proto-WG, and already have a document into the DNSIND on "zone key
referral" (co-written with Jerry Scharf).  Both of these relate to your
concern.  I have also had a draft (retired) on the "Chaining signed keys"
that is an alternative to section 6, which is likely to rise again now that
more folks are combing throught RFC 2535.

List note: given that DNSSEC is being merged with DNSIND, folks should
raise similar issues like this to either namedroppers or the coming dnsop
mailing lists, as appropriate.  (namedroppers deals with protocol issues,
dnsop deals with ops issues.  What is addresses here hits both.)

At 4:07 PM -0700 6/2/99, Lewis, Edward wrote:
>Message-ID: <[email-masked]>
>From: Mark Gritter <[email-masked]>
>To: [email-masked]
>Subject: Delegation Points
>Date: Wed, 2 Jun 1999 16:02:22 -0700
>MIME-Version: 1.0
>X-Mailer: Internet Mail Service (5.5.2448.0)
>Content-Type: text/plain
>

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                       Network Associates/TIS
Phone: +1 443-259-2352                             Email: [email-masked]

Think globally, scope locally.
"Trying is the first step to failure." - Homer Simpson
"No! Try not. Do... or do not. There is no try." - Yoda

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