On 2011-06-17, at 13:31, Olafur Gudmundsson wrote: > Few nits and questions below: > > a) DP and DSP should be included in the Definitions section 2, even though > the abbreviations are are defined in section 1.2 > Alternatively spell out in section 3.1. and 3.2 titles what DP and DPS are.
Makes perfect sense. I prefer spelling it out in the section headers to keep the document from growing even further. > b) The document for all practical purposes is about the process until a zone > has been signed/resigned. There is almost no discussion about the operation > of the signed zone is this intentional or an omission ? > (the exceptions are the key rollover sections 4.5.4+5) The document is intended to cover all security-related aspects and topics (including operational) which is impacted by the introduction DNSSEC in a zone. So in this context, technical operation of the signed zone is covered in the key-rollover sections (6.4, 6.5), in the signing/re-signing section (6.6) and the verification of the data to be signed (6.7, 6.8). From a business-operational perspective, contingency and disaster-recovery planning is covered in 4.5 and 4.6. For key management life-cycle operations (such as generation of new keys and possibly also distribution, backup and destruction), should be covered in sections 5.1 and 5.3. Are other aspects to operations which you think should be included in the document? (Or do you think the scope is too narrow?) > c) Section 4.6.9 should not limit itself to TTL's to types it should cover > all types in the zone as the Maximum TTL in the zone impacts how fast keys > can be added/removed from DNSKEY set. Good point, you are absolutely right. SOA expire and negative caching is also part of the equation. > d) Section 4.6.8 does not indicate what the purpose of this test is. > I think the purpose is to prevent bad data from showing up in the DNS. Yes. It currently reads: This subsection addresses the controls around the verification of the resource records in order to validate and authenticate the data to be signed. Should we clarify in that? Suggestions? > f) There needs to be section (4.6.x) for zones that use NSEC3 as to the > policy for changing NSEC3 parameters as this is similar to a ZSK roll-over. The intention is to have this in 6.2. But I see that there are no mentions of policy for changing of NSEC3-parameters in 4.6.2 of the draft. I'm thinking of adding a sentence to the text in 4.6.2 instead of creating a new subsection? > Questions: > > c) should the DPS have a section describing if/when/how a zone (i.e. the one > covered by the DPS) goes to unsigned? There has been discussions about this among the authors, but so far we've agreed on that such procedure is a DR-procedure and may be described in 4.5. > d) Should the DPS have a section describing the zone's policy as how to > perform an algorithm rollover ? > what I'm in particular looking for is in particular how long the zone expects > to be signed by both algorithms. I'm thinking that whatever forces a zone to change the algorithm is an unexpected event which has many dependencies to unknown factors (such as resolver implementations, new algorithms .. ), which is really hard to plan ahead for in such detail. Although, the emergency case (where a algorithm has been fundamentally broken) should be covered in 4.5.3 (Entity private key compromise procedures). -- Fredrik _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
