Hi,
Here is my review. There are some small comments and some larger
comments, but I decided to report them in order of appearance.
* Section 1.1. Key Rolling Considerations.
- Bullet point 2 takes into account DNSSEC boot-strapping. The document
is mainly about key timings in a rollover event. Section 3.3.5 talks a
bit about introducing a first key. I am questioning that the topic on
enabling DNSSEC is so small in this document that it may be better to
remove this bullet point and section 3.3.5.
- A style remark. In bullet point 4: I would remove the brackets around
the last sentence.
- Another style remark. The last sentence talks about key-signing keys
and zone signing keys. Inconsistency with the "-".
* Section 1.2. Types of Keys
- In the last sentence of paragraph 2, make clear that also the RRSIG of
the DNSKEY RRset is important:
In the case of the KSK, the information is the self-signed DNSKEY
and the DS RRset... ^^^^^^^^^^^
* Section 2.1. ZSK Rollovers
- Bullet point 2, second paragraph. "Once the signing process is
complete and enough time has elapsed to allow all old information to
expire from caches, ...". It is actually more about the new information
to propagate to caches, so I would suggest to replace it with:
Once the signing process is complete and enough time has elapsed to
allow all new information to propagate to caches, ...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- The final paragraph, which summarizes the three ZSK rollover
methods, can it be removed? The section itself is already a summary of
the possible ZSK rollovers, I don't see any value in this final paragraph.
* Section 2.2. KSK Rollovers
- Nit: Paragraph 4 starts with "Like the ZSK case, ..." which to me
seems to insinuate that the number of KSK rollover methods is related to
the number of ZSK rollover methods. I would like to see it removed.
- Bullet point 1 says that the ZSK Double Signature rollover is also
known as Double-DNSKEY. I have not heard of this term before reading
this document. Is it really known as? If not, please remove it to avoid
unnecessary confusion. Also, again: don't say waiting for old
information to expire, but waiting for new information to propagate.
* Section 2.3. Summary
- KSK Double-Signature has the description "Publish the DNSKEY and
RRSIGs at the same time." But actually that is true for all KSK
rollovers. In fact, I think this table doesn't have much value and I
argue that it can be removed.
* Section 3.1. Key States
- Repeating myself: These key states are not sufficient to describe the
rollover time lines. See the comments below on the rollover time lines.
* Section 3.2.1. (ZSK) Pre-Publication Method
- Style inconsistency: The first line uses capitals for "Pre-Publication
rollover", while in other sections the rollover names are completely
lowercased.
- A general note on the Events 1: It explains every time why there are
different times for key generation and publication. This can be done
only once with a note that this is also true for the other Events 1.
- Event 8 talks about "an expired DNSKEY RRset in the cache". Seems a
contradiction to me.
* Section 3.2.2. (ZSK) Double-Signature Method
- Event 3: The current key is said to be retired. However, the key state
definition of "retired" is:
A successor key has become active and this key is no longer being
used to generated RRSIGS.
But in this rollover, it is required to have the current key generate
signatures, otherwise there are no double signatures and the
Double-Signature rollover can make the zone go bogus. In short, the key
state in this event does not match the key state description.
* Section 3.2.3. (ZSK) Double-RRSIG Method
- The first line mentions double-signature rollover, should be
double-RRSIG.
- Event 5: "The key is now said to be active". Actually, according to
the key state description, the key was already active earlier:
The key has started to be used to sign RRsets.
With ZSK Double-RRSIG, the key has started to be used to sign RRsets in
Event 2.
* Section 3.3.1. (KSK) Double-Signature Method
- Event 5: The time that the key becomes active, but the key state
description of "active" only takes about creating signatures, not about
the so-called security chain.
- Event 9: Also the key state description of "retired" doesn't mention
the security chain, but is only aligned for ZSK rollovers.
These two comments are also for the other KSK time lines.
* Section 5. Algorithm Considerations
- Paragraph 1: "... using a single algorithm." -> "using the same
cryptographic algorithm".
* Section 7. Summary
- The second paragraph says that the Double-RRset rollover is the most
efficient method for KSKs. While this is true if you look at the
duration of the rollover, this is not true for the number of parent
interactions. In fact, in the following line, the document says that the
time take to roll KSKs depends on factors related to the (signed)
parent. So if the parent interaction is a slow process, the KSK
Double-Signature rollover might even be faster than the Double-RRset
method, since it only requires one parent interaction.
That's all:)
Best regards,
Matthijs
On 08/23/2012 11:49 PM, Peter Koch wrote:
Dear DNSOP WG,
this is to initiate a working group last call (WGLC) for
"DNSSEC Key Timing Considerations"
draft-ietf-dnsop-dnssec-key-timing-03.txt
<http://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing/>
The WGLC will last until Friday, 14 September 2012
owed to return-to-desk season and the length of the draft.
The intent is to request publication of the document as an Informational RFC.
Please review the draft and send comments to this list (pls keep the full file
name of the draft in the "Subject:"). A little guidance for what to look at:
o appropriateness for the target audience
o technical correctness and internal consistency
o consistency with and/or relation to RFC 4641 and its designated
successor <http://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc4641bis/>
In line with our custom the draft will only progress if it receives
five or more significant(*) reviews and the (rough) consensus is in favour.
(*) Please review thoroughly. While "yeah, ship it" might be perceived better
than silence, it is not always helpful to determine consensus. In this
particular
case, I might take it as an indicator that the draft has received a cursory
read.
That is not to express an opinion on the quality of the draft, just a hint
that there should be one bite for everybody. (For completeness sake, the remark
applies to "nay" contributions respectively.)
Finally I would like to confirm that I saw Paul and Matthijs reinforce their
concerns raised in Vancouver in response to my mail earlier this week.
Looking at <http://tools.ietf.org/wg/dnsop/minutes?item=minutes-84-dnsop.html>
the minutes I follow the mandate to issue the WGLC. Looking forward to your
contributions.
Best regards,
Peter (as co-chair and doc shepherd)
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
