Subject: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-key-timing-05.txt

From: [email-masked]
Date: Wed, 17 Sep 2014 05:18:58 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Domain Name System Operations Working Group of the IETF.

        Title           : DNSSEC Key Rollover Timing Considerations
        Authors         : Stephen Morris
                          Johan Ihren
                          John Dickinson
                          W. (Matthijs) Mekking
	Filename        : draft-ietf-dnsop-dnssec-key-timing-05.txt
	Pages           : 31
	Date            : 2014-09-17

Abstract:
   This document describes the issues surrounding the timing of events
   in the rolling of a key in a DNSSEC-secured zone.  It presents
   timelines for the key rollover and explicitly identifies the
   relationships between the various parameters affecting the process.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-key-timing-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-key-timing-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 18 Sep 2014 14:51:58 -0400

All

This document has been in WGLC and the working group has done an 
iteration on the document.  The authors merged in several sets of 
changes, first back in July, and recently from the feedback from the 
working group reviewers and editors.    The opinion is that this version 
reflects all suggestions and is ready to move forward again.

Since the editorial changes are more than we originally expected, we're 
going to open up a Working Group Last Call on this document for another 
2 weeks. We urge folks to read over the differences in the documents.

This last call will end on October 2nd, 2014.

thanks
tim

-------- Original Message --------
Subject: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-key-timing-05.txt
Date: Wed, 17 Sep 2014 05:18:58 -0700
From: [email-masked]
To: [email-masked]
CC: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
  This draft is a work item of the Domain Name System Operations Working 
Group of the IETF.

Abstract:

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 22 Sep 2014 20:06:06 -0700

On Sep 18, 2014, at 11:51 AM, Tim Wicinski <[email-masked]> wrote:

> This document has been in WGLC and the working group has done an iteration on the document.  The authors merged in several sets of changes, first back in July, and recently from the feedback from the working group reviewers and editors.    The opinion is that this version reflects all suggestions and is ready to move forward again.
> 
> Since the editorial changes are more than we originally expected, we're going to open up a Working Group Last Call on this document for another 2 weeks. We urge folks to read over the differences in the documents.
> 

I did a clean read, and it feels *much* better than the early drafts. I have a small number of editorial comments, but some bigger questions as well. I strongly suspect the questions can be answered by small additions to the draft.

At the beginning of 2.1:
   For ZSKs, the issue for the zone operator/signer is to ensure that
   any caching validator has access to a particular signature that
   corresponds to a valid ZSK.
"that corresponds to" seem wrong here. The following may be more accurate (or it might be wrong...):
   For ZSKs, the issue for the zone operator/signer is to ensure that
   any caching validator has access to a particular signature has
   access to the corresponding valid ZSK.

In 2.2, it says "It is important to note that this does not preclude the development of key rollover logic"; I can't figure out what "this" refers to. There are a bunch of things in the two preceding paragraphs that it might mean.

The introduction to 3.1 caught me, and I can't figure out whether or not it is right.
   A DNSSEC key contributes two pieces of information to the validation
   process: the DNSKEY itself and the data created from it.  In the case
   of the validation of an RR, the data created from the DNSKEY is the
   RRSIG.  Where there is a need to validate a chain or trust, the data
   created from the DNSKEY is the DS.  In this section, the term
   "associated data" refers to the RRSIGs created from a DNSKEY when
   discussing a ZSK, or to the DNSKEY's corresponding DS record when
   referring to a KSK.
Is the "associated data" for a KSK really just the DS? Shouldn't any RRSIG over the ZSK that was created by the DSKEY also be "associated data"?

Also in 3.1:
   Ready       The DNSKEY or its associated data have been published for
               long enough to guarantee that any previous versions of
               the DNSKEY and/or associated data have expired from
               caches.
This is discussing a new key. What is the "previous version"?

Section 3.3.5 is really important to some readers, but it could easily be lost. There should be a sentence near the end of 1.1 that says "Note that introduction of first keys is different than rolling a key; see Section 3.3.5 for more information about that topic."

Section 6 really should be Section 1.4. The paragraphs will make it much easier for someone reading the document who exclaims (to no one in particular) "they didn't consider X" as they are reading the meat of the document to understand that the authors probably did think about it, but chose to not include it.

--Paul Hoffman

---

From: "Niall O'Reilly" <[email-masked]>
Date: Tue, 23 Sep 2014 16:42:27 +0100

At Mon, 22 Sep 2014 20:06:06 -0700,
>    access to the corresponding valid ZSK.

  I can't parse the last sentence above and would appreciate
  clarification.

  The noun clause which is apparently intended as the object of the
  infinitive "to ensure" contains two finite verbs.  Perhaps a
  sub-ordinating conjunction has been omitted?

  Best regards,
  Niall O'Reilly

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 Sep 2014 08:51:26 -0700

>  sub-ordinating conjunction has been omitted?

Does the following help?

  For ZSKs, the issue for the zone operator/signer is to ensure that
  any caching validator has access to a particular signature also has
  access to the corresponding valid ZSK.

Or:

  For ZSKs, the issue for the zone operator/signer is to ensure that
  if a caching validator has access to a particular signature,
  the validator also has access to the corresponding valid ZSK.

--Paul Hoffman

---

From: "Niall O'Reilly" <[email-masked]>
Date: Tue, 23 Sep 2014 16:59:24 +0100

At Tue, 23 Sep 2014 08:51:26 -0700,
>   access to the corresponding valid ZSK.

  After reading the alternative below, I think this needs
  s/validator has/validator which has/

>   the validator also has access to the corresponding valid ZSK.

  Perfectly clear; thanks.

  Best regards,
  Niall O'Reilly

---

From: Stephen Morris <[email-masked]>
Date: Thu, 25 Sep 2014 13:38:40 +0100

Paul

Thanks for taking the time to go through the draft.  Addressing your
comments:

On 23/09/14 04:06, Paul Hoffman wrote:
> At the beginning of 2.1: For ZSKs, the issue for the zone 
> operator/signer is to ensure that any caching validator has access 
> to a particular signature that corresponds to a valid ZSK. "that 
> corresponds to" seem wrong here. The following may be more
> accurate (or it might be wrong...): For ZSKs, the issue for the
> zone operator/signer is to ensure that any caching validator has
> access to a particular signature has access to the corresponding
> valid ZSK.

The text resulting from the emails from you and Niall O'Reilly:

"For ZSKs, the issue for the zone operator/signer is to ensure that
any caching validator which has access to a particular signature also
has access to the corresponding valid ZSK."

...seems OK.  We'll update that paragraph.

> In 2.2, it says "It is important to note that this does not 
> preclude the development of key rollover logic"; I can't figure
> out what "this" refers to. There are a bunch of things in the two 
> preceding paragraphs that it might mean.

How about:

"It is important to note that the need to interact with the parent
does not preclude the development of key rollover logic;"

> The introduction to 3.1 caught me, and I can't figure out whether 
> or not it is right. A DNSSEC key contributes two pieces of 
> information to the validation process: the DNSKEY itself and the 
> data created from it.  In the case of the validation of an RR, the 
> data created from the DNSKEY is the RRSIG.  Where there is a need 
> to validate a chain or trust, the data created from the DNSKEY is 
> the DS.  In this section, the term "associated data" refers to the 
> RRSIGs created from a DNSKEY when discussing a ZSK, or to the 
> DNSKEY's corresponding DS record when referring to a KSK. Is the 
> "associated data" for a KSK really just the DS? Shouldn't any
> RRSIG over the ZSK that was created by the DSKEY also be
> "associated data"?

I'm not clear what you mean by "any RRSIG over the ZSK that was
created by the DSKEY". Do you mean the RRSIG over the DNSKEY RRset
created by the KSK in question? If so, I take the point that the KSK's
associated data can be regarded as both a DS record and the RRSIG over
the DNSKEY RRset and so as written, it is not completely clear.

I think there are two things relevant for this paragraph:

* The draft doesn't concern itself with the validation of the DNSKEY
RRset (i.e. that it is signed by a valid KSK).  So when talking about
the ZSK, it is taken as read the ZSK has been validated by a KSK.  In
the case of a KSK, the assumption is that the KSK comes from a DNSKEY
RRset signed by itself, and so the draft only concerns itself with the
validation of the KSK against the DS.

* In virtually all cases, the KSK and the DNSKEY signature created by
it are added to and removed from the zone together.  They also travel
together - you always get the RRSIG when you retrieve the DNSKEY. The
term "associated data" is really trying to capture the idea that in
some cases the pieces of data required for a validation are obtained
separately, perhaps at different times.

I'm not sure whether the above two points need to be clearly spelt out
in the draft or whether they are clear from the context of the
discussion. If the latter, modifying the paragraph to:

"A DNSSEC key requires two pieces of information to perform
validation: the DNSKEY itself and associated data created from it.  In
the case of the validation of an RR, the data associated with the ZSK
is the RRSIG.  Where there is a need to validate a chain or trust, the
associated data is the DS."

... may address your point.  If not, an additional subsection in
section 3 will be required to make the points listed above.

> Also in 3.1: Ready       The DNSKEY or its associated data have 
> been published for long enough to guarantee that any previous 
> versions of the DNSKEY and/or associated data have expired from 
> caches. This is discussing a new key. What is the "previous 
> version"?

How about rewording it as:

"The DNSKEY or its associated data have been published for long enough
to guarantee that copies of the key(s) it is replacing (or associated
data related to that key) have expired from caches."

> Section 3.3.5 is really important to some readers, but it could 
> easily be lost. There should be a sentence near the end of 1.1
> that says "Note that introduction of first keys is different than 
> rolling a key; see Section 3.3.5 for more information about that 
> topic."

Accepted.

> Section 6 really should be Section 1.4. The paragraphs will make
> it much easier for someone reading the document who exclaims (to
> no one in particular) "they didn't consider X" as they are reading
> the meat of the document to understand that the authors probably
> did think about it, but chose to not include it.

Fair point - accepted.

Stephen

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 25 Sep 2014 10:05:02 -0700

> does not preclude the development of key rollover logic;"

Yes, great. (That was not my first expansion of "this", FWIW.)

> the DNSKEY RRset and so as written, it is not completely clear.

Yes, exactly that. "or to the DNSKEY's corresponding DS record when referring to a KSK" actually limits it to the DS record.

> discussion.

They were not clear to me.

> If the latter, modifying the paragraph to:
> 

The stuff above makes it clearer, but readers will will still need to do some logic in their heads with it. However, given that this is more of an operational document, you don't really need to lay everything out. The modification is probably fine on its own.

> data related to that key) have expired from caches."

Yep, fine.

Thanks!

--Paul Hoffman