Subject: Comments on delegation signer

From: Erik Nordmark <[email-masked]>
Date: Mon, 6 May 2002 23:37:55 +0200 (CEST)

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

Editorial comments as far as I can tell.

In section 2.2.1 it says "Delegations ... MAY contain only ..."
and I don't understand what that means.
Is the intent "Secure delegations ... MUST contain at least ..."?

At the end of section would it be useful to point out that
implementations should not assume that the digest is exactly 20 bytes?
(since a new digist type might have a larger digest)

Section 3: I don't understand the tag value. Isn't the DS in the parent
supposed to have the same tag as the KEY in the child?

I don't know for sure, but is the <example. NXT> partial in that in doesn't
have a domain name in its RDATA? (All the other NXT in the example contain
this.) I was expecting to see secure.example. there.

Section 4 talks about needing to search more than 2^80 keys.
This looks like birthday probability i.e. if there are more than 2^80 different
DS records in the DNS the probability of two having the same digest is about
half. But I interpret the statement to be about the brute force attack against
a particular child zone. In that case on average 2^159 keys would have to
be generated.

Finally split the references into normative and non-normative.

   Erik

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Ed Lewis <[email-masked]>
Date: Wed, 8 May 2002 08:46:15 -0400 (EDT)

Given the opt-in issue about whether zones, names, or RRsets are
secure/insecure, refering to "secure" delegations is dicey.  First,
I'd roughly define a "secured delegation" as being one in which there
is a KEY RR set (at the apex) - and possible that the SOA is signed,
etc.  Secondly, I wouldn't state that:

"Secure delegations...MUST contain at least"

but rather that:

"In order for a delegation to be considered secure there MUST be at least"

That's an editorial nit, but in the first form, if a "secured delegation"
fails to meet the MUST and is no longer "secured" and hence the MUST no
longer applies.  I.e., there's no way that the requirement/MUST can
"fail."

Regarding the tag field in the DS record, this is a good thing for
debugging.  By simple inspection of the record, an admin can see if the
desired KEY RR's are represented in the DS set.  Although this isn't a
protocol necessity, experience in the workshops shows that tags are
important in debugging.  Perhaps we are letting debugging get ahead of
operations, but 1) this makes the protocol more deployable and 2) tools
that should provide a way to interpret the records seem to have been
lacking - for one reason or another.  (Yeah, we did miss the one option to
dig that might have proven important.)

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 10 May 2002 10:57:09 +0200 (CEST)

> "In order for a delegation to be considered secure there MUST be at least"

The reason I assumed that saying "Secure delegations" here is because
the paragraph in question start with the text 
   For every secure delegation there MUST be a DS RRset stored in the

How should that whole paragraph be rewritten to capture the difference
you point out?

> dig that might have proven important.)

I don't think I said that tags aren't useful - I'm just confused by the
values in the example.

My reading of the document was that the tag value is also useful for the
resolver to more quickly find the key.
My question is how this is done given the tag values in the example.

  Erik

---

From: Ed Lewis <[email-masked]>
Date: Fri, 10 May 2002 08:17:43 -0400 (EDT)

> How should that whole paragraph be rewritten to capture the difference

In order for a delegation to appear to be signed, the parent zone MUST
contain a DS RR set for the child.  Whether or not the resolver making
the determination of security will decide that the child zone is secure
will start with the evaluation of a DS RR set, unless the resolver has
already configured a key for the child zone.

Delegation points MAY contain only the following RR sets: NS, DS, NXT,
and SIG.  Delegation points MUST not hold any other RR sets, implicitly
including KEY RR sets.  The NS RR set MUST NOT be signed by the parent
zone regardless of the security status of the delegation.  Note that
although the NXT RR set held in the parent and the set held in the
child will share the same owner name, class, and type, the two are
distinct sets and will have different values in their respective RDATA.

...this assumes that "delegation point" refers to the data in the parent
to identify a cut point.  I did make two pararaphs out of this to try and
provide more clarity.  I also rearranged the decription of the types held
to put what can be done first (+) and what can't be done second (-).
Finally, the original text explicitly mentions that the NXT's will differ
from parent to child, but then again, so will the SIG set, and possibly
the NS set....

> I don't think I said that tags aren't useful - I'm just confused by the

I misunderstood the intent of your comment.

> My question is how this is done given the tag values in the example.

In looking a the example (section 3), it appears that the zone is "broken"
as the DS RR does not refer to a KEY RR.  The tag in the DS should be the
same as (one of) the tag(s) in the KEY RR set.  I think that's obvious -
IOW, the example is broken.