Subject: [DNSOP] draft-ietf-dnsop-dnssec-key-timing-00

From: Johan Ihren <[email-masked]>
Date: Tue, 19 Oct 2010 10:26:27 +0200

All,

This document has been making the rounds for some 2.5 years now, initally as a personal submission by the authors, and later on as a WG document. The reason that it has taken so long is a combination of 

* the subject matter being quite complicated and several re-starts trying to find the best approach for description
* the need to track an evolving subject matter, interact with other documents like 4641-bis, etc
* the usual sundry time constraint issues for authors, editors and reviewers

The present state is that we have a document that's fairly "stable", has been reviewed several times with nits fixed in between. So it is almost ready to go, isn't it? Well, not necessarily... 

One of the problems with delays is that over time you gain a clearer understanding of what was once new. Another is that when that perfect 20/20 hindsight appears you realise that if you were to start over you would do it in a different way. And this is perhaps where we are now.

There are significant changes that are being discussed, including:

* a section on rollovers of the so-called CSK (Combined Signing Key) in addition to the treatment of KSK and ZSK rollovers.

* there is a lack of clarity in the current definition of key states that would benefit from further work. For instance, current logic assumes that a transition from one 
active key to the next is immediate, while for large zones it is becoming clear that signing with the new key may be a gradual phase-in that will take some time until all signatures are replaced. See the recent email from Matthijs Mekking.

* alternatively, a more fundamental change would be to completely change the terminology by switching away from a state description that is "key centric" (i.e. keys have states and the rollover progresses as a function of the keys changing states) to instead be "rollover centric" (i.e. the rollover has states, and keys change behaviour and tasks as a function of of the rollover changing states). However, it would allow for a consistent terminology across all types of rollovers.

* manage the complexity and problems finding reviewers by splitting the material into two documents, the first laying down terminology and defining states and transitions, the second having all the math, equations, and complete treatment of all consequences of all choices of rollover mechanisms. The first document would be of more general interest and the latter clearly more of relevance to implementers.

However, doing major surgery like this at this time would clearly delay publication significantly and we are therefore at a point in time where we have to ask the WG for guidance on how to best proceed.

We see the following three paths forward:

A. "Improvements should always be incorporated, even in the light of further 
 delays". This is also known as the "This Time For Sure"-alternative.

B. "Better to publish what we have and initiate work on a -bis document 
 immediately. Also known as the "Perfect is the Enemy of Timely"-alternative.

C. Drop it. If it isn't sufficiently cooked after getting on for three years, then perhaps it 
s/after three years/after getting on for three years/

 is either a case of bad ingredients, or incompetent chefs. Also known as
 the "This Parrot Is Dead"-alternative.

We are willing to proceed in either of these directions, and we do have opinions on what to do with this. But, as this email is the "problem statement", this is not the place to express them. 

So there it is. Please speak up on where we ought to go with this. A, B or C (or some other alternative not listed above).

Regards,

John, Stephen and Johan

---

From: Jim Reid <[email-masked]>
Date: Tue, 19 Oct 2010 09:47:27 +0100

> the "This Parrot Is Dead"-alternative.

I vote for B. This document is by definition something that will never  
be complete. so publish now and revise/update later in light of new  
experience. It does not make sense IMO to strive for the perfect all- 
singing, all-dancing release with a "just one more heave" attitude. I  
hope we've all realised that after the many "with this corner case  
fixed, DNSSEC will be done in 6 months" issues.

---

From: Tony Finch <[email-masked]>
Date: Tue, 19 Oct 2010 12:01:54 +0100

On Tue, 19 Oct 2010, Jim Reid wrote:
> I vote for B.

+1

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 19 Oct 2010 13:08:53 +0000

+1 (from the 'something is better than nothing' school of thought) :-)

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 19 Oct 2010 10:22:25 -0400

>  immediately. Also known as the "Perfect is the Enemy of Timely"-alternative.

I like this, but I'd like it more if there were text in the document
that said something like, "This represents current thinking at the
time of publication.  The reader is reminded that DNSSEC is as of
publication in early stages of deployment, and best practices will
likely change in the near term."  Or something like that.  The idea is
to give the reader a clue that s/he ought to be keeping up with the
mailing lists and so on in order to understand what is happening.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 Oct 2010 07:44:17 -0700

>mailing lists and so on in order to understand what is happening.

+1 to Andrew's addition, and maybe add another one: "Some of the techniques and ideas that DNSSEC operators are thinking about that differ from this document include" and a list of interesting phrases, no details.

--Paul Hoffman, Director
--VPN Consortium

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 19 Oct 2010 23:03:07 +0000

> mailing lists and so on in order to understand what is happening.

Or even "These are the guidelines as best we understand them, as we
write, but we expect them to serve partly as a basis for further
discussion and experiment. If you find something better, bring it on."

Sorry guys-- I don't think the parrot is dead enough to get you off
the hook.

Suzanne

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 20 Oct 2010 10:32:53 +0200

> discussion and experiment. If you find something better, bring it on."

Although we have already better understanding for guidelines that are
more complete and have improved clarity. So perhaps "These are the
guidelines as best we understood them" ;).

But perhaps B is the best option, although minor surgery is still needed
before publishing. That includes text like Andrew suggested. Then this
document can serve as input for -bis documents.

Best regards,

Matthijs

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 20 Oct 2010 08:38:43 -0400

On 20/10/2010 4:32 AM, Matthijs Mekking wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

I agree that at this time option B is the best one.
I will send editors nits from my review of the document.
The disclaimer should be that this document covers only
rolling keys of the same algorithm, it does not cover
transition to/from/addition/deletion of different algorithm.

I would also recommend that this document be published as informational.

	Olafur