[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comments on rollover requirements
Referring to:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rollover-requirements-01.txt
The document doesn't describe the usage scenarios that we will face -
such as close-knit anchor management versus DLV-type anchor
management, or complete compromise versus singleton compromise of a
zone's key set.
Quite frankly, if amazon.com has three keys and one is compromised, I
won't be able to discern which one. The news will probably be
broadcast on some TV station - what news anchor will be able to spit
out which key is the compromised one. Maybe if this were all
automated, the difference between complete and singleton compromises
is significant, but if there's any manual intervention, I don't thin
there is a significant difference.
On to comments on section 5...
5.1 Scalability
This section ignores scalability from the point of view of the zone
operator. The only mention is how many anchors a resolver will
configure.
No solution ought to be dependent on how many resolvers have the
anchor configured. There's not necessarily a relationship between a
zone operator and the resolver operators. E.g., the resolvers run at
AOL (probably) do not have a special arrangement with .ZA. No
business link (like even TLD to registrar) at all.
5.2 IP Encumberance
Is this really the second most important point? That's my only
comment on this.
5.3 General applicability
IOW, don't special case the root zone. What more is there to the requirement?
5.4 Support private networks
That sounds like 5.3. All zones ought to be eligible to be anchors.
And all zones have parents except the root. (Where would a DS RRSet
for the root zone sit?)
Is this section supposed to be a stub for split-zone anchoring? Can
the support be to "turn off" validation, as in a null DS record?
5.5 Detection of Staleness
When you live on top of an unreliable protocol (UDP), you can never
"detect" anything reliably. The lack of an obtainable DS RRSet may
be the result of a disconnected network and not removal of it.
5.6 Manual operations permitted
I think that it should be obvious that an operator can always
disable/ignore any automatic attempt to update the configuration of
their server. Even the software updating mechanisms for my laptop
always ask permission before enacting an upgrade or using upgraded
software.
5.7 Planned and unplanned
In an automated protocol, there's not much difference, is there?
5.8 Timeliness
"Distributed to security-aware resolvers" "timely" highlights the
missing portion of 5.1 on scaling.
5.9 High Availability
This is needed, and made me wonder why we don't rely more on the CERT RR.
5.10 New RR types
5.11 Support for maintenance
This sounds like the functional requirements.
5.12 Recovery from compromise
This section is lacking substance. It basically says "if the problem
is easy to solve, then it should be solvable." No discussion on
whether there is a discernable difference between singleton failures
or mass failures.
After reading this, in general, what is the interop problem? It is
"how does a zone make it's public key (data) known?"
On the one hand, I don't want to reinvent the wheel - meaning, why
not rely on the CERT RR, a CA infrastructure, and maybe even a MIB
for servers? (Yeah, yeah, I know DNS'ers have this thing about MIBs.)
On the other hand, how much of this is a detail for implementers?
Each server has it's own configuration interface, and trust anchors
are just configuration entries?
On another hand, do I want to let something as sensitive as trust
data be able to be silently updated, especially if it is something I
may not understand? (Reading cryptobytes is plaintext hard.)
On the other another hand, if I can do this in band, then the trust
data passes along a path as safe as the application data (i.e., fates
are shared). But the down side is that if the app data can't get
through, the trust data can't either.
I guess I am still leery of putting this mechanism only in to the
port 53 traffic stream. But it has it's advantages.
I just don't see this document describing the problem we are setting
out to solve.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Nothin' more exciting than going to the printer to watch the toner drain...
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>