Subject: [DNSOP] comments about draft-morris-dnsop-dnssec-key-timing

From: Wes Hardaker <[email-masked]>
Date: Thu, 07 May 2009 14:04:11 -0700

As I stated in the meeting, I think this document is a great idea as an
addition to the RFCs about DNS(SEC).  Kudos for writing it, and great
kudos for the diagrams and generally clear text.

Comments though:

*** Biggest one: I still believe that this document would be horribly
    remiss without including the timing associated with RFC5011
    processing.  It's becoming more and more clear that zone operators
    will be encouraged by their registrars to roll they're keys in 5011
    compliant manners for automatic DS or DLV record updates to succeed
    without requiring conversation.  The extra timing constraints
    introduced by RFC5011 aren't nearly as bad as the timing constraints
    in the draft, and thus I think the increase in complexity will only
    be a small fraction of what is already a complex situation.

    I think it could be best handled by simply including a section near
    the top that defines one term that is included in all the needed
    equations below.  That term would be 0 if you weren't doing RFC5011
    processing or would be something like 30days + fudge, for example,
    if you were.  That wouldn't require making the text below more
    complicated but would still show the important points in the process
    where longer wait times are necessary.

    I think this is critical and must be included.  IMHO, of course.
    But I'll do my best to adapt everyone else's HO as well.

* mention the appendix early in the doc as a handy reference.  i.e. it's
  highly useful to refer to when reading the doc itself

* 2.1: Dp => time delay fudge factor.  I think the text, by the time you
  get to the bottom, adequately describes the issues with needing to
  wait a period of time that is highly variable because of operational
  delays.  I'd be tempted (since I think it's a confusing point to many)
  to bring it up in it's own paragraph before the rest of the math
  begins.  Discuss the issues with propagation and possibly mention that
  some code bases just use a standard doubling to ensure the timing is
  safe (e.g. instead of waiting for just a TTL, wait for 2*TTL instead).

* 2.2.2: I think the wording could be a clearer here.  That being said,
  I haven't done the decency of suggesting an alternative paragraph or
  two have I?  (Sorry).

* 2.2.2: and others: I'd be tempted to use a different event enumeration
  system.  Group each set of events together so when you switch from one
  scenario to another users can be sure you're not talking about the
  same event.  My initial thought was to use events of the form A.1,
  A.2, ... and then switch to B.1 ... when switching to a different
  timing discussion.

* 2.3.1, last word: "events" -> "external triggers" or "other triggers"

  ("events" already has way too much context above and thus a different
  word would be better just to ensure it's not confused with the
  previous text; pick the synonym of your choice)

* For acronyms/terms/abbreviations like "Nze" you have defined as "the
  (n)umber of (e)mergency (Z)SKs".  Most of the terms suffer from a
  battle in user memorization because the ordering of the words differs
  from the ordering of the letters.  It took me half the document to
  realize why I wasn't remember what each term was.  There is a
  consistence to the abbreviations that makes sense, so I think it'd be
  better to simply reorder the words instead.  For example "Nze" could
  be "the number of ZSKs for use in emergencies".  (this is actually a
  harder one; most of the rest of them have an easier wording/ordering
  swap than this example)

* I'd strongly recommend, when you get everything further along and
  about finished, that you hand it to someone fresh to have them check
  all the equations from scratch.  Some of them are complex enough that
  I wouldn't be surprised if an thinking error snuck in (not that I
  don't have confidence in you!  To err is human).

* 3.1, bullets 2 and 3: technically ZSKs can be pointed to by a DS and
  can be used as trust anchors.  It would probably be easiest if
  you declared that aspect out of scope as it isn't the recommend usage
  case.

* 3.1, paragraph ending in "and its publication in the zone.)":
  I'd list Dr instead as the "time between publication of the key and
  the DS publication" because the timing of when the parent was informed
  is not as important as the time between the key publication and the DS
  publication.  When it was published to the parent is almost certainly
  different from when the key first got published.

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

---

From: [email-masked]
Date: Tue, 19 May 2009 13:03:09 +0100

> kudos for the diagrams and generally clear text.

Thank you.

>     But I'll do my best to adapt everyone else's HO as well.

As Johan said at the WG meeting, the draft only deals with state 
transitions, not distributing trust anchors.  However, you make a powerful 
argument: what do other people think?  Is there a need for detailed timing 
considerations of RFC 5011 processing?

>   highly useful to refer to when reading the doc itself

Will do, thanks for the suggestion.

>   A.2, ... and then switch to B.1 ... when switching to a different

Good suggestions, we'll look at them.

>   harder one; most of the rest of them have an easier wording/ordering

Other people have made similar comments about the nomenclature and we are 
changing it to something that is (hopefully) more logical.

>   don't have confidence in you!  To err is human).

Will do.  Although I do have great confidence that the readers of the 
draft will point out any errors - providing they don't read it immediately 
before bedtime :-)

>   you declared that aspect out of scope as it isn't the recommend usage

This raises a question that we have discussed amongst ourselves, namely 
the terminology "KSK" and "ZSK".  Conceptually it is simple, in that a ZSK 
signs the records in the zone, and a KSK signs the DNSKEY RRset and is 
pointed to by a DS/configured as a trust anchor.  But as you say, ZSKs can 
be pointed to by a DS and used as trust anchors.  And theoretically you 
could have multiple ZSKs, each of which signs just some of the records in 
the zone (a partial-zone signing key?).

So would better terminology be something like "local key" and "non-local 
key" where the distinction is between a key referenced only within the 
zone (i.e. by RRSIGs), and one that is referenced by something outside the 
zone (DS record in the parent/trust anchor repository)?  I.e. the terms 
"ZSK" and "KSK" simply refer to two particularly useful combinations of 
properties:

"ZSK" = "local references" + "signs entire zone"
"KSK" = "non-local references" + "only signs DNSKEY RRset"

while several other viable models exist, including your example:

"FOO" = "non-local reference" + "signs entire zone".

>   different from when the key first got published.

Agreed.

Thanks for the feedback.

Stephen

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 19 May 2009 12:35:35 +0000

This is going to be a very useful document, two high-level points:

> considerations of RFC 5011 processing?

I understand the distinction you're making so maybe another document
should be written around 5011, but getting the bits out there would be
good and this is also not a bad place to do it. (Does adding Wes'
additional term open too many other cans of worms, or no?)

> the zone (a partial-zone signing key?).

Please don't change this. Making finer distinctions in one document,
clearly defined, is one thing. But please don't try to change
terminology we're finally starting to get people to use; it's been
(and continues to be) hard enough to get them to stop talking about
one key and the singular act of signing.

thanks,
Suzanne

---

From: John Dickinson <[email-masked]>
Date: Tue, 19 May 2009 14:38:01 +0100

> This is going to be a very useful document, two high-level points:

Thanks

> one key and the singular act of signing.

This was kind of my idea - so maybe I can explain my thinking a bit. I  
am wondering if this document should restrict itself purely to  
considering keys and say nothing about what is signed by those keys.  
Therefore, it would not use the KSK and ZSK terminology.

You could have keys with the following set of properties:
- how they are rolled (pre-publish or double key)
- the SEP bit on or off
- bit 7 (zone key bit always set)
- bit 8 revoked bit
- protocol == 3
- an algorithm
- a size
- is this key intended to be pointed to by a DS RR?
- is the zone operator doing RFC5011?

Some of these properties impact on, or are altered by, timing  
considerations.

Some combinations of these properties make useful keys and it may well  
be best practice to use them to sign particular RRSets. However, I  
wonder if this draft is the place to comment on that issue - would it  
be better in a BCP. This draft could just consider the timing  
considerations for keys with particular (anticipated to be useful)  
sets of properties and be pointed to by a BCP which says which  
properties a good KSK, ZSK or anotherSK should have and what RRSets  
they actually sign.

John

---
John Dickinson
http://www.jadickinson.co.uk

I am riding from Lands end to John O'Groats to raise money for  
Parkinson's Disease Research. Please sponsor me here http://justgiving.com/pedalforparkinsons2009

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 19 May 2009 06:42:46 -0700

>>>>> On Tue, 19 May 2009 13:03:09 +0100, [email-masked] said:

>> you declared that aspect out of scope as it isn't the recommend usage

SM> This raises a question that we have discussed amongst ourselves, namely 
SM> the terminology "KSK" and "ZSK".

I think, as I said, you should just acknowledge the fact that the text
deals with the recommended way to do things and that although it's
possible to use DS and DNSKEY records in other ways it's outside the
scope of the document.
-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

---

From: [email-masked]
Date: Tue, 19 May 2009 13:46:54 +0000

On Tue, May 19, 2009 at 02:38:01PM +0100, John Dickinson wrote:
> Sz sez...

	are you going to focus on the key, its intended/expected use
	or something else (the signatures or the items covered by the
	signatures...)

> Some of these properties impact on, or are altered by, timing  

	for the key... timing is immaterial. only the signature 
	has a temporal consideration.  unless you want to equate
	key visability with time.

> Parkinson's Disease Research. Please sponsor me here 
> http://justgiving.com/pedalforparkinsons2009
> 
> 
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Edward Lewis <[email-masked]>
Date: Wed, 20 May 2009 10:15:22 -0400

At 14:38 +0100 5/19/09, John Dickinson wrote:

>am wondering if this document should restrict itself purely to considering
>keys and say nothing about what is signed by those keys. Therefore, it
>would not use the KSK and ZSK terminology.

You may be right about avoiding the KSK/ZSK terminology when thinking 
about architectural correctness, but for the sake of operators and 
policy makers there should be some written material "mapping" KSK/ZSK 
into the the terminology of the document.  We'll need some reference 
material that glues this document into the language we use. 
Otherwise we will end up with a cogent but misunderstood document 
that will be ignored by the folks that need it the most.

Right or not, in operations, KSK/ZSK has become an essential concept. 
(Perhaps because it was workshop "ops" experience that gave rise to 
the terms.)  If we have to go back and relate that to SEP or 
something else, we're just mapping terms to terms to concepts.  An 
image of a car skidding on ice comes to mind.

BTW, I did read this document before drawing up plans for key 
succession.  The document has a great amount of detail.  I had to 
digest it and simplify it before I could put a plan in front of an 
implementation and operations teams.  It's not a level of 
comprehension, but fewer moving parts is a good thing when it comes 
to "heat of the battle" situations.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Getting everything you want is easy if you don't want much.

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 20 May 2009 17:15:15 +0000

> that will be ignored by the folks that need it the most.

What he said....I pulled up the thread to try to say exactly this, but
it's now been said so I can stop.

> to "heat of the battle" situations.

I'd like to see the detailed architectural discussion, and the mapping
from it into "ops terms" (KSK/ZSK and suggested practices or
considerations), all in one document. I understand the argument for
having a separate BCP to accomplish that, but I'd really like to have
an integrated document to point people to for both good practice and
its architectural rationale.

Suzanne

---

From: Edward Lewis <[email-masked]>
Date: Wed, 20 May 2009 13:39:40 -0400

>its architectural rationale.

One of the obstacles to the goal of mapping a detailed architectural 
discussion into "ops terms" is that when it comes to operations 
environments, they tend to have unique circumstances.  Operators will 
be grafting DNSSEC on to diverse existing architectures.  Each will 
have different regulations and requirements for operations.  Overly 
specific recommendations can "backfire."

Even if the service is a commodity, there may a lot of differences in 
the back offices of the providers.

OTOH, if there is a critical mass of one kind of registry or another, 
then it is fine to generate a document.  But please be very clear and 
specific of the "demographic" of the audience.  (What I am trying to 
avoid is getting into a situation where someone tries to make all DNS 
servers conform to BCP 40.  I.e., it's not a sin to allow AXFR.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468