Arguements on key distribution vs. DNS

[Edward Lewis <lewis@tislabs.com>]

Originally I was solidly behind the idea of using DNS to distrbute
application keys.  I admit I still believe that this would be beneficial,
but an trying to come to understand the alternatives.

Since this topic is somewhat DNS specific, I'll try to summarize the
arguements for and against the use of DNS as a distrbution mechanism.

(As usual, I am writing this from memory, so if something you think should
be inserted, let us know.  I did not intentionally drop any arguements
based on my judgement.)

FOR

If someone is to have an Internet presence, they will have a domain in the
DNS.  (Whether it is also a zone, and whether they maintain servers is not
important in this arguement.)  Point 1: anyone on the Internet will run the
DNS service.  Point 2: so long as my DNS is performing, by Internet
presence is useful.

Point 1: I must run DNS to be (usefully providing content) on the Internet,
so it will be there.  Other services are optional now, so if I am forced to
use another service (eg LDAP) to distribute keys, I now have to set up an
entirely new service.

Point 2: Any reliability and scaleability considerations I may have are
limited by the reliability and scaleability of DNS.  Using a second service
will drop my  operating envelope to that of the second service.

(I.e., DNS is a convienent and sufficient place to hold the keys.)

DNS has a clearly defined chain of authority, the tree structure.  DNSSEC
definitions default to using this chain of authority but allow for
alternatives, at the discretion of the resolver (eye of the beholder).  An
application can therefore make rational automated judgements about the
integrity of an answer, even if it is customized for the application.

With a fully signed hierarchy, all one needs is the root zone key to be
able to extend "faith" in the accuracy of a lot of data, including
application keys.

Placing application keys in DNS can be done without impacting the DNS
protocol or current name server operations.  The keys themselves can be
designed as pure data to the DNS system.

AGAINST

DNS is a critical service and as such needs to maintain high reliability.
One cog in maintaining high reliability is simplicity.  Simplicity means
uncluttered software implementation and a strict bounds on the data stored
therein.

Being a core service, DNS must be able to respond quickly to a high volume
of requests.  A slowing of DNS has an effect on performance on all other
parts of the Internet, magnified because of interactions of the DNS data
consuming elements.

Therefore, name serving is something left to simplicity.

DNS already has defined a NAPTR record to redirect queries for data to
other services.  (Not the SRV record!)  DNS can assume its role of a lookup
service without getting involved in the management of the data desired.

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