In addition to a bunch of nits Samuel Weiler wrote:
We are CC-ing the dnsop list as this is a relevant content change that could do with WG review.I'm not done with the last substantive section, but here's the current list, somewhat ordered. I'll send the substantive ones to the list later. I think the first item is critical.
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 it did, 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.
You are correct a pre-publish is possible.
We did two things. We reworded this paragraph to argue that it is not the most elegant way to roll the KSK and moved it behind the the sections on KSK and ZSK rollover
So the order is now.
4.2 Key Rollovers . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Zone-signing Key Rollovers . . . . . . . . . . . . . .
4.2.2 Key-signing Key Rollovers . . . . . . . . . . . . . .
4.2.3 Difference Between ZSK and KSK Rollovers . . . . . . .Below is the new text.
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.
The currently most commonly available signer shows this behaviour. We think following the behaviour of the signer is clearer.
Section 3.5Its applicable to confidentiality and integrity. I do not think we have to change these recommendations in the light of the SHA1 vulnarability but I am not sure. Guidance would be appreciated.
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.?
We used to have this text, it got removed between version 01 and version 02. Unless directed by the WG we keep this out.
We have seen events where data needed for verification of an authentication chain had expired from caches. We suggest the TTL on DNSKEY and DSs to be between ten minutes and one hour. We recommend zone administrators to chose TTLs longer than half a minute.
-----------------
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.)
Sentence now reads:
After one stopped publishing an RRSIG in a zone it may take a while before the RRSIG has expired from caches and has actually been removed from the DNS.
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.
Part after the semi colon rephrased as:
it may take some time for the data to be transfered to other secondary
authoritative nameservers and clients may be fetching data from caching non-authoritative servers.
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.
I think that this addition is confusing. Personally I think that we should advocate the setting of the SEP bit as it helps troubleshooting. I think that leaving out the "protocol purity" text above will not introduce possible problems.
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.
We added your suggested text.
Section 4.1.1, fourth bullet
"RRSIGs in the zone server by the slave server" doesn't makse sense to
me.
That should have read "RRSIGs in the zone served by the slave server pass ..."
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.
We reprhased that sentence:
We also suggest that operators of nameservers that supply secondary services develop 'watch dogs' to spot upcoming signature expirations in zones they slave, and take appropriate action.
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"?
Rephrased:
How quickly can I reach an administrator of secondary servers to load a valid zone?
Section 4.2.2.1I hope its the right number (its what we tried to argue) and if it is it cannot be constrained (as we tried to argue) :-)
... 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.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//
Rephrased to:
Also the pre-publish scheme involves more parental work when used for KSK rollovers as explained in <xref target="keyroll"/>.
4.2.3 ..., and where removal of the keys by the child can be signaled by the parent. ... This is confusing me.
Does this help:
Using an established trust relation, the interaction can be performed in-band, and the removal of
the keys by the child can possibly be signaled by the parent.
But isn;'t it clear from "the malicious key holder" to which the "i.e." refers?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.
These proposed modifications are made available through http://www.secret-wg.org/dnsop/
(an htmlwdiff at: http://www.secret-wg.org/dnsop/draft-ietf-dnsop-dnssec-operational-practices-03-04pre1.html)
If we receive no further comments in the next 10 odd days we'll post a new version and ask the
chairs to consider forwardingthe document to the IESG.
--Olaf and Miek
. dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
