From whence we came...

[Edward Lewis <lewis@tislabs.com>]

This mail list has been set up to discuss the distribution of public keys
on the Internet.  In this message I will try to convey the history of this
effort, set the context for what we are trying to solve and layout a
roadmap of where we might go.

The topic is the distribution of public keys over the Internet.  Whether
the term "public key" is strictly defined or loosely defined has not been
determined.  What "distribution" means is also ill defined at this time,
but there have been working definitions in use for months.

The history of this effort is in the DNS Security Extensions effort.  This
means that the discussion so far has been DNS centric.  This does not mean
that the discussion must remain so, nor does this mean that the result of
this effort will be an addition to DNS (for any value of "addition").

This mailing list is set up with the possibility that there will be one or
more IETF BOF meetings on this and maybe a working group.  Be aware that
this does not mean holding a BOF or acheiving WG status is a goal of the
effort (defined by the maillist), but that these are possibilities.

ORIGINAL INTENT

The very beginnings of this effort lie in a feature of the KEY resource
record in the DNS Security Extensions.  As defined in RFC 2535, but soon to
be modified, the KEY RR is defined to hold a public key.  A public key is
the public component of an asymetric public-private key pair.  (Symmetric,
shared secrets, have been explicitly beyond scope to date.)  According to
the design intent of RFC 2535, public keys associated with applications
could be placed in DNS.  (As will be described later, current DNS thought
is to discontinue this practice.)

The operational scenario for the use of public keys in DNS is roughly as
follows.  Assume a signed DNS zone and (for example) SSH running on a host
listed in the zone.  The SSH key could be placed in DNS, in the same
database location as the address record.  When a client asks to open an SSH
connection to the serving host, the address and key are made available to
the client, who can then open a secured connection.  The security of the
key is backed by the zone and zone administrator.  (Many details are
omitted here.)

There has also been consideration of Public Key Certificates.  RFC 2538
defines a record, CERT, that is designed to hold certificates.  In the
definition of this record, the RFC states that the intent is to hold
structures that can be protected by other means (than DNS Security).  For
example, a PGP certificate can be signed by a key in another PGP
certificate, which is turn is also signed by another.  Again omitting many
details, the CERT record is seen as a feature to allow the distribution of
the output of a PKI, and not a PKI itself.

EFFORT HISTORY

DNS Security Extensions are maturing in the DNS working groups, DNSEXT and
DNSOP.  There is an off-shoot mailing list at dnssec@cafax.se where more
discussions have happened.  Since the RFCs defining the DNS Security
Extensions have been issued, there has been a lot of activity to refine the
definitions.

Parts of the activity have been driven by the need to make the RFC's more
ameanable to operations, in other words making the extensions work in
everyday zone administration.  Other parts of the activity have been
directed towards making the extenstions a starting point for securing
Internet applications.

Sidebar paragraph: Using cryptography to achieve security is fairly
straightfoward to understand and implement (first with the observation that
cryptography is just a tool for security and does not guarantee it).  The
difficulty in implementing cryptography is that it needs fuel to run -
namely fresh sets of keys.  Distributing and exchanging keys is crucial
problem to solve and is a difficult problem.  This is why the desire to put
application keys in DNS began.

The effort to secure Internet applications spawned many heated debates.
Since this message is trying to set the context, the contents of the
debates aren't raised here.  The bottom line is that the discussions to put
application keying material in DNS ground to a halt with no forseeable
solution within the DNS community.  In fact, one of the results of the
debates is a step backward for the effort, the newly proposed restriction
on the KEY resource record, removing it as a candidate for applications.
(This step backward isn't a condemnation of the effort to secure
applications, but is a needed step to be able to secure the DNS itself.)

CURRENT STATE

The effort to secure applications, born in the DNS area, has emerged as a
non-DNS problem.  The debates within the DNS area did expose a number of
observations which are beneficial.  One issue is that any key management
system (of which distribution is a component) is sensitive to the so-called
trust model  of the environment.  Furthermore, environments differ from
application to application.  Thirdly, the "unwritten rules" of how and why
data is stored in DNS became more ane more "written."

Based on the observation that key distribution is sensitive to
applications, groups who had been working within DNS to try to provide a
baseline key distribution realized that a broader audience is needed to
define the environment for key distribution.  An effort has begun to survey
protocols in the Internet to look at trust models and key management.  This
effort will be more successful with the input of experts from the protocols
than from just within DNS.

Besides the need to better define the problem, there is a need to better
understand existing systems that might help solve the distribution problem.
While it is true that DNS has "ejected" this work item for the time being,
it might well be that DNS is an important piece of the solution.

Another sidebar: while it may appear from this message that the DNS groups
wanted this discussion to leave, the atmosphere was "friendly."  Many of
the WG members supported the use of DNS to secure applications, but there
were significant objections raised.  These objections could not be answered
from the expertise within the group.  Further, when reexamining the charter
and workload of the WG's, it was decided that other issues needed more
attention in the near term.

WHERE WE ARE HEADED

The phase of this effort is "find our scope, set definitions, determine
requirements."  The first steps include:

o Determining the need for a common approach to key distribution
   why do this in common (as assumed in DNS) instead of per application?
o Defining the kinds of services we need to provide
   i.e., key distribution? management? storage?
o Scoping the applications for which we think there is a common solution
   e.g., IPsec is a candidate event though it is in layer 3, etc.
o Documenting constraints within which protocols can be used as a solution
   e.g., there are bounds on what DNS can and will not be bent to do

Documents that have already been proposed include (titles used here are
premature suggestions):
   A Survey of Application Key Distribution
   Constrains on Key Distibution in DNS
This is not a complete set of documents.  And since we aren't a working
group, documents will be individual submissions - and there's no one who
can rightfully admit or deny a document's relevence.

The place of this effort in the IETF process is that of a group of folks
trying to define a problem to solve.  If we identify a quantifiable problem
- and a few of us already believe we are onto something - we would then try
to charter (define scope, approach, milestones) this effort.  But this
discussion is beginning to get too far ahead of ourselves.

CONCLUSION

I hope this gives some context to the mail list.  I am sure others will add
the significant bits that I have omitted.  Over the next few months, we
should be able to delve more into the points studied so far.

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

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