Re: Arguements on key distribution vs. DNS

[David Conrad <david.conrad@nominum.com>]

Ed,

On 12/31/01 7:18 AM, "Edward Lewis" <lewis@tislabs.com> wrote:
> AGAINST
> 
> DNS is a critical service and as such needs to maintain high reliability.

While I agree that the DNS is a critical service, the requirement to
maintain high reliability has, to date, not been met (at least as indicated
by the various studies that show very high percentages of
mis-configurations, lack of response to queries, etc).  Since a broken DNS
is often a self-correcting problem (when people can't get their work done,
they'll fix what is broken),

> One cog in maintaining high reliability is simplicity.  Simplicity means
> uncluttered software implementation and a strict bounds on the data stored
> therein.

While I'll buy the "uncluttered software implementation" (and I might add
"too late!"), I'm not so convinced on the "data stored therein".  To the
contrary, I figure the reliability of the system should be independent of
the data stored therein.
 
> Being a core service, DNS must be able to respond quickly to a high volume
> of requests.

DNSSEC would seem to contradict this.

> DNS already has defined a NAPTR record to redirect queries for data to
> other services.

As has been pointed out by others, NAPTR doesn't insure secure access to the
thing pointed to.

> Placing application keys in DNS and then relying on the DNS Security
> Extensions to provide security of the keys places an extra burden on the
> DNS administrator.

I'd be surprised if this is significant compared to the general maintenance
of DNSSEC.

> The administrator is now responsible to a higher degree
> for the contents of a zone.

> By relying on the administrator, an individual application's trust model is
> now reliant upon someone that may be operating out of the bounds of the
> application and beyond control when something needs to be fixed.  Along the
> same lines, applications (in general) relying on an administrator will be
> forced or coerced into having similar trust models even if the each
> application's needs are different.
> 
> With a fully signed hierarchy, all one needs to break is the root zone key
> to be able break "faith" in the accuracy of a lot of data, including
> application keys.  (Notice that change to the word "break" from the FOR
> entry corresponding to this.)
> 
> MY OPINION
> 
> Like I said, I used to be for using DNS, but now am unsure.  I do think
> that DNS is the most convienent vehicle and that the extra burden isn't a
> problem.  However, I am unsure about the trust model issues and whether the
> approach of using DNS to redirect queries to other services is a bad idea
> or good idea.
> 
> PS - This isn't a complete treatment of the DNS issue.  To be so, some text
> on what constitutes an easy addition to DNS is needed, an explanation of
> how DNS matches queries to answers, and a description of what DNS is not.
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                NAI Labs
> Phone: +1 443-259-2352                      Email: lewis@tislabs.com
> 
> Opinions expressed are property of my evil twin, not my employer.
> 
>