This document has a number of unjustified and mutually exclusive
requirements. To wit:
From Section 2: "... the child zone must contact its parent zone
and must notify it about the KSK change(s)." Some proposed schemes
involve the parent polling the child. Those schemes may be
unwise, but "must" seems overbroad and certainly unjustified by
the text in this document.
Later in section 2: "the security of these communications [in
manual rollovers] is out of scope of DNSSEC." Not necessarily. A
child might manually add new keys, intending that they be
authenticated in-band, then contact the parent out-of-band to
trigger the update (a process that may not need to be secured),
then the parent fetches the key keys in-band.
In section 3, I'm not sure what is meant by "Every RR MUST be
verifiable at any time..." In any case, I hope "every RR" does not
include "every RRSIG" -- I'd like to allow publication of RRSIGs
even when the DNSKEYs that created them aren't available.
Section 4 has an unjustified requirement for in-band
authentication: "Every exchanged message MUST be authenticated and
the authentication tool MUST be a DNSSEC tool..." Unless we're
limiting this document's scope to in-band rollover, this is grossly
inappropriate.
The next paragraph of section 4 has another unjustified
requirement: "... a child zone,... MUST notify its parent
zone...". Why is this document trying to disallow parent polling?
The next paragraph of section 4 is similarly flawed. It requires
transmission of keys, apparently prohibiting transfer of DS
records or key hashes, as suggested in Scott Hollenbeck's EPP
draft. Where's the justification?
Section 5 adds a requirement ("[a compromised] key MUST be changed
as soon as possible") that is perhaps unnecessary. The section
admits that this may cause validation failures, in direct conflict
with requirements in section 4 ("...at any time ... all RRs MUST be
verifiable, even if an error occurs") and section 3 ("Every RR MUST
be verifiable at any time...").
Section 6 requires the parent NS set to change whenever the child
NS set changes. No matter the preferences of the protocol purists,
this is not how the real world works.
I think the requirements I've picked apart above comprise such a large
portion of this document that the WG would be better off starting from
scratch than trying to fix the current document. Therefore, I suggest
that DNSOP abandon this draft.
-- Sam
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
