On Jul 20, 2010, at 5:31 PM, Ondřej Surý wrote: > Olaf, > > here you have diff (against up-to-date SVN) and full text for Key Algorithm > Rollover. The attached text was created as joint effort by me and Olafur. > > Ondrej. >
Thanks Ondrej and Olafur, Turns out that you pulled the text from the SVN just a little early and that I had already modified the table in a way similar to how you modified the table.. :-). Besides the text had changed slightly so the diff did apply cleanly. Anyway, I did copy most of your suggestions. Except that I did not want to clutter the table with RRSIG_ZSK_1(*) since the SOA signature already represents that. I did make a note about that representation in the text leading to the table. Adding the parent is off value, but I choose to follow the representation as in 4.1.2. Also version 3 of the draft had a paragraph about introducing NSEC3, I believe you have special experience in that field, and that paragraph needs careful review. In any case the section now reads as below. I would appreciate a review to see if this is according to your liking. Also see http://tinyurl.com/27odxco for the diffs abains I-D-03 and http://www.secret-wg.org/draft-ietf-dnsop-rfc4641bis.txt for the version on the trunk. --Olaf 4.1.5. Key algorithm rollover A special class of key rollover is the one needed for a change of key algorithms (either adding a new algorithm, removing an old algorithm, or both). Additional steps are needed to retain integrity during this rollover. Because of the algorithm downgrade protection in RFC4035 section 2.2, you may not have a key of an algorithm for which you do not have signatures, and you may not have a DS record in the parent zone of an algorithm for which you don't have a corresponding key in the zone apex. When adding a new algorithm, the signatures should be added first. After the TTL of RRSIGS has expired, and caches have dropped the old data covered by those signatures, the DNSKEY with the new algorithm can be added. After the new algorithm has been added, the DS record can be exchanged using Double Signature Key Rollover. You cannot use Pre- publish key rollover method when you do key algorithm rollover. When removing an old algorithm, the DNSKEY should be removed first, but only after the DS for the old algorithm was removed from the parent zone. The following figure describes the steps. Whereby the trailing underscored number indicates the algorithm and ZSK and KSK indicate the obvious difference in key use. For example DNSKEY_KSK_1 is a the DNSKEY RR representing the public part of the old key signing key of algorithm type 1 while RRSIG_ZSK_2(SOA3) is the RRSIG RR made with the private part of the new zone signing key of algorithm type 2 over a SOA RR (that has serial number 3). It is assumed that the key that signes the SOA RR also signes all other non-DNSKEY RRset data. Kolkman Expires January 13, 2011 [Page 26] Internet-Draft DNSSEC Operational Practices, Version 2 July 2010 ---------------------------------------------------------------- 1 Initial 2 New RRSIGS 3 New DNSKEY ---------------------------------------------------------------- Parent: SOA0 -------------- ( SOA0 )--------------> RRSIGpar(SOA0) -------------------------------------> DS_KSK_1 -------------------------------------> RRSIGpar(DS_KSK_1) -------------------------------------> Child: SOA0 SOA1 SOA2 RRSIG_ZSK_1(SOA0) RRSIG_ZSK_1(SOA1) RRSIG_ZSK_1(SOA2) RRSIG_ZSK_2(SOA1) RRSIG_ZSK_2(SOA2) DNSKEY_KSK_1 DNSKEY_KSK_1 DNSKEY_KSK_1 DNSKEY_ZSK_1 DNSKEY_ZSK_1 DNSKEY_ZSK_1 RRSIG_KSK_1(DNSKEY) RRSIG_KSK_1(DNSKEY) DNSKEY_KSK_2 RRSIG_KSK_2(DNSKEY) DNSKEY_ZKS_2 RRSIG_KSK_1(DNSKEY) RRSIG_KSK_2(DNSKEY) ---------------------------------------------------------------- 4 Exchange DS 5 Remove DNSKEY 6 Remove RRSIGS ---------------------------------------------------------------- Parent: SOA1 -------------( SOA1 )----------------> RRSIGpar(SOA1) -------------------------------------> DS_KSK_2 -------------------------------------> RRSIGpar(DS_KSK_2) -------------------------------------> Child: ---- (SOA2 ) ---> SOA3 SOA4 ----------------> RRSIG_ZSK_1(SOA3) RRSIG_ZSK_2(SOA4) ----------------> RRSIG_ZSK_2(SOA3) ----------------> DNSKEY_KSK_2 DNSKEY_KSK_2 ----------------> DNSKEY_ZSK_2 DNSKEY_ZSK_2 ----------------> RRSIG_KSK_1(DNSKEY) RRSIG_KSK_2(DNSKEY) ----------------> RRSIG_KSK_2(DNSKEY) ---------------------------------------------------------------- Stages of Deployment during an Algorithm Rollover. Step 1 describes state of the zone before any transition is done. Number of the keys may vary, but the algorithm of keys in the zone is same for all DNSKEY records. Step 2: the signatures made with the new key over all records in the Kolkman Expires January 13, 2011 [Page 27] Internet-Draft DNSSEC Operational Practices, Version 2 July 2010 zone are added, but the key itself is not. This includes the signature for the DNSKEY rrset. While in theory, the signatures of the keyset should always be synchronized with the keyset itself, it can be possible that RRSIGS are requested separately, so it is prudent to also sign the DNSKEY set with the new signature. Step 3: After the cache data has expired, the new key can be added to the zone. Step 4: After the cache data for the DNSKEY has expired, the DS record for the new key can be added to the parent zone and the DS record for the old key can be removed in the same step. Step 5: After the cache data for the DS has expired, the old algorithm can be removed. This time the key needs to be removed first, before removing the signatures. The key is removed in this step , and after the cache data for the DNSKEY has expired, the signatures can also be removed during this step. [OK:The following paragrapgh is provisional and needs careful review.] A special case is the rollover from an NSEC signed zone to an NSEC3 signed zone. In this case algorithm numbers are used to signal support for NSEC3 but they do not mandate the use of NSEC3. Therefore NSEC records should remain in the zone until the rollover to a new algorithm has completed and the new DNSKEY RR set has populated distant caches(at least one TTL into stage 4, or at any time during stage 5). At that point the validators that have not implemented NSEC3 will treat the zone as unsecured as soon as they follow the chain of trust to DS that points to a DNSKEY of the new algorithm while validators that support NSEC3 will happily validate using NSEC. Turning on NSEC3 can then be done when changing from zone serial number, realizing that that involves a resigning of the zone and the introduction of the NSECPARAM record in order to signal authoritative servers to start serving NSEC3 authenticated denial of existence. ________________________________________________________ Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
