Re: DNSSEC and Parent SIG in Child zone

[Miek Gieben <miekg@nlnetlabs.nl>]

On Sat, Oct 14, 2000 at 09:02:12AM +1100, Mark.Andrews@nominum.com wrote:
> 	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