Subject: Re: DNSSEC and Parent SIG in Child zone

From: [email-masked] (Ted Lindgreen)
Date: Tue, 17 Oct 2000 15:46:16 +0200

[Quoting Edward Lewis, on Oct 16, 21:22, in "Re: DNSSEC and Paren ..."]

> At 9:49 AM -0400 10/13/00, Ted Lindgreen wrote:
> >Reason to ask this, is that there seems no security-technical reason
> >to have this SIG in the parent zonefile instead.
> 
> How about this:
> 
> Having the parent publish the keys eliminates a beneficial three-way
> handshake.   (How beneficial is open to question.)  Given the current
> definition:

I fully agree that a three-way handshake is desirable.  However,
I am not sure that having the parent publish the keys eliminates
this handshake:

> 1) The child "signals" the intent to be secure by submitting keys to the
> parent.
> 
> 2) The parent "acknowledges" the child's desire to be secure by signing
> 
> 3) The child "accepts" this invitation by publishing the keys.  The

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.

> important part of this step is that the child has the option, once the
> parent has returned the signature, to decide if the signature is right.

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.

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

> 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 independend of where the SIG will be
located after having been generated.

Regards,
-- Ted.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 17 Oct 2000 10:15:22 -0400

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

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

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

>However, this problem is independent of where the SIG will be

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