Wes Hardaker <wjh...@hardakers.net> wrote on 07/05/2009 22:04:11:
> 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.
Thank you.
> 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.
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?
> * 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
Will do, thanks for the suggestion.
> * 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.
Good suggestions, we'll look at them.
> * 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)
Other people have made similar comments about the nomenclature and we are
changing it to something that is (hopefully) more logical.
> * 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).
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 :-)
> * 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.
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".
> * 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.
Agreed.
Thanks for the feedback.
Stephen
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
