Let's assume DNS is involved

[Edward Lewis <lewis@tislabs.com>]

For the purpose of this thread, I will assume that DNS is a crucial element
in the distribution of keys.  I want to lay out two scenarios and look at a
sliding scale of variables between the scenarios.

The first scenario is using DNS as the mechanism to point to keys, and no
more.  The second scenario uses DNS as the only mechanism involved in
delivering keys, e.g., the DNSSEC is used to protect raw public keys.  Of
course, I do not propose that either of these two are the candidate for a
solution - just that I will set these two up as polar opposites, and if DNS
is to be a player in the final solution, DNS will behave somewhere between
the two primordial scenarios.

In the first scenario, DNS contains NAPTR and SRV records that will direct
an application to the source of the keys.  When, e.g., an SSH client looks
up the address record for a server, the client will also ask for keying
information.  The data received will be a series of NAPTR and SRV records
that might lead to (I am making things up here) a server of PGP/X.509
certificates.  All that DNS is offering is to point to this source and it
is up to the client to now consume the certificates, validate the
certificate chain according to that policy, and then extract the needed key
data.

In this scenario, the client has to know how to deal with DNS and the
certificate distribution mechanism, and it has to perform its own policy
for evaluating the incoming data.  The upside of this is that the client is
free to follow localized policy and is not subject to any uncertainty in
the DNS realm.  One other downside to this (other than to have to know all
the elements involved) is that when trying to write the original DNSSEC
implementations to follow local policy - it was an unmanageable effort to
be able to implement the intent of the protocol as well as have to
understand what "local policy" meant and to derive a specification language
for it.

In the second scenario, DNS is used as the end-all in finding application
keys.  Once a, e.g., SSH client gets the address record, the client then
asks for the SSH-server key from an appropriate resource record.

The upside to this is that the client is simplified.  There is just one
query/response format to deal with, and if DNS is holding individual
records for each application, there is no problem thumbing through the data
for what is needed.

The downsides to this for DNS is that DNS has to be able to handle the new
record types (if individual application records ones are used).  Looking at
the record type space, in the decade or so since RFC 1035 was released,
about 50 of 64k types have been assigned.  Although this makes it sound
like there are a lot to hand out (and there are), the problem is that many
of the existing servers in use aren't built to handle (a rapid increase in)
new assignments.

The downside for the application is that the application is now at the
mercy of DNS for a policy and is vulnerable to a DNS breakdown.  In fact,
all applications following this model are simultaneously vulnerable to the
same (instance of a) problem.

So, given the two scenarios, is there a solution in between?  Can DNS be
used to point to a source of keys (possible nestled in a certificate) and
be able to provide a shortcut to acheiving validation of the data found
there - possibly by inculding a fingerprint?

Can DNS be used to improve the current state of security even if the
improvement isn't complete?

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: lewis@tislabs.com

Opinions expressed are property of my evil twin, not my employer.