[dnssec-deployment] dnssec automatic trust anchor configuration

[Edward Lewis]

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

2) Direct

3) Indirect

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 
malfeasance.

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
NeuStar

Sarcasm doesn't scale.