-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
I agree that the Double-DS approach is more practicable than the current rollover for cooperating operators. This is mentioned very briefly in the -06 version (last paragraph 4.3.5.1). However, we do want to provide an alternative for registries and registrars that does not allow a Double-DS rollover scheme. I do want to describe the cons of the current approach in more detail (the ones you have mentioned in your mail). If it is necessary to add the corresponding figure, it should then probably go into an appendix. Proposed text (to replace the last paragraph in 4.3.5.1): The requirement to exchange signatures has a couple of drawbacks. It requires more operational overhead, because not only the operators have to exchange public keys, they also have to exchange the signatures of the new DNSKEY RRset. Also, it disallows the children to refresh the signatures when they expire for a certain period. Both drawbacks do not exist if you replace the Double Signature KSK rollover with a Double-DS KSK rollover. Thus, if the registry and registrars allow for DS records to be published, that do not point to a published DNSKEY in the child zone, the Double-DS KSK rollover is preferred (also known as Pre- Publication KSK Rollover, see Figure 5), in combination with the Pre- Publish ZSK rollover. This does not require to share the KSK signatures between the operators. Both the losing and the gaining operator still need to publish the public ZSK of each other. Best regards, Matthijs On 04/20/2011 01:43 PM, Antoin Verschuren wrote: > On 20-04-11 11:58, Matthijs Mekking wrote: >> Hi Antoin, > >> It is assumed that in the cooperating case, both operators allow >> publishing of the signatures. > >> So they don't create the signature themselves, they merely copy the >> signature and publish it in their version of the zone. > > Ok, so that's a second option I hadn't thought about, because it is > impractical in practice. I guess in theory this will work, but only if > the zone, DNSKEYset and RRSIGs are static for the complete rollover period. > > In the case I have seen and discussed so far, only the public keys were > exchanged, and not the signatures. Exchanging signatures takes again > another step in the process, as a new signature can only be created > after recieving the new keys. And it only works if the signatures have > an expire that is longer than the transfer process. > > When you use the Doule-DS rollover, child A only needs to recieve B's > new public keys, and signs it only with KSK_A. child B has allready > queried A's public keys and has allready signed the DNSKEY set with only > KSK_B. > For the Double-DS method, that is sufficiant. > > I guess you can now also have child A copy RRSIG_K_B(DNSKEY) and child B > copy RRSIG_K_A(DNSKEY), but this is another step in the process that > consumes propagation time and extra interaction. It also disallows the > childs to refresh the signatures when they expire, unless they have yet > another interaction. > > This was the scheme I had in mind with Double-DS and cooperating DNS > providers: > > ------------------------------------------------------------ > initial | Double DS | > ------------------------------------------------------------ > Parent: > NS_A NS_A > DS_A DS_A > DS_B > ------------------------------------------------------------ > Child at A: Child at A: Child at B: > SOA_A0 SOA_A1 SOA_B0 > RRSIG_Z_A(SOA) RRSIG_Z_A(SOA) RRSIG_Z_B(SOA) > > NS_A NS_A NS_B > RRSIG_Z_A(NS) RRSIG_Z_A(NS) RRSIG_Z_B(NS) > > > DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_A > DNSKEY_K_A DNSKEY_Z_B DNSKEY_Z_B > RRSIG_K_A(DNSKEY) DNSKEY_K_A DNSKEY_K_A > DNSKEY_K_B DNSKEY_K_B > RRSIG_K_A(DNSKEY) RRSIG_K_B(DNSKEY) > ------------------------------------------------------------ > > ------------------------------------------------------------ > Redelegation | post migration | > ------------------------------------------------------------ > Parent: > NS_B NS_B > DS_A DS_B > DS_B > ------------------------------------------------------------ > Child at A: Child at B: Child at B: > > SOA_A2 SOA_B1 SOA_B2 > RRSIG_Z_A(SOA) RRSIG_Z_B(SOA) RRSIG_Z_B(SOA) > > NS_B NS_B NS_B > RRSIG_Z_A(NS) RRSIG_Z_B(NS) RRSIG_Z_B(NS) > > > DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_B > DNSKEY_Z_B DNSKEY_Z_B DNSKEY_K_B > DNSKEY_K_A DNSKEY_K_A RRSIG_K_B(DNSKEY) > DNSKEY_K_B DNSKEY_K_B > RRSIG_K_A(DNSKEY) RRSIG_K_B(DNSKEY) > > > ------------------------------------------------------------ > > There is less data to exchange. > > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNrtIpAAoJEA8yVCPsQCW53+EIALPXM+p5pHPyc3ZmEXvbwMJz YEUanA6RJioVDrM2UCtu6c5MToYTBI4tLUbTzNJy7ngR36MG55GkHnasIHKA3Jxw K8ETro5Y1FZsxRS4q5FWXCVNBcd62/W0b2oI3LwZZ3d25oH+1QWfothzmmQMgkSH QFRd5iJXbL3iiNEaC+VG322eNNn65LUwtu32mMwnng0Gj64GV8dKjCk+84ct2EIK aQQvNHEf2bgrxtyS+7KYP2HiVaInb/EU6d+JzsVwIdUHuJgEi8OU/9zBEFbBZJPf DDd0hE2TLZbyup7Fcy9v3vbmDaqYt0OhilIoTK2JWG9IMrDNsP59Z8bgFPvkh3c= =ukah -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
