Subject: Re: Redux: Why I want to remove the null key (SIG)

From: [email-masked] (Ted Lindgreen)
Date: Thu, 15 Jun 2000 14:18:00 +0200

[Quoting Bill Manning, on Jun 15, 14:06, in "Re: Redux: Why I wan ..."]
> 
>  Thanks. That the notification method is not specified should be made clear.

A list of what actions are needed to implement security might
clarify things.  Let's work out the KEY signing issues at a
delegation point.

We define the following possibilities:

1. Parent and child both unsecured.

2A. Parent is secured, child still unsecured.

2B. Child is secured, parent still unsecured.

3A. Parent and child both secured, parent signs childs key.

3B. Parent and child both secured, child is specially signed.

Note: this scheme can be applied everywhere in the DNS-tree, by
noting that at the root the child is the root and the parent does
not exist and only 1 and 2B are defined.

Going from 1 ==> 2A:
 - This is a parent-only action:
   The parent MUST sign a null-KEY for the child. Typically
   the parent will start holding this KEY in its zone file.

Going from 1 ==> 2B:
 - This is a child-only action:
   We have a "secured entry point" in the DNS tree here.
   The child must have its KEY signed in some special way, and
   has to take care that the resolvers of interest are pre-
   configured with the secured entry point and a KEY to
   verify the zone KEY.

Going from 2A => 3A:
 - Child action:
   When the null-KEY is still in the parent-zone file, the child
   must copy it into its own zone file and ask the parent to
   remove it from his zone file.
 - Parent action:
   Remove null-KEY.
 - Child action:
   The child must generate a real zone KEY and ask its parent
   to sign it.
 - Parent action:
   Verify request and sign the childs zone-KEY.
 - Child action:
   Replace the old unsecured zone file with null-KEY by the
   signed zone file and become secured.

Going from 2A => 3B:
 - Child only action:
   identical to "1 ==> 2B".
 - Note that the parent signed null-KEY remains in place.

Going from 2B => 3B:
 - Parent-only action, identical to "1 ==> 2A"

Going from 2B => 3A:
 - Parent action, identical to "1 ==> 2A"
 - Child action:
   Copy its parent signed null-KEY from parent zone-file into
   own zone file.
   Ask parent to sign its zone-signing KEY.
 - Parent action:
   Remove null-KEY from zone-file.
   Verify request and sign the childs zone-KEY.
 - Child action:
   Replace the special SIG by the parents SIG and
   remove the parent signed null-KEY.
 
There are a number of vulnerabilities, the obvious ones are
going towards 3A:

1. As long as the parents SIG over the old null-KEY is valid,
   the child zone can be zone-jacked.
   Therefore, null-KEY SIGs should not have long expiration
   times.
2. The verification by the parent that a KEY, presented by
   a child is indeed sent by someone authorative for this
   child is essential, but far from trivial.

Note that the functionality of the null-KEY is essential
and can not be removed.

Regards,
-- Ted.

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

---

From: Edward Lewis <[email-masked]>
Date: Fri, 23 Jun 2000 11:07:00 -0400

>   Therefore, null-KEY SIGs should not have long expiration

This would be counter to the efforts of the owner of a largely delegation
zone.  How or where should this recommendation/requirement be
specificed/enforced?

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"It takes years of training to know when to do nothing" - Dogbert

Opinions expressed are property of my evil twin, not my employer.