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.
-----------------------------
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.
-----------------------------
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.
-----------------------------
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.
-----------------------------
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?
Thanks!
Suresh
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
