Subject: Re: DNSSEC and Parent SIG in Child zone

From: [email-masked] (Ted Lindgreen)
Date: Sat, 14 Oct 2000 11:56:43 +0200

[Quoting Mats Dufberg, on Oct 14,  9:48, in "Re: DNSSEC and Paren ..."]
> On Fri, 13 Oct 2000, Edward Lewis wrote:
> 
> > BTW - do the top level delegators want to be storing the KEY's for all of
> > the children zone's?  I thought this would be a thing to avoid.
> 
> That would increase the size of the TLD zone many times. That would
> probably delay the implementation of DNSsec in TDL zones.

-  At installation time of DNSsec in TDL zones, most of the subzones
   will not be secure (yet). So, NULL-KEY records for most of the
   children will be in the TLD zone at startup anyway.
-  It is not only the KEY that bothers, the generation and maintenance
   of the the SIG over the KEY is more of a problem. So, although a real
   KEY is somewhat larger than a NULL-KEY, this makes little difference.
-  Although the size of the TLD zone and other technical issues are a
   concern, it is the organizational (administratic and legal) burden
   that comes with DNSsec that scares the TLD registries most.

So, zonefile size is not a strong reason to avoid having parent
signed child-KEYs in parent zones.

If the organizational burden would be less, that would be a
strong reason.

But sofar, with all scenarios we have been working out, we found
that the organizational burden for a registry when storing and
signing the child-KEY in their zone is little different or even
less compared with storing and signing them in an off-line database.
We also worked out scenarios where the parent does not store the
child-KEYs at all, and signs them on out-of-band requests.
This seems OK at first sight, but we found the burden comes back
even stronger when the TLD needs to refresh its own KEY.

But perhaps we have overlooked some better scenario?  If so, please
help us out!

If there is no better scenario, then storing (and signing) child KEYs
in parent zonefiles is something that will happen at TLDs.

And the question remains: is there a strong reason why the
parent-SIG must be duplicated in the child-zone?

If not, that would help the implementation of DNSsec in TDL zones
enormously. This is, because we have not found a solid solution to
guarantee that parent-SIGs in child-zones are in sync with the parent
KEY always. And if out of sync, child-zones will drop of the Internet
and the registries can expect damage claims and other horror.
Perhaps also here we overlooked the better solution, so if you
sees this solution, please tell us.

Regards,
-- Ted.

---

From: Miek Gieben <[email-masked]>
Date: Fri, 20 Oct 2000 12:30:16 +0200

I haven't seen my reply on the list. So I'm posting it again.
These are some comments on the key rollover draft.

> The rollover draft is looking at a method to support this
> by automating some / all of it.  Feed back on that would be
> useful.
We've studied the draft and it is a very clever scheme for a
scheduled key rollover when a the parent's SIG is located in
the child's zone and three generations are involved.
We've looked at the implications for large zones and 
we feel that it is impractical and difficult to implement
this scheme in the ccTLD's we dealing with. What is not 
covered by this scheme is an unscheduled rollover. For instance
when a key of a middle zone (a ccTLD) gets compromised and a
rollover must take place overnight.

A few further remarks,

In section 1, fourth paragraph:
   In a widely deployed DNS security system, the volume of update
   traffic will be large.  Just consider the .com zone.  If only a few
   percent of its children are secure and change their keys only once a
   year, you are talking about hundreds of thousands of new child public
   keys that must be securely sent to the .com manager to sign and

Perhaps you could clarify what you mean by "securely sent"?
We think encryption of the channel is not needed for this kind
of communication. Authentication and verification are most important:
the parent (or .com manager) needs to know that it is signing
a key from a legitimate representative of the child.

   return with their new parent signature.  And when .com rolls over its
   private key, it will need to send hundred of thousands of new
   signatures on the existing child public keys to the child zones.

We are still wondering if this step is really needed. 

This is the table in the draft:

          BEFORE ROLLOVER        SHORTLY AFTER             AFTER ROLLOVER

       p.x     KEY      P1     p.x     KEY      P1     p.x     KEY      P1
       p.x     SIG(KEY) P1     p.x     SIG(KEY) P1     p.x     SIG(KEY) P1
       p.x     SIG(KEY) GP     p.x     SIG(KEY) GP     p.x     SIG(KEY) GP

       m.p.x   KEY      M1     m.p.x   KEY      M2     m.p.x   KEY      M2
       m.p.x   SIG(KEY) P1     m.p.x   KEY      M1     m.p.x   SIG(KEY) P1
       m.p.x   SIG(KEY) M1     m.p.x   SIG(KEY) P1     m.p.x   SIG(KEY) M2
                               m.p.x   SIG(KEY) M2

       c.m.p.x KEY      C1     c.m.p.x KEY      C1     c.m.p.x KEY      C1
       c.m.p.x SIG(KEY) M1     c.m.p.x SIG(KEY) M2     c.m.p.x SIG(KEY) M2
       c.m.p.x SIG(KEY) C1     c.m.p.x SIG(KEY) M1     c.m.p.x SIG(KEY) C1
                               c.m.p.x SIG(KEY) C1

         p = parent, m = middle, c = child, GP = grandparent key
         P* = parent key, M* = middle zone key, C* = child key

We had a problem understanding what sigs change in the table. 

If you write the table like this things maybe clearer:
(we also leave the self signed sigs out, x = label)

   BEFORE ROLLOVER           SHORTLY AFTER                  AFTER ROLLOVER
	
p.x     KEY           P1   p.x     KEY             P1    p.x     KEY          P1

m.p.x   KEY           M1   m.p.x   KEY             M1            ---            
        ---                m.p.x   KEY             M2    m.p.x   KEY          M2
m.p.x   SIG(KEY(M1))  P1   m.p.x   SIG(KEY(M1,M2)) P1    m.p.x   SIG(KEY(M2)) P1 

c.m.p.x KEY           C1   c.m.p.x KEY             C1    c.m.p.x KEY          C1
c.m.p.x SIG(KEY(C1))  M1   c.m.p.x SIG(KEY(C1))    M1            ---            
        ---                c.m.p.x SIG(KEY(C1))    M2    c.m.p.x SIG(KEY(C1)) M2

In our scheme the tables becomes:

   BEFORE ROLLOVER           SHORTLY AFTER                  AFTER ROLLOVER

p.x     KEY           P1   p.x     KEY             P1    p.x     KEY          P1
m.p.x   SIG(KEY(M1))  P1   m.p.x   SIG(KEY(M1,M2)) P1    m.p.x   SIG(KEY(M2)) P1

m.p.x   KEY           M1   m.p.x   KEY             M1            ---            
        ---                m.p.x   KEY             M2    m.p.x   KEY          M2 

(there is no interaction with the child)

Comments are appreciated,

Miek Gieben,
NLnet Labs