On 2011-06-20, at 08:20, Olafur Gudmundsson wrote: >> Are other aspects to operations which you think should be included in the >> document? (Or do you think the scope is too narrow?) >> > > I think the document needs to be clearer as to what is NOT covered in a DSP. > > It is fine for the document to say that it only covers: (in section 1.3) > "As to DNS operational aspects of the zone, Normal DNS operation is outside > the scope of this document but best DNS operational practices are expected". > (as this is a product of the dnsop WG you need to say that or some readers > may have expectations as how to set up name-servers). > > Having said that does the document need to spell out how to recover if the > signing infrastructure fails?
I'm fine with clarifying the scope. Although, I strongly believe we should try real hard to not give recommendations as how to run a zone in the DPS framework document: 1.2. Purpose The purpose of this document is twofold. Firstly, the document aims to explain the concept of a DNSSEC Policy (DP) and a DNSSEC Practice Statement (DPS), and describe the relationship between a DP and a DPS. Second, this document aims to present a framework to encourage and assist writers of Policies and Practice Statements in creating heterogenous and comparable documents. In particular, the framework identifies the elements that should be considered in formulating a DP/DPS. It does not, however, define a particular Policy or Practice Statement, not does it seek to provide legal advice or recommendations as to the contents. >> 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? > > What I want to know is, how does a failure in the signing system, show up? > 1) updates to be blocked i.e. zone will stop processing updates. > 2) New versions of zone will not show up on schedule > 3) bad data will be published but will be replaced as soon as possible? > 4) something else. > > as this may affect Service level agreements having this spelled out is a good > thing. Doesn't this belong in section 4.5.2 (Corrupted computing resources, software, and/or data) of a DPS - described in section 4.4.5 in the framework document? >>> 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. > > I agree this frequently is a Disaster Recovery, but this may also be a policy > decision. > In particular for a tld. having DS removed is estimated to take 2 days, > flushing the DS takes another day, DNSKEY may still trusted by resolvers for > the DNSKEY TTL. > Thus in the case of loss of zone signing the DS must be removed 3 days + > DNSKEY TTL before the first signature in the zone expires. > > If the zone is going to bring up a new signing system (with new keys) is the > zone going be dual signed until old keys are flushed from the system. The intention is that this is to be covered in the same sections as mentioned above (4.4.5 in the framework document). That is where a TLD (or other zone operator) would spell out the policy for recovering from a lost or compromised key. >>> 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. > > Still does not cover if/how long the zone is going to be dual signed. > > As to the planning for algorithm rollover. > > The DSP may say > "before any algorithm rollover a new DSP will be published x months before > the event" > or "in case of introduction of new algorithm in the zone the zone will be > dual signed for x days" > or "zone will NEVER roll algorithm only go to longer keys" > or "zone will change from NSEC3 to NSEC 6 months after x% of the zone has > DS records" > > Algorithm rollover is the scariest part of DNSSEC operation, Ok, I see what you mean. Good point. I'm thinking maybe clarifying on this under "Key lengths and algorithms" (and possibly also under "Authenticated denial of existence"), or do you think we should create a new subsection for it? >> Although, the emergency case (where a algorithm has been fundamentally >> broken) should be covered in 4.5.3 (Entity private key compromise >> procedures). > > I think there are two different cases, that need to be covered, key > compromised and algorithm compromised. > > The first one is important the second one is not a big deal as > DNSSEC is only one of many security systems that will be affected and slow > and deliberate process in this case is better for everyone than quick > over-reaction. > > Thus the document should focus on the first case, by recommending that the > zone publish a time-line for algorithm rollover and include a policy as how > long the zone is going to be dual-signed. Agreed. Although I think it may be worth mentioning the case of algorithm compromise under "Entity private key compromise procedures". Planning for that case may reduce the risk of quick over-reaction. - f _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
