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

From: Andrew Sullivan <[email-masked]>
Date: Wed, 15 Aug 2012 21:53:00 -0400

Dear colleagues,

In Vancouver, according to the DNSOP minutes, participants were to
expect a WGLC "soon" on the subject Internet Draft.

In the archives since the meeting, I observe some comments at
http://www.ietf.org/mail-archive/web/dnsop/current/msg09783.html.  But
I do not observe the announcement of a WGLC.  I am wondering when we
might expect that call.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]

---

From: Peter Koch <[email-masked]>
Date: Mon, 20 Aug 2012 15:19:06 +0200

Andrew,

> I do not observe the announcement of a WGLC.  I am wondering when we

both chairs have taken advantage of the season at least a bit. One
of the chairs has recused himself being a co-editor, so this is
the document shepherd.  Issuing the WGLC involves reviewing the
draft as well as the recent discussion to generate framing questions.

In this particular case, several members of the WG, some of which
I remember having been in favour of WGLC during the Vancouver
meeting, had expressed support for a major change to the draft
suggested by Matthijs Mekking on July 24
<http://www.ietf.org/mail-archive/web/dnsop/current/msg09767.html>
That would basically mean folding significant parts of 'keytiming bis'
into the current 'key timing' draft.

My current reading of the sense of the WG is that we move to
WGLC with -03, declaring the July 24 suggestion out of scope
for this document and keep momentum for 'dnssec bis'. Unless
I hear objections, I'll issue a WGLC no later than Thursday
this week. Opinions, please.

-Peter

PS: That said, documents can be reviewed any time by anyone, with or
    without last call inprogress.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 20 Aug 2012 08:33:32 -0700

> into the current 'key timing' draft.

That was my (probably biased) memory as well.

> for this document and keep momentum for 'dnssec bis'.

That's one way to do it. A better one would be to start WG LC on key-timing with an explicit question to the WG about folding in the keytiming-bis changes. That way, the WG would know the status of both, and we would would possibly produce just one document. The operations community would be better off with just one document, if this WG can do that.

--Paul Hoffman

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 21 Aug 2012 09:12:57 +0200

On 08/20/2012 05:33 PM, Paul Hoffman wrote:
>>> http://www.ietf.org/mail-archive/web/dnsop/current/msg09783.html.
>>>
>>> 
But I do not observe the announcement of a WGLC.  I am wondering
>>> when we might expect that call.
>> 
>> both chairs have taken advantage of the season at least a bit.
>> One of the chairs has recused himself being a co-editor, so this
>> is the document shepherd.  Issuing the WGLC involves reviewing
>> the draft as well as the recent discussion to generate framing
>> questions.
>> 
>>  That would basically mean folding significant parts of
>> 'keytiming bis' into the current 'key timing' draft.
> 

Yes, me too.

>> WGLC with -03, declaring the July 24 suggestion out of scope for
>> this document and keep momentum for 'dnssec bis'.
> 
> That's one way to do it. A better one would be to start WG LC on 
> key-timing with an explicit question to the WG about folding in
> the keytiming-bis changes. That way, the WG would know the status
> of both, and we would would possibly produce just one document.
> The operations community would be better off with just one
> document, if this WG can do that.

I am afraid that one document just isn't sufficient. Adding a rollover
time line requires a fair amount of pages to cover the timing details
(at least with the current approach). The current document now covers
six time lines. When we want to add time lines for Single Type Signing
Scheme, Algorithm Rollover and Policy Rollover, we can come up with
about ten more time lines. It would become a very lengthy document,
arguably even longer than 4641bis ;). In my opinion, it would be
better to categorize them and deal with them over multiple documents
(one document per category).

We then could use one document which has the base terminology, so we
can refer to, for example, the key state definitions in future
documents. However, then we have to make sure that the key state
definitions are flexible enough to be able to describe these other
rollovers (and I am afraid that the current key state definitions are
not).

Best regards,
  Matthijs

> 
> --Paul Hoffman _______________________________________________
> DNSOP mailing list [email-masked] 
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 Aug 2012 08:53:04 -0700

> rollovers (and I am afraid that the current key state definitions are

I disagree that seven or eleven documents would be best for operators. Having more than one requires them to know the RFC numbers for all the documents for which they are possibly interested. Other WGs have problems with developers having to know about three RFCs for a protocol; it seems odd to think that us having a dozen documents for operators is a good idea.

Long documents are not a problem if they are reasonably well organized with truly parallel sections.

--Paul Hoffman

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 22 Aug 2012 07:56:38 +0200

On 08/21/2012 05:53 PM, Paul Hoffman wrote:
>> I am afraid that one document just isn't sufficient. Adding a
>> rollover time line requires a fair amount of pages to cover the
>> timing details (at least with the current approach). The current
>> document now covers six time lines. When we want to add time
>> lines for Single Type Signing Scheme, Algorithm Rollover and
>> Policy Rollover, we can come up with about ten more time lines.
>> It would become a very lengthy document, arguably even longer
>> than 4641bis ;). In my opinion, it would be better to categorize
>> them and deal with them over multiple documents (one document per
>> category).
>> 
>> We then could use one document which has the base terminology, so
>> we can refer to, for example, the key state definitions in
>> future documents. However, then we have to make sure that the key
>> state definitions are flexible enough to be able to describe
>> these other rollovers (and I am afraid that the current key state
>> definitions are not).
> 
> I disagree that seven or eleven documents would be best for
> operators. Having more than one requires them to know the RFC
> numbers for all the documents for which they are possibly
> interested. Other WGs have problems with developers having to know
> about three RFCs for a protocol; it seems odd to think that us
> having a dozen documents for operators is a good idea.

I am not talking about seven or eleven. Although I did not wrote down
an actual number, I could foresee three: One for KSK and ZSK
rollovers, one for so called CSK rollovers and one for key timings
with respect to policy rollovers (including algorithm rollover).

Seven or eleven are indeed somewhat ridiculous numbers. Three is okay
imho, especially if you put in the base document references to the
other ones.

Best regards,
  Matthijs

---

From: Johan Ihrén <[email-masked]>
Date: Thu, 30 Aug 2012 11:40:30 +0200

> That's one way to do it. A better one would be to start WG LC on key-timing with an explicit question to the WG about folding in the keytiming-bis changes. That way, the WG would know the status of…

Not to question the abilities of the WG, but I still have to ask whether (in your opinion) the operations community would be better off with a single document that may be finished around Christmas Eve 2020 or rather live with multiple docs that are published somewhat sooner than that.

> Having more than one requires them to know the RFC numbers for all the documents for which they are possibly interested. Other WGs have problems with developers having to know about three RFCs for a protocol; it seems odd to think that us having a dozen documents for operators is a good idea.

> Long documents are not a problem if they are reasonably well organized with truly parallel sections.

So, on principle I have to disagree with this. Multiple documents are a method of abstraction and organization, just like directories, or, for that matter, dividing your source into multiple files.

If it is really a problem to have to refer to more than on RFC, then I think we made a huge error many years ago when we gave RFCs a number. We should have gone for 

"The RFC For The Internet" (yet to be published)

and meanwhile kept the Internet running on various versions of expired drafts.

Tongue-in-cheek and no offence intended ;-)

Regards,

Johan

---

From: Paul Vixie <[email-masked]>
Date: Thu, 30 Aug 2012 16:45:13 +0000

>>> for this document and keep momentum for 'dnssec bis'.

dnssec-bis was delegated signer. dnssec-ter was type code roll. we're on
dnssec-nextgen now.

> Not to question the abilities of the WG, but I still have to ask whether (in your opinion) the operations community would be better off with a single document that may be finished around Christmas…

while i agree with these sentiments i have a broader concern. ietf's
mantra is good engineering. if we know now that keytiming has flaws, and
we are only considering publishing it because we know our own record
shows that reaching consensus for keytiming-bis will take a long time,
then it's an implicit indictment (by us) of our own record and habits.

we should have a better reason for publishing two documents, like new
ideas occurred to us after the first one was beyond reach of our pen, or
they have different topics.

paul

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 30 Aug 2012 10:11:22 -0700

> they have different topics.

A big +1. An operator who wants to know how to do rollovers will not know *or care* why they followed IETF guidance that was overturned or even clarified soon after.

The reasons that the base document got delayed so horribly do not matter any more: what matters is what the WG and its leadership are willing to do today to help operators in the near future.

--Paul Hoffman

---

From: Joe Abley <[email-masked]>
Date: Thu, 30 Aug 2012 13:57:46 -0400

> A big +1. An operator who wants to know how to do rollovers will not know *or care* why they followed IETF guidance that was overturned or even clarified soon after.

I suspect an increasing proportion of operators doing DNSSEC do not care how to do rollovers, in fact. They care that the software they're using to manage keys and sign things is doing the right thing. The pragmatic long-term view is, I think, that this document doesn't give advice to operators so much as advice for those implementing DNSSEC signers.

I am not suggesting that operators don't care what happens under the hood, or that vendors don't care about operators. But I think the inference that this is advice to heed before you dive in and perform rollovers by hand is short-sighted. The focus ought to be advice that can be converted easily into good code.

I am not a developer of DNS software, and hence don't feel well-placed to review the draft from that perspective. However, my feeling (based on words absorbed inadvertently from people who are developers) is that the document would better serve that perspective if it presented robust state machines and algorithms for arbitrary rollovers.

As an operator I would very much like trustworthy tools that could take my desire (say) to roll a KSK from an N-bit alg-A key to an M-bit alg-B key and show me the timing constraints for that rollover to be completed, so I can plan the exercise, accommodate any expected delay in DS publication in parent zones, keep my relying parties informed, and hopefully have robots execute the actual zone changes for me. Working all that out by hand (and making the zone changes manually) based on the advice in dnssec-key-timing is error-prone.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 30 Aug 2012 11:21:09 -0700

On Aug 30, 2012, at 10:57 AM, Joe Abley <[email-masked]> wrote:

> I suspect an increasing proportion of operators doing DNSSEC do not care how to do rollovers, in fact. They care that the software they're using to manage keys and sign things is doing the right thing.

Good point, yes.

> The pragmatic long-term view is, I think, that this document doesn't give advice to operators so much as advice for those implementing DNSSEC signers.

Yes and no. Many of the aforementioned operators are probably going to be asked "are you sure that the software you are using follows the specifications" and those operators are going to look for the vendor's checkmark next to "the right" RFC number.

If so, this argues strongly for fewer RFCs for the checkmarks to match to.

> I am not suggesting that operators don't care what happens under the hood, or that vendors don't care about operators. But I think the inference that this is advice to heed before you dive in and p…

Yes. Here, "good" should also mean "code whose logs can be followed by someone who hasn't read the RFC, if needed".

> As an operator I would very much like trustworthy tools that could take my desire (say) to roll a KSK from an N-bit alg-A key to an M-bit alg-B key and show me the timing constraints for that rollo…

Yes.

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Thu, 30 Aug 2012 19:24:05 +0100

> then it's an implicit indictment (by us) of our own record and habits.

But I thought the flaws discussed in this thread were in terms of
presentation rather than engineering. (I haven't reviewed the document
yet.) As far as I can tell DNSSEC implementations and deployment are still
in a somewhat exploratory phase wrt key management, so it is reasonable to
expect it to take a long time to work out how to simplify the document in
a sensible way. I expect it to go along with good implementations of
canned rollover procedures.

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.