Subject: Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timing-03.txt until 2012-09-14

From: Matthijs Mekking <[email-masked]>
Date: Thu, 06 Sep 2012 12:29:26 +0200

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

---

From: Tony Finch <[email-masked]>
Date: Thu, 6 Sep 2012 12:44:36 +0100

Matthijs Mekking <[email-masked]> wrote:

Most of your points look OK to me though I have not yet reviewed the

>     allow all new information to propagate to caches, ...

No, I think the original text is correct. You can't remove the old DNSKEY
until all the old RRsets (and RRSIGs) have expired, and you can't remove
the old RRSIGs until the old DNSKEY RRsets have expired. Whether the
caches have the new data is irrelevant since it's also OK for them to have
no data. And when caches are filled is not under the authority's control.

> this document. Is it really known as?

Double-KSK would be a better term, since Double-DNSKEY sounds like the
normal steady state with a KSK and ZSK.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Yuri Schaeffer <[email-masked]>
Date: Thu, 06 Sep 2012 14:02:14 +0200

> normal steady state with a KSK and ZSK.

I disagree. To me Double-KSK sounds like having two keys, both with DS
and DNSKEY records published.

//Yuri

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 07 Sep 2012 09:10:32 +0200

On 09/06/2012 01:44 PM, Tony Finch wrote:
> Most of your points look OK to me though I have not yet reviewed
> the document in detail. I have a disagreement and a suggestion:
> 
>> 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, ... 
> No, I think the original text is correct. You can't remove the old
> DNSKEY until all the old RRsets (and RRSIGs) have expired, and you
> can't remove the old RRSIGs until the old DNSKEY RRsets have
> expired. Whether the caches have the new data is irrelevant since
> it's also OK for them to have no data. And when caches are filled
> is not under the authority's control.

Good point. The reason why this text attracted my attention is that
with ZSK Double-Signature, the "old information" will not expire from
caches. The previous versions of the RRsets which contain *only* the
predecessor DNSKEY and predecessor signatures expire from the caches.
It will have either a replacement that contains *both* predecessor and
successor DNSKEY and signatures, or it will have no replacement.

So, "old information" is perhaps too loosely.

Best regards,
  Matthijs

> 
>> - 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?
> 
> Double-KSK would be a better term, since Double-DNSKEY sounds like
> the normal steady state with a KSK and ZSK.
> 
> Tony.
>

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 7 Sep 2012 15:32:10 -0400

Dear colleagues,

>         <http://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing/>

I have read draft-ietf-dnsop-dnssec-key-timing-03. I have some
comments. I'll send additional comments containing nits to the draft
editors.

On the whole, I think the draft is a little complicated for operators
to follow easily.  I nevertheless think we should publish it: we offer
today _no_ guidance to operators on these matters, and people I work
with, at least, want such guidance.  I know there's another draft
floating about, but if we take as long to reach agreement on that
draft as we took to review this one, we'll never publish anything.

In section 1.2, it would be helpful to observe that, as a matter of
deployment, the KSK might also be the ZSK.  I'm aware that the
document is assuming a sharp distinction, but by noting they could be
the same key and leaving the working out of the implications for the
reader, the document will be made more useful.

Section 1.4 includes the RFC 2119 language, but in some places I
notice "must" (in lower case) used. I find this a little hard to work
with, and I know that at least one AD is quite exercised about this
issue, so I think someone needs to go through the document and restate
such uses. I also find it mystifying why some but not all of the
definitions are moved to an appendix, although I don't really care
about this.

Section 3.1 has this definition:

   Published   The DNSKEY record - or information associated with it -
               is published in the zone, but predecessors of the key (or
               associated information) may be held in caches.

I think this isn't quite right, because the predecessors of the key
(i.e. other keys) might also be Published, no? It's predecessors of
the relevant RRsets that might still be in caches, I think, no?

In section 3.2.2, the text, "The successor is key is now active and
the current key is said to be retired," is a little strange (it's odd
that the "current key" is the retired one and the "successor key" is
active). I understand the text given the context, but I wonder whether
this would be better phrased in terms of Key N and Key N+1.

It took me a minute to understand Section 3.2.3, Event 4.  Perhaps it
could be clarified this way:

   There is now a delay while RRSIGs that were only generated using
   Key N expire from caches.  This interval is given by the expression:

             Dprp + TTLsig

    After that interval, all caches that have any RRSIG will have the
    RRSIGs generated by both Key N and Key N-1.

Or something like that?

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 10 Sep 2012 10:19:12 +0200

Hi Andrew,

> draft as we took to review this one, we'll never publish anything.

I agree the document can be complicated for operators, but the document
targets developers in the first place. But I must admit, also for
developers, it can be quite a challenge to fully grasp all the timings
and its explanations on the first read.

> reader, the document will be made more useful.

If we would add such a notion, I would also add that this document does
not cover time lines for rollovers where the key has both roles.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 10 Sep 2012 11:19:42 -0400

> the minutes I follow the mandate to issue the WGLC.  Looking forward to your

General comments:
The document in introduction indicates that its target audience is
"zone manager". I think the main audience are:
       DNS zone tool developers,
       zone operator/manager
       domain policy specifier.
Each one has its own "desires" from the document, the document does a 
decent job of offering guidance to all.
I would like to see a short addition to the introduction addressing
this.

The document has fair amount of repeated text and definitions and his
makes it harder to read the whole document but on the other hand it
makes it easy to read a single section w/o having to make many lookups
to more definitions. The way the document is written it makes it
easy to make to just go into the relevant section. Introduction
should mention that the goal of the document is allow easy
use of "single method" w/o having to read the whole document.

I'm not sure that I agree that the definitions used in the document are 
in appendix rather than in an early section.

Overall I like the document and support its publication.
Few minor nits below:

Section 2.2 and 2.3.
The document says that Pre-Publication is not applicable to KSK
rollover, this is wrong as new KSK can be added to the childs DNSKEY
RRset without signing the DNSKEY RRset, there is nothing in the
protocol specifcation that prevents this.
I agree using this methold results in a more complicated rollover
than any of the others as the signature by the new key needs to be
added before the DS is changed.
In effect the result is overly complicated
NEW DNSKEY --> NEW RRSIG --> NEW DS --> del Old DNSKEY --> del OLD DS
or
NEW DNSKEY --> NEW DS --> NEW RRSIG --> del old DS --> del OLD DNSKEY
NEW DNSKEY --> NEW DS --> NEW RRSIG --> del old DNSKEY --> del old DS

So for accuracy I think the document should say "overly complicated
with no addvantages thus not recommended"

Section 4
The description of Double-DS method is a little be short, and does
not explicitly point out the main advantage of the method, i.e.
no parental involvment is required to start using a the new key.

	Olafur

---

From: Tony Finch <[email-masked]>
Date: Mon, 10 Sep 2012 17:17:34 +0100

> protocol specifcation that prevents this.

There is an important difference, though. A pre-published ZSK is
immediately useful for signing without any further steps required (after
waiting for cache expiry). If you pre-publish a KSK you don't get usefully
closer to adding the new link in the chain of trust: you still have to go
through a complete iteration of one of the KSK rollover procedures
described in the draft, except instead of adding the new KSK+RRSIG you
only need to add the new RRSIG.

So I'm not sure what is the value of mentioning this possibility.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Wed, 19 Sep 2012 16:17:20 +0100

Sorry, late again, but I have read through the draft and I did not find
any errors. I found an earlier version very useful in getting to grips
with DNSSEC's timing constraints, so I'm keen to see it published. I
really like the formalism and careful presentation style.

I have a couple of observations:

The timelines cover the entire lifetime of a key. This means they
typically cover one and a half rollovers: the key is introduced (then
there's nothing about retiring the old key) then its successor is
introduced, then the key is retired. I find this a bit distracting and I
would prefer it if the timelines were oriented around a single rollover.

Secondly, there is a fairly simple set of rules underlying all rollovers,
which I don't think I have seen written down - the existing descriptions
explain the processes that result from these rules, but leave them
implicit.

For ZSKs, the rules are:

(1) You must remove the old ZSK after adding the new ZSK.

(2) You must remove the old RRSIGs after adding the new RRSIGs.

(3) You must wait for the new ZSK to propagate before removing the old RRSIGs.

(4) You must wait for the new RRSIGs to propagate before removing the old ZSK.

By "propagate" I'm including propagation to all authority servers and
expiration of previous versions of the records from all caches.

Each kind of rollover comes from adding an extra criterion:

Pre-Publication: minimise the time between adding the new RRSIGs and
deleting the old RRSIGs.

Double-Signature: minimise the overall time taken by the process, or
minimise the number of phases.

Double-RRSIG: minimise the time between adding the new ZSK and deleting
the old ZSK.

For KSKs, the rules are:

(5) You must remove the old DS after adding the new DS.

(6) You must remove the old KSK after adding the new KSK.

(7) You must wait for the new DS to propagate before removing the old KSK.

(8) You must wait for the new KSK to propagate before removing the old DS.

Each kind of rollover comes from adding an extra criterion:

Double-Signaure: minimise the time between adding the new DS and removing
the old one.

Double-DS: minimise the time between adding the new KSK and removing the
old one.

Double-RRset: minimise the overall time taken by the process, or
minimise the number of phases.

If you have a single key-type signing model, you need to take the union of
the rules (and rules 1 and 6 combine). The same applies when rolling both
keys at once, e.g. when changing operators. When you are changing
operators, changing the NS records effectively does the adding and
removing implied by the differences between the zones at the old and new
operators.

Tony.

---

From: Peter Koch <[email-masked]>
Date: Wed, 19 Sep 2012 17:20:50 +0200

> Sorry, late again, but I have read through the draft and I did not find

thanks, Tony, no worries about the delay.  I'm currently evaluating the
responses and will come back the week after next week.

-Peter (shepherding co-chair)