Re: DNSSEC and Parent SIG in Child zone

[Edward Lewis <lewis@tislabs.com>]

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

I am now preparing for an upcoming workshop and configured a root key in my
test server.  Everytime I query for data outside the experiment, named
fails to respond.  Turning on debugging I see that "real" data is arriving,
but because I have configured a root key and there is no "real" root key,
named is judging the data to be bad.

So, if the parent is trusted by a resolver, the resolver will trust the
child's key and ignore a child that refuses the new key.

>Cryptograhically, or security-technically I see no difference
>between a child:
>1. verifying a parent-SIG over own-KEY with parent-KEY, then
>   including the parent-SIG in own zonefile, and then starting
>   to use the new KEY.
>2. verifying a parent-SIG over own-KEY with parent-KEY, and
>   starting to use the new KEY.

Let me rewrite 2 if you will:

 2. verifying a parent-SIG over own-KEY with parent-KEY, then
    relying on the parent-SIG being in the parent file, and
    starting to use the new KEY.

You are right about these two being the same cryptographicaly, but the
issue is not cryptographic.  The issue is what happens when something goes
wrong.  Try to think of the two situations in which the "verifying" fails.
In 1, the parent-SIG is not published, in 2, the parent-SIG is published
against our wishes.

>Please note, that in order to verify the parent-SIG, one has to
>consult the parent-zone anyway to collect the parent-KEY.

Of course.  This issue isn't getting the parent key correctly, it's knowing
whether the parent has gotten the child's key correctly.

>> I.e., what if someone adds or modifies the keys between the time the child
>> sends them and the parent receives them?  The parent won't know this and
>> publishing the erroneous keys and the signature would be a problem.
>
>This is a very serious problem. In fact, we see the verification by
>the parent before signing a childs zone-KEY as the most critical
>part (in terms of security) of implementing DNSSEC at TLDs.
>
>However, this problem is independent of where the SIG will be
>located after having been generated.

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

This is a lot more overhead, but the parent's SIG can stay in the parent
and the child has approval.  How resistent this is to a masquerade I don't
know, I just am floating this idea.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: lewis@tislabs.com

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

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