Re: null DK records at the parent

[Roy Arends <Roy.Arends@nominum.com>]

[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:
> 
> I'm in favor of requiring null DK records at the parent to signify that =
> the delegated child zone is unsecure (or experimentally secure if a KEY =
> record is present).  Both the DK record and the SIG@parent solutions =
> require the delegating parent to store more information about the child =
> zones, but the benefits outweigh the downside of zone database growth.  =
> SIG@child is the only solution that doesn't lead to a larger parent =
> zone, but there are other drawbacks that make it unpopular.
> 
> 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
> 
> If a null DK/KEY record is not required, and a resolver does not find a =
> DK/KEY record from a delegation, but find a KEY record in the child =
> zone, the resolver does not know if the zone is experimental, or secure =
> (and an attacker may have intercepted the delegation message).
> 
> 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.
> 
> Scott

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.

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. 

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).

In any case, important is when a child is bad: 
   only if the parent states that a child is secure, and the child can
   not offer valid signatures. Defining valid in this case: No sigs or
   corrupt sigs.

Regards,

Roy Arends
Nominum