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: a...@tr-sys.de |
+------------------------+--------------------------------------------+
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
