Subject: Re: DNSSEC and Parent SIG in Child zone

From: [email-masked] (Ted Lindgreen)
Date: Tue, 17 Oct 2000 17:02:44 +0200

[Quoting Edward Lewis, on Oct 17, 15:17, in "Re: DNSSEC and Paren ..."]
> At 9:46 AM -0400 10/17/00, Ted Lindgreen wrote:
> >In case (only) the parent publishes the SIG over the child new KEY,
> >1) and 2) do not change. In 3) the child can also "accept" the
> >invitation by starting to use the new KEY to sign its zone.
> 
> #3 isn't quite right.  If the parent publishes a signed but bad key for
> your zone and you refuse to use the key (or can't), then your data is
> "turned off."

OK, I understand your problem now.  We missed this, because we were
thinking in terms of a two step KEY update in line with the draft
from Mark Andrews:

1. A new KEY is sent to the parent.
2. The parent includes the new KEY in the next zonefile update (with
   a new SIG over both old and new KEY, of course).
3. When the child sees its new KEY appearing in the parents zone, and
   it is OK, it updates its own zonefile with the new KEY (and SIGs).
4. The child asks the parent to remove the old KEY.
5. The parent removes the old KEY in the next zonefile update.

Of course, this is very simplified, because in real-life with TLDs
four parties are involved in the communication:  the registry, the
registrant, the domainholder, and the zone-administrator.

Anyway, if a bad KEY is added, step 3 will be to go back to step 1.

However, this scheme leaves open the problem of mr. Badguy
pretending to be the child and sending in a KEY for a fake-zone.

For this we were thinking of an extra, informational-only message,
bypassing the regular communication channels.

> How about this?
> 
> 1) Child sends keys to parent
> 2) Parent signs keys of child
> 3) Parent sends results of signing to child
> 4) The child verifies the result and tells parent
> 5) If okay, parent publishes, else start over

OK, I like it, and it does solve the mr. Badguy leak also.
It means that our informational message gets replaced with
a real message that must be ACKed. We will try to see
how this fits in.

Thanks,
-- Ted.

---

From: Miek Gieben <[email-masked]>
Date: Tue, 17 Oct 2000 23:21:41 +0200

> a real message that must be ACKed. We will try to see
It is important to note that there is a difference between:
1) a scheduled key renewal request from the child
2) the first key for a child
3) a child's (private) key compromise 

1)
The child _has_ a valid key, so it can sign its request with
that key. Nothing difficult has to be done here.

2)
The most difficult step. The five steps above seem to solve most
of the problems here.

3)
This looks most like its first KEY, as the old key cannot
be trusted anymore. But now there may be extreme timepresure,
especially if this is child has again many children (like a large
 TLD), or is dealing with high volume creditcard transactions.

grtz Miek