About halfway through this document, I was expecting (and hoping) to
say that I supported its publication. I still think it's a good doc,
but I think there are several substantive issues that need to be
addressed. I'll start with the most important, then move on to less
substantive stuff. Minor editorial points have been sent directly to
the editors.
-- Sam
Section 4.2.1 This section says that the pre-publish scheme doesn't
work for KSK rollover (4.2.2.3 says the same thing.) -- I thought
pre-publishing did work, so long as you were prepublishing DS records
in the parent (hence publishing multiple DS records). The current
language seems to imply that no pre-publish scheme will work, and I'm
extremely uncomfortable with that. Would you consider saying that
pre-publishing DS records would work?
Section 4.4.2 suggests storing DNSKEYs, not DSs. I think this is bad
advice -- DS message digest algorithms may be used for signaling (of,
for example, use of NSEC3), so the child may want to choose the
message digest algorithm. Rather than require the parent to support
them all, why not just let the child provide the hash?
Examples (sections 4.2.1, 4.2.2.1, 4.2.2.2, 4.2.3): Why do you show
both keys, particularly the ZSK, signing the DNSKEY RRset? I think
the examples would be clearer if only the KSK signed the DNSKEY RRset.
Alternatively, add text explaining why the RRSIG is there and
explaining that it's not strictly necessary.
I found section 4.3 (and 4.3.1 and 4.3.2) very confusing (in fact,
those are the sections that I got most stuck on as I tried to finish
this review). For instance, it says "the local zone can only be
resigned with the new KSK after [there's a new DS in the parent]".
That not only sounds incorrect (why can't you?, and why are you
signing the whole zone with a KSK?), it sounds dangerous. I'm not
sure what to do with the last paragraph of 4.3. For the first
paragraph of 4.3.1, perhaps reorder it and number the steps:
1. parent removes DS
2. remove compromised DNSKEY, add new one, sign DNSKEYset with new
DNSKEY
3. after TTL, publish new DS at parent
4.3.2 is similarly awkward. I haven't finished reading the appendix
(especially B); maybe that will help.
Section 3.5
Is the table (and the cited paper) applicable to authentication? (As
compared to confidentiality.) I'm not sure that it is, but I'm
willing to go read the paper and ponder this some more.
Section 4.1.1, third bullet, re: making the TTL long enough to fetch
all data for a verification. Could we make an estimate? 5 sec.? 30
sec? 60 sec.?
-----------------
Less important stuff (mostly text/documentation issues):
Section 1.2
After one stopped publishing an RRSIG in a zone file it will
take a while before the RRSIG has actually been removed from
the DNS.
Why? (Yes, I know why, but the sentence seems to come out of the blue
here.)
Section 2, third paragraph
Administrators of secured zones will have to keep in mind that data
published on an authoritative primary server will not be immediately
seen by verifying clients; it may take some time for the data to be
transfered to other secondary authoritative nameservers, during which
period clients may be fetching data from caching non-authoritative
servers.
The part after the semicolon doesn't make sense to me as an
explanation of the part before the semicolon -- if clients are talking
to caches, what different does secondary update delay make? This
seems to be confusing two different things.
Section 3.1
I suggest adding even more explicit text explaining that that the
SEP flag is merely advisory, and that separation of these functions is
not necessary. I suggest something like the following (taken from
draft-weiler-dnsext-dnssec-bis-updates-00 section 5):
Futhermore, note that the SEP bit setting has no effect on how a
DNSKEY may be used -- the validation process is specifically
prohibitted from using that bit by -records section 2.1.2. It
possible to use a DNSKEY without the SEP bit set as the sole secure
entry point to the zone, yet use a DNSKEY with the SEP bit set to
sign all RRsets in the zone (other than the DNSKEY RRset). It's also
possible to use a single DNSKEY, with or without the SEP bit set, to
sign the entire zone, including the DNSKEY RRset itself.
Section 3.5
Says " Also see Section 3.1.1." My immediate question was "why?".
The answer is "for a discussion of how keys serving different roles
(ZSK v. KSK) may need different key strengths." Consider saying that.
Section 4.1.1, fourth bullet
"RRSIGs in the zone server by the slave server" doesn't makse sense to
me. I have a general note of "confusing" by the bullet -- I don't
have specific changes, though. Later on in that bullet the phrases
"slave zone" and "secondary zones" appear -- I don't think we want to
use those terms. There's also a sentence: "How quickly can I reach an
administrator and load a valid zone?" -- should that be
"master" or "primary" instead of "administrator"?
Section 4.2.2.1
... The minimum
duration of this pre-roll phase is the time it takes for the data
to propagate to the authoritative servers plus TTL value of the
key set. This equates to two times the Maximum Zone TTL.
This implies that it (may) take a TTL for data to propagate to the
secondaries/slaves. Stupid question: is that the right number? Could
it be constrained to something shorter?
4.2.2.2
I'd like to see this document mention the mandatory algorithm rules,
and somewhere around 4.2.2.2 or 4.2.2.3 seems like the right place.
>From the last paragraph of -protocol section 2.2:
There MUST be an RRSIG for each RRset using at least one DNSKEY of
each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset
itself MUST be signed by each algorithm appearing in the DS RRset
located at the delegating parent (if any).
4.2.2.3
First bullet: as before, why can't one pre-publish DS records?
I find this statement disturbingly overbroad. Also, pre-publish takes
longer (an extra TTL?). Also: s/just//
4.2.3
..., and where
removal of the keys by the child can be signaled by the parent. ...
This is confusing me. What do you mean?
4.3
While an authentication chain to your compromised key exists, your
name-space is vulnerable to abuse by the malicious key holder (i.e.
the owner of the compromised key).
"owner" implies to me "rightful owner", which means this doesn't make
sense, but I'm not thinking of a good term.
---------------------
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
