[dnssec-deployment] dnssec automatic trust anchor configuration
Ed.Lewis at neustar.biz
Mon Mar 12 08:39:00 EDT 2007
At 0:55 +0100 3/8/07, Roy Arends wrote:
>As an example, take the DNSKEYs that RIPE publishes on their website:
>The concept that DLV uses is similar to a Certification Authority. It is the
Moving from the situation of an RIR to DLV is quite a semantic leap.
I would categorize the relationships between DNS parent and child,
with regards to registry situations, in to four categories.
1) The reverse map
4) Third party
The first category describes the situation for IANA and the RIRs.
These registries "create" and determine the holdings of the
registrants and then assign to the registrant resources that are
reflected primarily in the routing tables and secondarily in the DNS.
Work in this arena is already on-going with respect to using
certificates to authenticate the routing table (feeding) data.
The second category are registries in which a customer directly
requests a domain name of the registry. The similarity with the
first category is that when this hits the DNS, the parent-child
interaction does not go through any kind of broker. The differences
are that DNS is the primary protocol for the registration (therefore
certificate work has not been done here) and the "creation" of the
resource is made by the registrant.
The third category are registries which work through registrars and
other agents to accept registrations. In this situation, the
distance between the parent and child is greater. The significant
difference from the second category is the need to handle middle
"boxes" in the trust model.
The fourth category, into which DLV falls, is not reflected in the
DNS and is not a relationship between registrant and registry as the
first three categories are. This is an "aftermarket" situation in
which the relationship is primarily between the relying party (the
validator) and the trust "broker."
I think it is important to consider the environment. Anything can be
automated (in the 70's I had a poster that said "To really screw
things up, you need a computer") but what's going to be the headache
here is what do the certificates bind together.
For interesting reading, look at the debate running over the use of
certificates in securing routing and the RIRs. This has been going
on for about two years now and is quite an extensive discussion,
including getting into the meaning of the expiration of a certificate
and how it relates to getting a route accepted.
I think the pure mechanics of distributing trust anchors in X.509
certificates is quite convenient. The same mechanics can be made to
work for all four categories, including revocation. However, the
mechanics are the least interesting part of the problem. Using X.509
certificates mean having to now work within certificate handling
processes, which is non-trivial. There's a lot of work to be done,
much more than managing DNS zone.
Not that the work has no commensurate rewarded, but, it's not easy.
The reason I thought of the four categories is that there is a
"trust" flow that is unique to each.
In category one, the trust starts at the registry. First they vet
the request but after that they do all the work. By them selecting
the resource, they create the DNS domain name to delegate. As they
create the name, there's no question of what goes into the
certificate. I know of only once has a recipient protested a
resource - an allocation from IANA to APNIC (about the time of the
last San Fran IETF), the protest was because part of the allocation
had an IANA reserved sticker on it.
In category two, the trust comes from the registrant first as they
choose the name. There maybe restrictions on the choice and there
may be other concerns (trademark) to consider. The vetting process
here is much different than for category one as the justification for
the registration is much different.
In category three, the trust is the same, but there may be many
middle boxes in the trust path. From the registrant to registry that
is. What category two and three share is that the DNS data is begin
served by the one authority that "knows best" as far as the validity
of the name's registration. The question is whether there has been
subscriber fraud (lying in the registration) or a middle box
Category four is completely different. Here the trust is from the
relier to the broker, and the trust isn't that the data is true and
honest, but that the broker has done a sufficient job in obtaining
and publishing the true data. For example, if a registrant commits
subscriber fraud at a registry, resulting in an inappropriately
secured DNS entry there is one set of legal consequences. What if a
DLV is also "victim" to this fraud? If all the DLV promises is to do
it's job diligently, what happens to a relier that realizes a loss
because of the fraud? Will the DLV help go after the registry
(presumably insured) and others?
Perhaps if the problem is scaled back to "just protect the DNS" and
not seeing this as part of the critical path, it would be easier to
justify the work. Application (protocols) should assume their own
security even with DNSSEC.
Edward Lewis +1-571-434-5468
Sarcasm doesn't scale.
More information about the Dnssec-deployment