On May 18, 2012, at 11:30 AM, Suresh Krishnaswamy wrote: > I'm reading 4641bis after a really long time and the current version appears > useful and very well done. So I'd like to applaud the editors and working > group for bringing this document into such good shape. > > Leaving aside the nits, here are some of my comments on -11. > > > 3.2.1. Rolling a KSK that is not a trust anchor > There are 3 schools of thought on rolling a KSK that is not a trust > anchor: > > o It should be done frequently and regularly (possibly every few > months) so that a key rollover remains an operational routine. > > o It should be done frequently but irregularly. Frequently meaning > every few months, again based on the argument that a rollover is a > practiced and common operational routine, and irregular meaning > with a large jitter, so that 3rd parties do not start to rely on > the key and will not be tempted to configure it as a trust anchor. > > o It should only be done when it is known or strongly suspected that > the key can be or has been compromised, or when a new algorithm or > key storage is required. > > > SK> I'd add a fourth: > > o It should be done in conjunction with operator change policies and > procedures so that new operators are adequately prepared to conduct > unscheduled key rollover operations should the need arise.
This seems like a good addition. It incorporates the ideas that key rollover procedures need to passed forward to new operators. > ----------------------------- > > 3.2.2. Rolling a KSK that is a trust anchor > > ... > > It is therefore preferred to roll KSKs that are likely to be used as > trust anchors on a regular basis if and only if those rollovers can > be tracked using standardized (e.g. RFC 5011) mechanisms. > > > SK> The problem with this the above para is that there is no way to > verify that the rollovers are being tracked by automated mechanisms. > Perhaps the guidance ought to be: > > Thus, if a KSK is intended to be used as a trust anchor it is > advantageous to use an aggressive rolling schedule initially, in > order to build confidence in the validating client's ability to track > these rollovers on an ongoing basis. +1 to this idea. > > > ----------------------------- > > > 3.2.3. The use of the SEP flag > > ... > > anchor. Therefore, it is suggested that the SEP flag is set on keys > that are used as KSKs and not on keys that are used as ZSKs, while in > those cases where a distinction between KSK and ZSK is not made (i.e. > for a Single Type signing scheme), it is suggested that the SEP flag > is set on all keys. > > Note that signing tools may assume a KSK/ZSK split and use the (non) > presence of the SEP flag to determine which key is to be used for > signing zone data; these tools may get confused when a single type > signing scheme is used. > > > SK> Suggest deleting the second para above and adding the following text at > the end of the first para instead. > > Similarly, it is suggested that validators configure Trust Anchors > for only those keys that have the SEP flag set. Signing tools should > not merely use the absence of the SEP flag as the sole discriminator > while identifying the Zone Signing Keys within a keyset. > > > ----------------------------- > > > 3.3. Key Effectivity Period > > ... > > The motivation for having the ZSK's effectivity period shorter than > the KSK's effectivity period is rooted in the operational > consideration that it is more likely that operators have more > frequent read access to the ZSK than to the KSK. If ZSKs are > maintained on cryptographic Hardware Security Modules (HSM), then the > motivation to have different key effectivity periods is weakened. > > SK> I don't understand the rationale for the above. The effectivity > period of the ZSK should have no relation to the number of times it is > read (and not even on the number of signatures created using it, > as I think I read on this list). Maybe what we want to say here is that > > In cases where the ZSK cannot be afforded the same level of > protection as the KSK (such as when zone keys are kept online), and > where the risk of unauthorized disclosure of the ZSK's private key > is not negligible (e.g. when HSMs are not in use), the ZSK's > effectivity period should be kept shorter than the KSK's effectivity > period. This circles back to the permathread on why even have a split between the two types. If an operator needs to read a key, they need to read a key. If doing so is dangerous to the sanctity of the key, the operator has really crappy policies. There is no conceptual reason that reading a key is dangerous. > ----------------------------- > > > 4.1.2. Key Signing Key Rollovers > > ... > > Since only the key set is signed with a KSK, zone size considerations > do not apply. > > SK> However, the number of signatures in the keyset will increase. That > is, the response size for the DNSKEY rrset will be slightly larger. Good point. > ----------------------------- > > > 4.1.3. Difference Between ZSK and KSK Rollovers > > ... > > The drawbacks of this scheme are that, during the "new DS" phase, the > parent cannot verify the match between the DS_K_2 RR and DNSKEY_K_2 > using the DNS -- as DNSKEY_K_2 is not yet published. Besides, we > introduce a "security lame" key (see Section 4.3.3). Finally, the > child-parent interaction consists of two steps. The "Double > Signature" method only needs one interaction. > > > SK> Section 4.2.2 talks about the security lameness "condition" and > security lame "zones". What is a security lame "key"? Why is the > introduction of a DS record that has no matching KSK in the child zone > considered bad (as the above text suggests), given that we have another > valid DS->KSK link between the parent and child zones? > > ----------------------------- > > > 5.3.3. NSEC3 Salt > > ... > > However, unlike Zone Signing > Key changes, NSEC3 salt changes do not need special rollover > procedures. It is possible to change the salt each time the zone is > updated. > > SK> There was a recent suggestion that NSEC3 salt changes also had > certain timing dependencies because of the need to keep the NSEC3PARAM > record consistent during this process. Is that a valid concern, and one that > must be reflected in this document? Given the lack of discussion, NSEC3 salt should be considered outside this document. --Paul Hoffman _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
