A bit of a late reply, but prodded by the fact that Matthijs has replied to comments on the -bis version...
On 21/04/2011 14:19, Marc Lampo wrote: > 2.2. KSK Rollovers > ... In the KSK case this can never be a problem as the KSK is only > used for one signature ... > > Administrators should use the KSK only to sign the DNSKEY RRset, > but implementations may allow to use the KSK for *all* RRset's. > --> shouldn't the "is only used" be "should only be used" ? Our feeling here is that although this is a possibility, a KSK used in this way is really more of a single type signing key and different considerations (not discussed in the document) apply. For this reason, we're in favour of leaving it as is. > (next paragraph) > Trust in the KSK is either due to the existence of a DS record in the > parent zone (which is itself trusted) or ... > > I object to the phrasing : "which is itself trusted". > It should not be interpreted that the mere existence of a DS record > makes it trustworthy. In reality, the DS record is trusted > because the accompanying RRSIG can be validated. True. How about: "Trust in the KSK is either due to the existence of a signed and validated DS record in the parent zone or..." > 2.3. Summary > (only) two methods : ZSK Method and KSK Method. > > In draft-ietf-dnsop-rfc4641bis-06.txt, section 3.1, there is > motivation to not always distinguish between KSK and ZSK. (While I am > not in favour of global recommendation for this (no distinction), if > an administrator chooses not to differentiate, this does introduce a > third method, > combining both. I think this draft should describe > associated issues as well) The idea of a single type signing scheme has gained currency in the time it has taken for the key timing draft to get this far. As we could end up aiming at a moving target, we have decided to explicitly limit the scope of the draft in a bid to get something to completion. (This is discussed in section 6.) > In addition, in my comment on that draft, earlier this week, I contributed > my observation that some DNSSEC'd domains use 3 keys for rollover : > initial situation : key1 & key2 > start of rollover : add key3 --> key1 & key2 & key3 > end of rollover : remove key1 --> key2 & key3 > > I don't think this is covered by any of the Methods in this draft (of > key-timing). > Leave it to the authors if they want to consider and include this > method for timing considerations. > For clarity : I did *not* invent this method, I merely noticed it > being used "out there" ! > Nor do I know if the authors of rfc4641bis will include this method of > rollover at all ! We don't think this is a new method; essentially it is a rollover of key1 to key3, but with the added security of the presence of an extra key (key2). As a result, some of the timings can be relaxed: assuming that key2 has been in the zone long enough that it can be used to validate signatures, then there is no need to wait until key1's information has reached all validators before removing key3. What do other WG members think? Should there be some mention in the draft of the effect that additional keys can have on rollover timings? > 3.1 Key States > Ready : The new key data has been published for long enough to > guarantee that any previous versions of it have expired > from cache. > > I object to the phrasing : "previous versions of it". > (as long as a key exists, all "versions" are identical (keyid, > algorithm, value); > What is really meant : "any previous versions of the DNSKEY RRset". > Where the next "preceding" version of the DNSKEY RRset, is a RRset > where the new key is not yet present, with its DNSKEY record) Good suggestion - we'll update the text. > Retired : The key is in the zone but a successor key has become > active. As there may still be information in caches that > that (word is present twice !) require use of the key, > it is being retained until this information expires. > > I would additionally state : > The key, in Retired state, is no longer used for generating RRSIG's. > > Also, instead of "information in caches", I propose : > As there may be RRSIG's present in caches, > RRSIG's that were generated with this key, > the key is being retained until those RRSIG's expire themselves. > (because : "information" is really "RRSIG's generated with this key", > isn't it ?) How about: Retired: A successor key has become active and this key is no longer being used to generate RRSIGs. However, as there may still be RRSIGs in caches that were generated using this key, it is being retained in the zone until they have expired. > 3.2.1 - 3.2.2 - 3.2.3 - 3.3.1 - 3.3.2 - 3.3.3 > (each time : the time flow) Not sure what you mean here. > There is always an event "Tgen", > but there is never an event "generation of the new key". > > To be consistent, the generation of the new key should be added. > However, this complicates the time flow. > > My recommendation is not to show "Tgen" at all. > It is obvious that a key must be generated before it can be published. > But I don't think showing this event in the time flow has any > additional contribution. > > I do realise that the text that goes with this event > states that Tgen might be the generation of "a pool of keys". > > OK - perhaps we can live with this single "Tgen" + text; > otherwise there is no reason for the state "Generated", > and keys would come "out of nowhere" to the state "Published", > which might be even more confusing. Our preference is to leave it, but do other WG members have an opinion on this? Stephen _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
