Re: I-D Action: draft-ietf-dnsop-rfc4641bis-11.txt
Matthijs Mekking <matthijs <at> nlnetlabs.nl>
2012-05-21 09:43:58 GMT
Hi Suresh,
Thanks for your review. I have commented on your feedback in between
lines.
However, I am not planning on any action now. I have lost confidence
in that this document will ever move forward. The WGLC for this
document was June 2011, should this really take so long?
So I like to see some action that gives me some confidence that I am
not working on an abide document.
Best regards,
Matthijs
On 05/18/2012 08:30 PM, 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 paragraph (3.2.1) is to summarize the two camps in the discussion
whether to roll a key because of operational concerns or to roll a key
because of cryptographically concerns. The second bullet point already
is somewhat a compromise between the two, taking into account that (new)
operators are prepared for unscheduled key rollovers. The third bullet
point also covers changing policies and procedures ("when a new
algorithm or key storage is required").
I am not in favor of adding the fourth bullet point. The first two
bullet points already cover the methods to prepare (new) operators to
conduct key rollovers, unscheduled or scheduled. The third bullet point
covers changes in policies and procedures, but maybe we could change its
text to:
o It should only be done when it is known or strongly suspected that
the key can be or has been compromised, or in conjunction with
operator change policies and procedures, like when a new
algorithm or key storage is required.
> -----------------------------
>
> 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.
>
In the second paragraph of this section, the document states that "it is
expected that the zone administrators are aware of such circumstances."
Such circumstances being the zone's keys are used as trust anchor.
So I think the current text is okay. We could clarify it by replacing
likely with expected:
vvvvvvvv
It is therefore preferred to roll KSKs that are expected 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.
>
> -----------------------------
>
>
> 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.
While I agree with the paragraph, I don't think it is appropriate to
include into 4641bis. First, the document is targeted at the zone
administrators, not resolver operators. In other words, I think it
should not make considerations regarding validators.
Second, the text about signing tools is not that different from the text
in -11. Only your text makes a recommendation for signing tools
developers, while the text in -11 warns about the assumptions signing
tools make with respect to the SEP bit. I think, given the targeted
audience of the document, the latter is more appropriate.
> -----------------------------
>
>
> 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.
>
I think we say the same here, but to be honest: I think your text is
more precise (although it neglects the rooted motivation for the
different effectivity periods between ZSK and KSK, I don't think that is
an issue).
> -----------------------------
>
>
> 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.
True.
> -----------------------------
>
>
> 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?
I assume you mean Section 4.3.3. A key is security lame, if the
corresponding DS is published, but its DNSKEY record not. Security
lameness is not necessarily bad, only if all keys are security lame (as
said in the text and as you also suggest). It happens if you conduct a
Double-DS rollover. However, you do not benefit from security lameness,
and validators have more options to try to build the chain of trust and
if they try the lame keys first, the do more work.
>
> -----------------------------
>
>
> 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?
I don't understand 'this process'. What process? The way I see it, they
are tight to the serial. Each version of a zone needs to have a complete
chain of NSEC3s and corresponding NSEC3PARAM. So they are consistent
with the serial. So you could change it every zone change and
secondaries are able to construct valid NSEC3 responses, regardless if
they are in sync with the master or not.
>
>
>
> Thanks! Suresh
>
>
>
> _______________________________________________ DNSOP mailing list
> DNSOP <at> ietf.org https://www.ietf.org/mailman/listinfo/dnsop
I
note that the listed affiliations are Kirei AB, .SE and ICANN.
Quoting Section 1.1:
"Even though this document is heavily inspired by the Internet X.509
Public Key Infrastructure Certificate Policy and Certification
Practices Framework [RFC3647], with large parts being drawn from that
document"
I don't see any mention of that in the Acknowledgements Section of the draft.
There is a pre5378 license clause which was used in an update of a
RFC which predates RFC 3647. This draft is a different and unusual
case. BTW, it is easier to let the previous versions of the draft to expire.
Regards,
-sm
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
RSS Feed