-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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/
iQEcBAEBAgAGBQJMWmreAAoJEA8yVCPsQCW57GAH/3Fpnh+diHbNhHSw41lcm/CL piukCIHbrHOx+5SIW1UwbRWF045DPGkozw2wEy3i10v40yw+hnQ6pIqjPC/nvl+l t8xbt8PHfBsKxCMcpM8IjZ8wjw1yzcn5WXZ9SzHVrx0zGPkLsGot4s9qCkAnYlI/ +VQLiBkNCtJDbiKj6qHsOUDyXORvtW4P3SfeCxU8V7g3/EMCUzjlCJQkucU5K9bR Axvj+xtKEMlmNvvmyTKNKA1Ne1l9i/Wrndg5KF3SUNaFEPz3dbB5ky3p9WfqAWbf 5vKw9McfusjgZ/jI7/O9neZg0VAGzpfy0ONeTzK6wdUhP//QJao9mlijr5d7RzU= =xVkq -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
