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


To: Edward Lewis <lewis@tislabs.com>
cc: dnssec@cafax.se
From: Olafur Gudmundsson <ogud@ogud.com>
Date: Wed, 27 Mar 2002 11:12:22 -0500 (EST)
In-Reply-To: <v03130300b8c0faaabd1e@[166.63.190.161]>
Sender: owner-dnssec@cafax.se
Subject: Re: Keys and DS



On Fri, 22 Mar 2002, Edward Lewis wrote:

> Off an on, there have been discussions on how to do child-parent key
> exchanges.  A number of different ways are being proposed, I think it is
> important to note that there is no reason that just on way must be chosen.
>
> I think it would be a waste of bits to try and argue over any one approach
> in a mailing list, experience and code are better arbiters.  But I do want
> to gather opinions on some issues.  Again - "gathering opinions" doesn't
> mean trying to hammer consensus out of folks that do not agree.

Below are my private (possibly ignorant) answers to these excellent
questions.

>
> First question.  Is there a requirement/need to have a child provide
> authentication during the sending of material key material to the parent?
> (By "key material" I am not inferring a KEY set for this question.)

Depends where you are in the DNS tree.
For leaf zones that have limited security requiremnts misconfiguration
is OK, for large delegation zones having correct DS pointing at them
is essential or everyone that depends on the delegation zone is hosed.
I think the more important questions to ask is:
Q: What actions should parent take to protect itself from
childs misconfiguration/misinformation ?

In the case of NS records parents do not process update until after
the nameservers listed have been checked to be authorative.
In the case of KEY and DS, parent can follow at least one of the
following policies:
  - insist on KEY + SIG(KEY) to make sure that the KEY records are
    valid keys that the child has access to and can use.
  - accept DS records and check if there are matching KEY records
    in the childs KEY apex set.
  - accept DS without checking.

>
> Second question.  Should the child be responsible for sending the generated
> DS records to the parent?  (This is perhaps a touchy question.)  I won't
> elaborate further, I would like to hear opinions.

The only border case where this is an issue is where child wants to
advertise DS record for a public key that is not avertised yet.
I do not think it matters who generates the DS record, but I may in
general trust the parent slightly better.

>
> Third question.  With the use of DS, if each member of a zone's apex keyset
> is represented by a (signed) DS record at the parent, is/are SIG(KEY)s
> necessary?  E.g., If I see this:

Yes, because otherwise we have created a special case that resolvers need
to detect and educate users about. It is simpler to say
    - apex KEY set is signed by a KEY identified in a DS record in parent
    - all RRset in a zone are signed by a KEY in the zone apex set except
      for NS records.
Than add the thrid rule
    - apex key set does not have to be signed when parents DS set contains
      all the keys in the set.

Allowing this will cause operational problems if the child adds or deletes
a DS record, then it needs to start signing the KEY set.
Furthermore how does an off-line signer discover the contents the parents
DS set.

	Olafur


Home | Date list | Subject list