Re: What are we trying to do?

[Paul Hoffman / IMC <phoffman@imc.org>]

Strawman proposal:

Some security applications allow two hosts that have not had previous 
contact to communicate securely. Two common examples of these 
applications are IPsec and SSH.

In order for the two hosts to identify each other and therefore 
thwart man-in-the-middle attacks, they use public key cryptography to 
sign appropriate messages to each other, as specified in the 
application protocols. In order to do this, each host must both
(a) get the public key of the other
(b) trust that the public key is in fact authentically bound to the other host

Three broad categories of mechanisms for getting the public key of 
another host are:
(a)(1) Ask the host itself
(a)(2) Ask a server that is somehow associated with the host
(a)(3) Ask a bunch of servers that are not associated with the host 
but are known to have a bunch of keys

Two broad categories of mechanisms for trusting the binding of a 
particular public key to a host are:
(b)(1) hierarchical or web of trust to one or more inherently-trusted keys
(b)(2) out-of-band trust of the particular key



Commentary:

All discussion of "keys" falls into category (b)(2) because there is 
no associated reason why someone should trust the key. Out-of-band 
trust implies that the process cannot be done automatically; this in 
turn means that the system won't scale.

(b)(1) implies that users understand trust, and also understand 
transitive trust. This has proven to be false, but no one has come up 
with any other solution in the (b) space.

(b)(1) also implies that the recipient of the certificate has enough 
intermediate certificates to definitively trust or not trust the key 
binding in question. Today, that means that either the recipient is 
prescient, that all trust-trees have a depth of exactly two, or that 
the system delivering the certificate also needs to deliver 
additional certificates. Note that the PKIX WG is working on a 
protocol  that will enable someone to ask someone else for the 
additional certificates, but work on that has been (typically) slow 
and tedious.

The "do it in the DNS" solutions appear to be (a)(2) plus (b)(1). Ask 
the server which knows about the DNS records for the server in 
question; chain through certificates to the DNS root.

A completely minimal PKIX certificate for a 1024-bit key is about 400 
octets long; a typical certificate is closer to 500 octets. This 
means that passing more than certificate in UDP is going to take 
either packets >576 octets (or whatever the magic number is these 
days for minimal PMTU) or it will have to happen in multiple round 
trips.

An alternative to using the DNS protocol to talk to a DNS server 
related to the end host is to do (a)(1): ask the host itself. This 
can either be done in the protocol (both SSH and IPsec already do 
this), or as a new protocol that has a host emit certificates and 
possibly path validation and revocation information about itself. 
Note that this would work fine even for certificates that chain in 
the DNS hierarchy: you don't have to use DNS to ask about DNS 
information.

--Paul Hoffman, Director
--Internet Mail Consortium