Re: [DNSOP] RFC4641bis Editing Status Report.
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. On 20.3.2010 17:10, Olaf Kolkman wrote: Colleagues This is a status update on RFC4641bis. Please refer to links provided for more details on the issues. I have no particular issues I need to discuss in the face to face meeting and will present what is written below in a somewhat condensed form. If folk have something they would like to discuss it is probably best to give a heads-up here. High level summary: Most changes in the document are with respect to the description about keys and key maintenance (section 3). I've tried to stress the operational tradeoffs and make those the basis of the cryptographic considerations. The idea is that the tradeoff between costs and threats set the operational handling of the keys. Once you know how you want to handle the keys operationally set the appropriate crypto parameters. Also there is a completely new section on the Next Record types (section 5) and there are considerations added about the changing ones dns operator (section 4.4.5) In detail - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/HSMs Addressed in a section 3.1.4.3 Private Key Storage I believe this issue to be resolved. - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/NSEC-NSEC3 Complete new section 5. There is one remaining point there brought up in From: Florian Weimerfwei...@bfk.de Subject:Re: [DNSOP] rfc4641bis: NSEC vs NSEC3. Date: February 22, 2010 11:20:16 PM PST To: Olaf Kolkmano...@nlnetlabs.nl Cc: Alex Bligha...@alex.org.uk, Paul Woutersp...@xelerance.com, dnsop WGdnsop@ietf.org NSEC making the packet too big base on the argument that However, NSEC records are sometimes returned in response to DO=0 queries I believe there is consensus that that is caused by an implementation bug. Therefore the issue can be closed. - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Review-NIST Scott reported that this issue can be closed. - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ZSK-roll-frequency - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/cryptography_flawed - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/discussion_of_timescales - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/rollover_assumptions I believe these issues where addressed by reordering and rewriting parts of section 3. But this section may need a little more work to clarify that the approach is from operational perspective rather than a highest achievable crypto perspective. http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/non-cooperative-registrars Added as: 4.4.5.2. Non Cooperationg DNS Operators This issue is resolved although a review of the supporting figure is needed. The following issues have not yet been addressed and the issue needs to be reviewed on relevance against the current version http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_and_parent_keys http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/differentiation_trustanchor_parent http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_configuration http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/timing_terminology I've added http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Signature_validity From the recent mail from Sebastian where he asks for guidance on signature validity intervals that is an issue that is probably closely related to http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/timing_terminology which I will address in the next version. -- Ondřej Surý vedoucí výzkumu/Head of RD department --- CZ.NIC, z.s.p.o.--Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.s...@nic.czhttp://nic.cz/ tel:+420.222745110 fax:+420.222745112 --- $Id: Key_algorithm_roll 38 2010-02-17 14:12:44Z olaf $ 2008090400 Key algorithm rollover section Jelte Jansen Added: 5 Sept 2008 http://www.ietf.org/mail-archive/web/dnsop/current/msg06707.html During some work on DNSKEY maintenance, I think i found a potential operational issue. If we are going to do new work on DNSSEC Operational Practices, I would like to suggest to add a text similar to that attached to this message. The issue lies in the combination of algorithm downgrade protection and caching, and can result in a small window of time (depending on TTLs), where all data in a zone could be considered bogus by validators. RFC4035 states the following (section 2.2): There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset. While this poses no problem when an admistrator rolls a key with
[DNSOP] 4641bis (draft 3) status update
Colleagues, Shortly before the cutt-off I submitted version 3. In this mail I want to raise a number of points that are up for discussion in Maastricht (or on the list). For the Maastricht meeting I plan to use _no_ slides but go through the points one by one and discuss/hum etc. The document can be found at: http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis-03 And the diffs between this and the previous version are highlighted here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc4641bis-03.txt Based on the feedback during last IETF I've tried to differ the tone of the document. The general approach is that the document gives the considerations and motivations for different operational choices and has weakened some of its earlier recommendations. Specifically the arguments for splitting key and zone signing key or using a 'single type signing scheme' have had some attention. One general comment, when you review please do not review for style/typos quite yet. I've received a set of corrections that I've already applied on the trunk[*]. Please review for content now and wait for typos and other editorial nits review till version 4 appeared. - 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. 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) -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). 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. -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. - Point 6 Is Appendix B useful? Or drop it? - Point 7 Any objections on closing the following: - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Key_algorithm_roll - 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 During the authoring of versions 2 and 3 of the document the first issues have been addressed. The differentiation between trustanchor-parent situation has been taken into account but not as drastically as Paul suggested. I believe this issue can be closed after review of version 3 of the document. - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/discussion_of_timescales - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/non-cooperative-registrars -
