Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-11.txt

From: Suresh Krishnaswamy <[email-masked]>
Date: Fri, 18 May 2012 14:30:26 -0400

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

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 18 May 2012 11:59:21 -0700

>      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.

+1 to this idea.

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.

Good point.

Given the lack of discussion, NSEC3 salt should be considered outside this document.

--Paul Hoffman

---

From: Olaf Kolkman <[email-masked]>
Date: Mon, 21 May 2012 11:40:23 +0200

> Leaving aside the nits, here are some of my comments on -11.

Suresh,

<serious>
Thanks you for the comments, and Paul for the followup. 
</serious>

<sarcasm>
They are very timely since the DNSOP chairs are currently scheduling time to review the document after the last call for this document closed about a year ago.
</sarcasm>

<serious>
Chairs, would you like us to incorporate (some of, see comments from Paul H.) the suggestions in the document _now_ or after you have done your review?

Can you please make sure this document is at the IESG before June? 

</serious>

--Olaf

NLnet
Labs
Olaf M. Kolkman

www.NLnetLabs.nl
[email-masked]

Science Park 400, 1098 XH Amsterdam, The Netherlands

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 21 May 2012 11:43:58 +0200

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.
> 
> 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 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.

> 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.
> 
> 
> verify that the rollovers are being tracked by automated 
> mechanisms. Perhaps the guidance ought to be:
> 
> 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.

> 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.
> 
>  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.

> maintained on cryptographic Hardware Security Modules (HSM), then 
> the motivation to have different key effectivity periods is 
> weakened.
> 
> 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,
> 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).

> 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.

> 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.
> 
> 
> 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.

> 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.
> 
>  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
>  [email-masked] https://www.ietf.org/mailman/listinfo/dnsop

---

From: Olaf Kolkman <[email-masked]>
Date: Mon, 21 May 2012 11:40:23 +0200

Suresh,

<serious>

<sarcasm>

<serious>

</serious>

--Olaf

NLnet
Labs
Olaf M. Kolkman

www.NLnetLabs.nl
[email-masked]