Subject: [DNSOP] A new review of draft-ietf-dnsop-rfc4641bis-10 -- part (B)

From: Alfred Hönes <[email-masked]>
Date: Thu, 5 Apr 2012 00:48:19 +0200 (MESZ)

As indicated in the previous message, I have revisited the
"DNSSEC Operational Practices, Version 2" I-D and performed
a full review from scratch for the most recent draft version,
draft-ietf-dnsop-rfc4641bis-10.

For convenience, and to accommodate message size limitations,
I have split my review comments into 3 parts:

  (A)  Technical flaws,
  (B)  Editorial flaws, and
  (C)  Editorial nits

Only the first two parts are being sent to the dnsop list,
the bulky third part is given as fodder to the authors only.

Here we go with part (B); if deemed necessary, please consider
to provide feedback for the items below on the list.

(B)  Editorial flaws
++++++++++++++++++++

(B.1) general -- terminology

The draft should make more consistent use of signature timing terms.

(B.1.1)  "signature validity period" et al.

The draft mostly uses "signature validity period" (or shortly
"validity period" [of a signature]) to indicate the (non-recurring)
time interval defined by the Signature Inception and
Signature Expiration fields in the RRSIG RDATA, but it also
uses "signature validity interval" in several instances, and it
uses the partially capitalized forms "Signature Validity period"
and "Signature Validity interval" in Section 4.4.2.2 and
"Validity Period" in Figure 10.
With two big caveats (see below), I recommend to harmonize on the
term "signature validity period", as introduced in Section 2,
"Time Definitions", and to always use the lowercase version.

Further, the title of Section 4.4.2, "Signature Validation Period",
is not used anywhere else and should be altered to
"Signature Validity Period".

* Caveat #1: From a mathematical/metrological perspective, the term
  "signature validity *period*" is a bad misnomer since it is used
  to indicate a single (non-recurring), closed (inclusive), time
  *interval*,  [ Signature_Inception, Signature_Expiration ] .

  Ironically, the primary definition in Section 3 (2nd para) of
  RFC 4034 uses the proper term, "signature validity interval",
  but Section 3.1.5 of RFC 4034 says "signature validity period",
  as does RFC 4033 in Section 2, 6, 8, and 8.1.  To add even more
  inconsistency into the terminology used, Section 2 of RFC 4033
  also uses one instance of "validity lifetime".

  So it looks like we are stuck with the improper term "validity
  period" for consistence and uniformity with RFCs 4033/4034.

* Caveat #2: Other timing parameters are (mostly) spelled in
  headline case throughout the memo.

Hint for the document editor:
  The instances of "[signature] validity interval" I found are in:
  - Section 4.2.1.1, bullet 5.
  - Section 4.3.4, 2nd paragraph (2x)
  - Section 4.4.1, last paragraph
  - Section 4.4.2.2, 4th paragraph (use lowercase, as noted above!)
  - Section 4.4.2.3, 3rd paragraph (2x)

In Section 4.3.5.2, 1st paragraph, for uniformity "signature validity"
should be amended to say "signature validity period" as well.

(B.1.2) "Re-Sign Period" and "Refresh Period" et al.

  The draft mostly uses these terms in headline case, but also a few
  instances of mixed case, and a single instance of an unnecessary
  variation, "refresh interval" appear in the draft.
  The draft should better uniformly use the headline case spelling
  for the defined terms.  (See the editing hints below.)

  These terms are defined in Appendix A, "Terminology";
  however, there the variant "Re-Signing frequency" is used as a key
  word and "Re-Signing Period" is used in the definition, both of
  which do no occur anywhere else in the draft.

  Therefore, I suggest to alter that definition in Appendix B
  to properly introduce the term used throughout the draft:

OLD:

   Re-Signing frequency:  Frequency with which a signing pass on the
      zone is performed.  Alternatively expressed as "Re-Signing
      Period".  It defines when the zone is exposed to the signer.
      During a signing pass, not all signatures in the zone may be
      regenerated: that depends on the refresh period.

NEW (with change tags):

|  Re-Sign Period:  This refers to the (reciprocal of the) frequency
          ^^^^^^^   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|     with which a signing pass on the zone is performed.  The Re-Sign
                                                           ^^^^^^^^^^^
|     Period defines when the zone is exposed to the signer.  During a
           ^^^
      signing pass, not all signatures in the zone may be regenerated:
|     that depends on the Refresh Period.
                          ^       ^

Hints to the document editor:
  - Section 4.4.1, 2nd bullet, 2nd para:
    s/refresh interval/Refresh Period/
  - Section 4.4.1, 2nd bullet, 3rd para:
    s/Refresh period/Refresh Period/
  - Section 4.4.1, last bullet, 5th para:
    s/Refresh period/Refresh Period/

(B.2)  Section 1 -- outdated text

The 2nd paragraph of Section 1 says:

   During workshops and early operational deployment, operators and
   system administrators have gained experience about operating the DNS
   with security extensions (DNSSEC).  This document translates these
   experiences into a set of practices for zone administrators.  At the
|  time of writing -the root has just been signed and the first secure
|  delegations are provisioned- there exists relatively little
   experience with DNSSEC in production environments below the top-level
   domain (TLD) level; this document should therefore explicitly not be
   seen as representing 'Best Current Practices'.  Instead, ...

The tagged phrase seems to be outdated now and should be updated
to reflect te successful deployment of DNSSEC in the Root zone and
many TLDs.  As of today, the ICANN TLD DNSSEC Report (2012-04-03)
( <http://stats.research.icann.org/dns/tld_report/> ) says:

| Summary
|
| * 313 TLDs in the root zone in total
| * 91 TLDs are signed;
| * 85 TLDs have trust anchors published as DS records in the root zone;
| * 4 TLDs have trust anchors published in the ISC DLV Repository.

So I suggest to modify the dangling sentence in the above quote to say:

   During workshops and early operational deployment, operators and
   system administrators have gained experience about operating the DNS
   with security extensions (DNSSEC).  This document translates these
|  experiences into a set of practices for zone administrators.  Although
|  the DNS Root has been signed since July 15, 2010 and now more than 80
|  secure delegations are provisioned in the root, at the time of writing
   there still exists relatively little experience with DNSSEC in
   production environments below the top-level domain (TLD) level; this
   document should therefore explicitly not be seen as representing
   'Best Current Practices'.  Instead, ...

(B.3)  Section 1.2 -- clarification

With respect to item (B.1) above, I suggest to even better clarify the
definition of "Signature validity period" in Section 1.2 (1st bullet):

OLD:
|  o  "Signature validity period" The period that a signature is valid.
|     It starts at the time specified in the signature inception field
|     of the RRSIG RR and ends at the time specified in the expiration
|     field of the RRSIG RR.

NEW:
|  o  "Signature validity period" The time interval during which a
|     signature is valid.  It starts at the (absolute) time specified in
|     the signature inception field of the RRSIG RR and ends at the
|     (absolute) time specified in the expiration field of the RRSIG RR.

(Regarding the list style here, I'll supply an editorial nit.)

(B.4)  Section 3.1, 7th para -- language improvement / clarification

I suggest to improve the language in the first part of the last
sentence in the 7th paragraph of Section 3.1:

          [...].  Since for all practical purposes X will somewhere of
   the order of 10 to 100, the associated key sizes will vary only about
   a byte in size for symmetric keys.  When translated to asymmetric
|  keys, is still too insignificant a size difference to warrant a key-
   split; it only marginally affects the packet size and signing speed.
---
          [...].  Since for all practical purposes X will somewhere of
   the order of 10 to 100, the associated key sizes will vary only about
   a byte in size for symmetric keys.  When translated to asymmetric
|  keys, the size difference is still too insignificant to warrant a key
   split; it only marginally affects the packet size and signing speed.

(B.5)  Section 4.1.1.1 -- clarifications

a)  The preamble to Figure 1 says:

|  Pre-Publish key rollover involves four stages as follows:

For clarity on first reading, I suggest to make this clause a bit
more precise, in mentioning the role of the ZSKs in the figure:

                           vvvvvvvvvvvvvvvvvvvvvvv
|  Pre-Publish key rollover from key 10 to key 11 involves four stages
|  as follows:

IMHO, there is no need to repeat a similar addition for subsequent
figures because a sequential reader of the memo will take note of
the elaborations below Figure 1 and not need to be made aware of
similar context in the other rollover figures.

(B.6)  Section 4.1.5, list items below Figure 5 -- clarifications

(a)
In the 1st list item below Figure 7, the draft says:

   initial:  Describes state of the zone before any transition is done.
|     The number of the keys may vary, but the algorithm of keys in the
|     zone is same for all DNSKEY records.

This is hard to parse and understand.
I suggest to change the wording to say:

   initial:  Describes state of the zone before any transition is done.
|     The number of the keys may vary, but all keys (in DNSKEY records)
|     for the zone use the same algorithm.

If this change is not accepted, at least  s/is same/is the same/ .

(b)
In the 2nd list item, the draft says:

   new RRSIGs:  The signatures made with the new key over all records in
      the zone are added, but the key itself is not.  This step is
      needed to propagate the signatures created with the new algorithm
      to the caches.  If this is not done, it is possible for a resolver
      to retrieve the new DNSKEY RRset (containing the new algorithm)
|     but to have a RRsets in cache with signatures created by the old
      DNSKEY RRset (i.e. without the new algorithm).

The tagged line should be clarified to say:

|     but to have RRsets in its cache with signatures created by the old

(c)
In subsequent list items, I suggest to clarify the text -- where
becessary -- by making the distinction between "old" and newer data
more explicit, and -- in two instances -- an indication of the
possibility of more than one DNSKEY RR (as in the Figure, due to the
split KSK/ZSK scheme used) should be indicated by talking about the
"DNSKEY RRset":

|  new DNSKEY:  After the cache data has expired, the new key can be
      added to the zone.
---                      vvvvv
|  new DNSKEY:  After the old cache data has expired, the new key can be
      added to the zone.

|  new DS:  After the cache data for the DNSKEY has expired, the DS
      record for the new key can be added to the parent zone and the DS
      record for the old key can be removed in the same step.
---                                     vvvvv      vvvvvvv
|  new DS:  After the cache data for the old DNSKEY RRset has expired,
      the DS record for the new key can be added to the parent zone and
      the DS record for the old key can be removed in the same step.

|  DNSKEY removal:  After the cache data for the DS has expired, the old
|     algorithm can be removed.  This time the key needs to be removed
|     first, before removing the signatures.
---                                             vvvvv
|  DNSKEY removal:  After the cache data for the old DS has expired, the
|     old algorithm can be removed.  This time the old key needs to be
                                        vvvvv     ^^^^^
|     removed first, before removing the old signatures.

|  RRSIGs removal:  After the cache data for the DNSKEY has expired, the
|     signatures can also be removed during this step.
---                                             vvvvv      vvvvvvv
|  RRSIGs removal:  After the cache data for the old DNSKEY RRset has
|     expired, the old signatures can also be removed during this step.
                  ^^^^^

(B.7)  Section 4.1.5.3, 1st para -- wrong pointer

The draft text refers to Figure 12 where it should refer to Figure 13:

   Combining the Single Signing Type Scheme Algorithm Rollover and
|  RFC5011 style rollovers is not trivial, see Figure 12 in Appendix C.
---                                                   ^^
   Combining the Single Signing Type Scheme Algorithm Rollover and
|  RFC 5011 style rollovers is not trivial, see Figure 13 in Appendix C.
      ^                                                ^^

(Note that Figure 11 details the 'normal' Single Signing Type Scheme,
Figure 12 details the RFC 5011 style rollover with split KSK/ZSK, and
Figure 13 actually details the single key, RFC 5011 style variant.)

(B.8)  Section 4.2.1.x -- disambiguation/clarification in title & text

The superordinate section titles only set context insufficiently and
so the section titles and leading text of both Sections 4.1.2.1 and
4.2.1.2 might cause misunderstanding of what the intended advice is
(even indicating malicious intent!).  I suggest to add precision to
both in expanding on the key rollover scenario described there.

(a)  Section 4.2.1.1

OLD:

|4.2.1.1.  Keeping the Chain of Trust Intact
|
|  If we follow this advice, the timing of the replacement of the KSK is
|  somewhat critical.  The goal is ...

NEW:

|4.2.1.1.  Emergency Key Rollover Keeping the Chain of Trust Intact
|
|  If we follow this advice to perform emergency key rollover in a
|  manner that keeps the chain of trust intact, the timing of the
   replacement of the KSK is somewhat critical.  The goal is ...

(b)  Section 4.2.1.2

OLD:

|4.2.1.2.  Breaking the Chain of Trust
|
|  There are two methods to break the chain of trust.  The first method
   causes the child zone to appear 'Bogus' to validating resolvers.  The
   other causes the child zone to appear 'insecure'.  These are
   described below.

NEW:

|4.2.1.2.  Emergency Key Rollover Breaking the Chain of Trust
|
|  There are two methods to perform an emergency key rollover in a
|  manner that breaks the chain of trust.  The first method causes the
   child zone to appear 'Bogus' to validating resolvers.  The other
   causes the child zone to appear 'insecure'.  These are described
   below.

(B.9)  Section 4.2.3 -- IETF terminology

In the last line of the second paragraph of Section 4.2.3,
the draft should prefer to say  "Transport Layer Security (TLS)"
in favor of  "secure sockets (TLS)" .

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 11 Apr 2012 15:48:26 +0200

> to provide feedback for the items below on the list.

Again, all items that are adopted without feedback necessary have been
omitted from this reply.

> (B)  Editorial flaws

Adopted your suggestions.

>    'Best Current Practices'.  Instead, ...

Yes, that's what you get when a document is laying around for so long.
It used to be "the root is being signed" ;). But I have adopted your change.

> |     (absolute) time specified in the expiration field of the RRSIG RR.

I don't see why this should be changed. Do you prefer interval over
period? Do you want the clarify that the times are absolute? This is a
non-issue in my opinion.

> similar context in the other rollover figures.

Or

  Pre-Publish key rollover from DNSKEY_Z_10 to DNSKEY_Z_11 involves...

> |  new DNSKEY:  After the old cache data has expired, the new key can be

What is an old cache? I suggest "After the old data has expired from
cache" here.

> |  DNSKEY removal:  After the cache data for the old DS has expired, the

"old DS RRset"

> |     removed first, before removing the old signatures.

Best regards,
  Matthijs

---

From: Alfred Hönes <[email-masked]>
Date: Wed, 11 Apr 2012 22:08:34 +0200 (MESZ)

Matthijs,
again thanks for your quick and detailed response and action.

A few selected follow-up remark can be found inline below.

On 11 Apr 2012 15:48:26 +0200, Matthijs Mekking wrote:
> On 04/05/2012 12:48 AM, Alfred Hönes wrote:
> Again, all items that are adopted without feedback necessary have
> been omitted from this reply.

And I additionally dropped those items where I'm satisfied with your
response and do not see the need to add more thoughts.

>> ...

Well, the issue is that RFCs 4033 and 4034, after initially using
the precise term, "signature validity interval", have switched
to use the misnomer "signature validity period", and we are stuck
with that unfortunate usage for consistency with RFCs 4033/4034.

"Period" is used in "Re-Sign Period" "Refresh Period" in this draft
in the proper sense of a period - a recurring, floating interval
that relates to the reciprocal value, a frequency.

Therefore I still believe that it is worth emphasizing here, early
in the document, that "period" in "signature validity period" is
different, actually being a fixed time interval that, once passed,
will not recur.  The suggested two additions of parenthetical
"absolute" [time] seem to be a suitable way to do that with a very
small textual footprint.

>> ...

The proposed text did say "old cache data", not "old cache".   :-)
But the wording you suggest is fine as well; I just tried to a change
with a smaller footprint.

>> |  DNSKEY removal:  After the cache data for the old DS has expired, the

Agreed.

>> ...

Best regards,
  Alfred.

---

From: Dick Franks <[email-masked]>
Date: Wed, 11 Apr 2012 23:53:11 +0100

On 11 April 2012 14:48, Matthijs Mekking <[email-masked]> wrote:

> The word 'period' means the (constant) interval between events in a
sequence; for example, the orbital period of a satellite.

The time elapsed between aperiodic events occurring at times t1 and t2 is
best described as an interval of duration (t2-t1).

Absolute time was deprecated in 1905.

--Dick

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 12 Apr 2012 10:19:13 +0200

Alfred,

I have no further comments on part (A). I have also adopted the
leftovers in part (B), with explanation in between lines.

Best regards,
  Matthijs

On 04/11/2012 10:08 PM, Alfred � wrote:
> Matthijs, again thanks for your quick and detailed response and
> action.
> 
>> On 04/05/2012 12:48 AM, Alfred H�nes wrote:
>> Again, all items that are adopted without feedback necessary
>> have been omitted from this reply.
> 
> And I additionally dropped those items where I'm satisfied with
> your response and do not see the need to add more thoughts.
> 
> 
>>> (B)  Editorial flaws ++++++++++++++++++++
>>> 
>>> ...
>>> 
>>> With respect to item (B.1) above, I suggest to even better
>>> clarify the definition of "Signature validity period" in
>>> Section 1.2 (1st bullet):
>>> 
>>> OLD: |  o  "Signature validity period" The period that a
>>> signature is valid. |     It starts at the time specified in
>>> the signature inception field |     of the RRSIG RR and ends at
>>> the time specified in the expiration |     field of the RRSIG
>>> RR.
>>> 
>>> NEW: |  o  "Signature validity period" The time interval during
>>> which a |     signature is valid.  It starts at the (absolute)
>>> time specified in |     the signature inception field of the
>>> RRSIG RR and ends at the |     (absolute) time specified in the
>>> expiration field of the RRSIG RR.
>> 
>> I don't see why this should be changed. Do you prefer interval
>> over period? Do you want the clarify that the times are absolute?
>> This is a non-issue in my opinion.
> 
> the precise term, "signature validity interval", have switched to
> use the misnomer "signature validity period", and we are stuck with
> that unfortunate usage for consistency with RFCs 4033/4034.
> 
> "Period" is used in "Re-Sign Period" "Refresh Period" in this
> draft in the proper sense of a period - a recurring, floating
> interval that relates to the reciprocal value, a frequency.
> 

Ok, with that explanation I at least understand why you suggested this
change. Adopted.

>>> (c) In subsequent list items, I suggest to clarify the text --
>>> where becessary -- by making the distinction between "old" and
>>> newer data more explicit, and -- in two instances -- an
>>> indication of the possibility of more than one DNSKEY RR (as in
>>> the Figure, due to the split KSK/ZSK scheme used) should be
>>> indicated by talking about the "DNSKEY RRset":
>>> 
>>> |  new DNSKEY:  After the cache data has expired, the new key
>>> can be added to the zone. ---                      vvvvv |  new
>>> DNSKEY:  After the old cache data has expired, the new key can
>>> be added to the zone.
>> 
>> What is an old cache? I suggest "After the old data has expired
>> from cache" here.
> 
> But the wording you suggest is fine as well; I just tried to a
> change with a smaller footprint.

But it was ambiguous (at least to me), so I suggested the other wording.