Subject: null DK records at the parent

From: "Scott Rose" <[email-masked]>
Date: Tue, 5 Jun 2001 10:02:34 -0400

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

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Roy Arends <[email-masked]>
Date: Wed, 6 Jun 2001 03:21:26 +0200 (CEST)

[cross-posted reply to [email-masked]]

> rollover.  It might be helpful when learning how to perform a secure key =

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

---

From: Roy Arends <[email-masked]>
Date: Wed, 6 Jun 2001 04:03:09 +0200 (CEST)

> > I haven't seen much discussion about the DK record draft on this or =
[snip]

>    not offer valid signatures. Defining valid in this case: No sigs or

Eh, skip that, this should read:

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

Regards,
 
Roy Arends
Nominum

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 05 Jun 2001 23:34:29 -0400

> > schemes, the parent is responsible for stating the security status of =

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

> > rollover.  It might be helpful when learning how to perform a secure key =

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.

>info when it wants to specify that the parent regards the child as

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

>sig/key/DK@parent is sufficient. ie, no information is in this case also

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.

>    The resolver needs to securely resolve this key (or could have it

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

---

From: Roy Arends <[email-masked]>
Date: Wed, 6 Jun 2001 14:53:02 +0200 (CEST)

> parents NXT and look inside it.

Looking at DK RR type in the nxt@parent for the child or looking for a
NULL-DK@parent for the child is to me the same. The secure resolver has to
do 1 lookup in both cases. This is ofcourse when NXT/NO are not tossed
out.

> not give out both NXTs. (The ENDS0 ZONE option addresses this).

This I had overlooked. Is it valid though to require huge amounts of
information (ie. null-DK RRs) for the rare case that parent and child are
both secure and are served by the same server ? Looks to me like a
paradox. Especially those servers that serve both secured parents and
secure childs do not have the burden of serving null-DK RRs. 

If this is assumed to be valid I see no alternative then requiring
null-DK. 

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

True, but this discussion was on obsoleting NULL-DK RR, not on obsoleting
NXT/NO records. 

> but negative answers can not.

Thats true, especially when NXT/NO records are tossed out. My reply was
written with a requirement for NXT/NO records in mind.

Regards 

Roy Arends
Nominum