To:
dnsop@cafax.se
From:
Miek Gieben <miekg@nlnetlabs.nl>
Date:
Fri, 20 Oct 2000 12:30:16 +0200
Sender:
owner-dnsop@cafax.se
Subject:
Re: DNSSEC and Parent SIG in Child zone
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