-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 <matth...@nlnetlabs.nl> To: matth...@pletterpet.nl 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 >> > > 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/ iQEcBAEBAgAGBQJMWmutAAoJEA8yVCPsQCW54XEIANXoOqsg/9SKcAENYn3zkZSK 7/ugGRUbHwO7/4OwjgGfJrdWGqQffqhbazDrqaAfY1o6+nei2A/qKqvPyjrRhijy mDRL8ZfDQtk29h+NAGZXYZzaMZVQnBC7XNICc3Nah7YhWKsl1f5Y87s1GXAueirj hxKe0s5YBWl2xtmp04fTh6YihMwV+P9n0uEZYjUV5RU/hCdCsG2ooiG+U0GLAaio qHTrm+Xx8jGeoTQsjS4TPVsd4nRKN//518X2YfoPNw0d9dMV3drmHCMMSlVympfi tCpZrPzzh1S5xuw41A5PwTwd2WHfk/QUe9QnDQ3Ip4C+bAkyWkPk0s+oKu3Arlo= =kiLD -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
