[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Edward Lewis <lewis@tislabs.com>, Ted.Lindgreen@tednet.nl
Cc: dnsop@cafax.se, dnssec@nlnetlabs.nl
From: ted@tednet.nl (Ted Lindgreen)
Date: Tue, 17 Oct 2000 17:02:44 +0200
In-Reply-To: "Edward Lewis's message as of Oct 17, 15:17"
Reply-To: Ted.Lindgreen@tednet.nl
Sender: owner-dnsop@cafax.se
Subject: Re: DNSSEC and Parent SIG in Child zone

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

Home | Date list | Subject list