Re: null DK records at the parent

[Olafur Gudmundsson <ogud@ogud.com>]

At 09:21 PM 6/5/2001, Roy Arends wrote:
>[cross-posted reply to dnssec@cafax.se]
>
>On Tue, 5 Jun 2001, Scott Rose wrote:
>
> > I haven't seen much discussion about the DK record draft on this or =
> > cafax.se lists, so I'd thought I'd get the ball rolling:
> >
> > The reason for needing null DK (or KEYs) in the parent, as I see it, is =
> > that a security aware resolver knows to expect a DK or KEY in the glue =
> > data when getting a delegation.  If it doesn't, it knows to query for =
> > them to determine the security status of the child.  If it gets a null =
> > DK/KEY record, then receives a self-signed KEY from the child, the =
> > resolver knows the child is experimentally secure.  In these two =
> > schemes, the parent is responsible for stating the security status of =
> > the delegated child. =20

The main argument for NULL DK is to avoid having to look for the
parents NXT and look inside it.
Background: in order to get the upper/parent NXT a query to an authoritative
server is required. If server is authoritative for both parent and child it may
not give out both NXTs. (The ENDS0 ZONE option addresses this).


> > One thing that might be helpful to add to the DK draft (or the key =
> > rollover draft) is how DK records should be used when performing a key =
> > rollover.  It might be helpful when learning how to perform a secure key =
> > rollover.


I debated putting that in, but decided against that in order to keep the
draft focused on the core idea (not using KEY record in parent).
There are two main key rollover strategies for DK
         3 step (old key, old +new key, new key)
         Master key that does not rollover and only signs the child KEY set.
The master key idea comes from the discussion on how to maintain the same root
key for a long time.


>When using the sig@parent/DK schemes, there is no fundamental difference
>between obsoleting the NULL-key qualification and requiring a NULL-key at
>the parent (it is unnecessary redundant). IIRC RFC 2535 stated that
>sig@parent is optional, and therefore the parent needed to specify some
>info when it wants to specify that the parent regards the child as
>not secured.

See above discussion, but if NXT/NO is tossed out then this is not redundant.



>With the new drafts, the parent is required to give information on the
>childs security status, in the case that the child is secured by the
>parent. If the parent does not consider the child to be secure, obsoleting
>sig/key/DK@parent is sufficient. ie, no information is in this case also
>information.

Correct, if your resolver can talk directly to the authoritative server 
(preferably using TSIG or SIG(0)). Explicit records can be cached for a while
but negative answers can not.


>When a dnssec-aware-resolver stumbles upon a child which claims to be
>secure, I see 3 different options.
>1) the child key is self-signed and the resolver has this key
>    preconfigured:
>    It can easily verify the signatures. (but then, why would this resolver
>    go top down from the root)
>
>2) the child key is self-signed and the resolver has no knowledge of this
>    key: unsecure zone.
>
>3) The child key is signed by some key other then their own or its parent:
>    The resolver needs to securely resolve this key (or could have it
>    preconfigured).

No one is talking about off tree validation so this case does not apply.
RFC3090 does cover the different cases in more gory details.

         Olafur