Sorry, late again, but I have read through the draft and I did not find any errors. I found an earlier version very useful in getting to grips with DNSSEC's timing constraints, so I'm keen to see it published. I really like the formalism and careful presentation style.
I have a couple of observations: The timelines cover the entire lifetime of a key. This means they typically cover one and a half rollovers: the key is introduced (then there's nothing about retiring the old key) then its successor is introduced, then the key is retired. I find this a bit distracting and I would prefer it if the timelines were oriented around a single rollover. Secondly, there is a fairly simple set of rules underlying all rollovers, which I don't think I have seen written down - the existing descriptions explain the processes that result from these rules, but leave them implicit. For ZSKs, the rules are: (1) You must remove the old ZSK after adding the new ZSK. (2) You must remove the old RRSIGs after adding the new RRSIGs. (3) You must wait for the new ZSK to propagate before removing the old RRSIGs. (4) You must wait for the new RRSIGs to propagate before removing the old ZSK. By "propagate" I'm including propagation to all authority servers and expiration of previous versions of the records from all caches. Each kind of rollover comes from adding an extra criterion: Pre-Publication: minimise the time between adding the new RRSIGs and deleting the old RRSIGs. Double-Signature: minimise the overall time taken by the process, or minimise the number of phases. Double-RRSIG: minimise the time between adding the new ZSK and deleting the old ZSK. For KSKs, the rules are: (5) You must remove the old DS after adding the new DS. (6) You must remove the old KSK after adding the new KSK. (7) You must wait for the new DS to propagate before removing the old KSK. (8) You must wait for the new KSK to propagate before removing the old DS. Each kind of rollover comes from adding an extra criterion: Double-Signaure: minimise the time between adding the new DS and removing the old one. Double-DS: minimise the time between adding the new KSK and removing the old one. Double-RRset: minimise the overall time taken by the process, or minimise the number of phases. If you have a single key-type signing model, you need to take the union of the rules (and rules 1 and 6 combine). The same applies when rolling both keys at once, e.g. when changing operators. When you are changing operators, changing the NS records effectively does the adding and removing implied by the differences between the zones at the old and new operators. Tony. -- f.anthony.n.finch <[email protected]> http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
