-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Algorithm rollover is also discussed on namedroppers. Wouter listed some other options you have when algorithm rollover and 5011 are both in place:
* Go MISSING. use the steps for removal without the REVOKE publish step. The key goes into 5011-MISSING state. And is removed after a time (180 or 366 days or so). This may be an alternative for non ZSK-KSK split zones, since they want things easy, and this is easy. * Sign the entire zone with the removed KSK while it is REVOKED as well. Some find this distasteful, but really, it is only a DNSKEY flag, just like the SEP flag and carries meaning only to operators. If you have a ZSK/KSK split you do not have to do this. ! The latter option is, I believe, not true. If you do not introduce a temporary ZSK, you will break 5011-aware resolvers (since they will stop using the revoked key for validation and now theres only signatures of one algorithm validating). So even with a single type key scheme, you need to introduce a (temporary) split when doing algorithm rollover. Nevertheless, I think the first option is nice to include into 4641bis. Best regards, Matthijs On 08/05/2010 09:43 AM, Matthijs Mekking wrote: > There seems something went wrong with the layout on the previous try... > > Matthijs > > -------- Original Message -------- > Subject: 4641bis (draft 3 and 4) review - largely 5011 related > Date: Thu, 05 Aug 2010 09:42:14 +0200 > From: Matthijs Mekking <[email protected]> > To: [email protected] > > > Hi Olaf, > > I noticed there is already a version 4 out, but it merely covers changes > in language and style. So, here is a review of version 3 of the document. > > The KSK RFC5011-based rollover method says that the removed key must be > post-published as revoked at least holdback timer long. However, that > parameter is just a management value for the validating resolver. It > should be post-published as revoked the Maximum Zone TTL long. Proposed > text: > > RFC5011 increases the duration of key rollovers, because the > key to be removed must first be revoked. Thus, before the DNSKEY1 > removal phase, DNSKEY1 must be published for one more Maximum Zone > TTL with the REVOKE bit set. The revoked key must be self-signed, so > in this phase the DNSKEY RRset must also be signed with DNSKEY1. > > This is also true for algorithm rollover. Proposed text: > > Trust anchor algorithm rollover is as simple as a regular RFC5011 > based rollover. The old trust anchor must be revoked before it is > removed from the zone. > > However, at every RRset there must be at least one signature for > each algorithm used in the DNSKEY RRset. This means that a different > key with the same algorithm, other than the revoked key, must > sign the entire zone. This can be the ZSK. More operations is > needed if the single type signing scheme is used. Before rolling the > algorithm, a new key must be introduced with the same algorithm as > the key that is candidate for revocation. That key can than > temporarily act as ZSK during the algorithm rollover. > > End proposed text. > Rolling the algorithm of only the KSK or only the ZSK is in my point of > view infeasible and useless. > > And one more RFC 5011 note: In section 4.2.3 (Compromise of Keys > Anchored in Resolvers), it might be relevant to mention that RFC5011 can > also recover from compromised keys, as long as at least one valid > trust-anchor key remains uncompromised. > > Finally, some editorial nits in version 4: > - You replaced the names of the DNSKEYs in the tables (for example, > DNSKEY_1 becomse DNSKEY_Z_1), but not in the text. > > - In the ZSK pre-publish rollover method, at the DNSKEY removal stage, > the text says re-sign with DNSKEY1. Although not necessary, it should > also be re-signed with DNSKEY11 (DNSKEY_Z_11), because it does so in the > table. > > - In the ZSK double signature rollover method, at the DNSKEY removal > stage, the text says "The key set now only containing DNSKEY 11, is > re-signed with DNSKEY 1." Again, also resign with DNSKEY_Z_11. Also, the > key set also containst DNSKEY_Z_11. > > > Below are some more inline comments. > > Best regards, > > Matthijs > > On 07/20/2010 06:20 PM, Olaf Kolkman wrote: >>>>> - Point 1: >>>>> Is the set of arguments presented for major operational choices (e.g. > single versus ksk-zsk split, >>>>> and key effectivity period) complete and are the arguments fairly > represented? > > ... > >>>>> Addressing all these arguments and considerations has created a > fairly > long document. >>>>> In fact the choice has been to make the document comprehensive in > presenting the considerations >>>>> while not giving strong recommendations one way or another. This > causes the document to be rather >>>>> long and raises the question of the target audience. > IMO, I think it is relevant to present the reader with the possible > options, including all its drawbacks and advantages. Later on, the > reader can always seek into the document to find the section they deployed. > >>>>> Also see: >>>>> > http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/KSK-ZSK-Split >>>>> >>>>> - Point 2: >>>>> Should this document try to give strong recommendations or should a > separate document (set) be made that gives >>>>> recommendations for certain operational environments (e.g. BCP for > root, BCP for TLD, BCP for enterprise)? >>>>> I am looking for specific guidance but as a straw man for consensus: > This document should not give strong >>>>> recommendations but provide comprehensive arguments (like it does > now); development of recommendations is >>>>> left for later, either in a follow up (RFC4641bis-bis) or as a set of > separate documents) > > Based on the previous comments: yes. > >>>>> -Point 3: >>>>> There have also been some questions about what audience the document > is trying to address. >>>>> >>>>> The document is targeted to the 'the authoritative side of the DNS > equation'. Is that indeed what the WG wants? >>>>> If so is that clear enough from the document. (Please send concrete > suggestions to improve if not). > > Yes. > >>>>> If there is consensus that the document talks to the authoritative > side then the chairs may want to ask the >>>>> question as to whether there a need for separate guidance for > resolver > operators, and maybe even ask for volunteers ;-) >>>>> >>>>> >>>>> The following points are more detailed. >>>>> >>>>> -Point 4: >>>>> > http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_configuration >>>>> >>>>> Version 3 of the document has tried to address these issues > (pending a > conclusion of point 3 above) but in order >>>>> to close this issue I would like to know whether "the document > [is] in > any way restrictive on not using 5011, >>>>> or is its consideration for advising RFC5011 to strong?" Silence on > this point will be taken as finding the right balance. > > The text now says: > It is therefore recommended to roll KSKs that are likely to be used > as trust-anchors if and only if those rollovers can be tracked using > standardized (e.g. RFC5011) mechanisms. > > To avoid confusion, I would add "on a regular basis" here. > >>>>> -Point 5: >>>>> > http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Signature_validity >>>>> Text added in 4.4.2, is this text satisfactory >>>>> > http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis-03#section-4.4.2 >>>>> >>>>> The paragraph talks about a Maximum signature validity and Minimum > validity period in fairly broad terms. >>>>> It also provides motivations for differentiating Signature Validity > periods for different RRsets in a zone, >>>>> those motivations are few and week. >>>>> >>>>> Again, is this section complete in providing arguments and are the > arguments fair? If not, what are concrete >>>>> recommendations for improvement. > I am fine with the text in this section/ > >>>>> - Point 6 >>>>> >>>>> Is Appendix B useful? Or drop it? > Already dropped in version 4, I see. Good. > >>>>> - Point 7 >>>>> Any objections on closing the following: >>>>> - > http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Key_algorithm_roll > > Yes, since the issue with RFC5011 popped up during ietf78. > >>>>> - > http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ZSK-roll-frequency >>>>> (take a look at 3.1.1. Motivations for the KSK and ZSK Separation, > the last paragraphs) >>>>> - > http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/differentiation_trustanchor_parent >>>>> - > http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/discussion_of_timescales >>>>> - > http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/non-cooperative-registrars >>>>> - > http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/rollover_assumptions >>>>> - > http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_and_parent_keys >>>>> I think this issue has become obsolete. >>>>> >>>>> Since some of these issues are hard to relate to version 3 of the > draft I would like to >>>>> take the following approach for version 4 of the I-D: mark all above > issues as completed, >>>>> unless I receive further clarification on why I shouldn't (possibly > with suggested text), >>>>> open new issues relative to version 3 of the draft, address those in > version 4. >>>>> >>>>> My target is to have version 4 of the document last call ready. That > is all major issues out of the way, and only nit-fixing. >>>>> >>>>> I am aware of a number of editorial nits[*] >>>>> >>>>> --Olaf >>>>> >>>>> [*] See http://www.secret-wg.org/draft-ietf-dnsop-rfc4641bis.txt > for a > snapshot of the living document and http://tiny.cc/6sllt >>>>> for the difference between the living document and the draft > version 3 > as it lives in the repository. >>>>> >>>>> ________________________________________________________ >>>>> >>>>> Olaf M. Kolkman NLnet Labs >>>>> Science Park 140, >>>>> http://www.nlnetlabs.nl/ 1098 XG Amsterdam >>>>> >>>>> _______________________________________________ >>>>> DNSOP mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list [email protected] 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/ iQEcBAEBAgAGBQJMWtSEAAoJEA8yVCPsQCW5DukH/0Bz2Nd442aiTiLGMMik2Q7v cj8HDwzME5nzH9CFeN2+m9uzZSO4aPS6GLwQ24JG0By/vS2WsBXDgaVFttsPbqHp dU3c0GyZTxaCvBXoQFw8DUT36SESaqPUQjbKh4y8Vr81Hl2+THKOpISTd6AAejeN PcypXYuqdsnj6DbHEP78oXQ7OyOoZ5NxtT9iqsUfJNpIY8ZRawDgjQYzviZYMR6Q oFwQtao8azJT3znffh0jEkIcdxc4oGJooDZt98cF2hNJzQhvK1OIi/K7WlIW+AIa uyuEJ/29vZF++bRNtvUQ9zrMW0AAeW0TfLcZWj5l6vOHH2FJQ60AIY7TKtCzo9E= =fPfH -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
