Re: RESCAP/RC: an alternative to key distribution using DNS

[Simon Josefsson <simon+keydist@josefsson.org>]

Keith Moore <moore@cs.utk.edu> writes:

> The RESCAP working group is working on the design of a protocol to
> be used to allow the lookup of meta-information that is associated
> with resource identifiers such as URIs.  The Resource Catalog (RC)
> protocol is being considered for this protocol.
>
> Basically RC assumes that there is some well-defined process for
> mapping a URI to one or more servers that can perform the lookup.
> The server is probably identified using a a NAPTR/SRV lookup mechanism
> similar to that defined in RFC 2168 and RFC 2915.  (in particular,
> NAPTR allows this process to be adaptable to the variety of URI
> syntaxes in use).
>
> The RC protocol itself is specifically designed to allow the client
> to request named metadata that are associated with a resource name.
> Arbitrary sets of metadata can be requested, and the kinds of metadata
> that can be associated with a resource name are arbitrarily extensible
> without changes to the RC servers.  The RC protocol provides its own
> mechanisms for signing arbitrary sets of metadata without constraining
> the signature formats that can be used.  Both the metadata and the
> signatures are opaque to the RC server.
>
> Distribution of key material is one of many applications for which RC
> was designed.  But especially since I'm not a security expert, it's
> entirely possible that there is some aspect of RC's design that
> is deficient for this purpose.  I'd very much appreciate comments
> from this group on the suitability of RC for this application.

From browsing the specification, it seems as it has the same problems
that using SRV records to find LDAP servers that hold keying material
has -- this problem has been explained a few times [1], but a short
recap: The problem is that there is no (secure) coupling between the
hostname (or URI in the case of RESCAP) and the keying material
eventually looked up.

Also, I do not see how RESCAP could be used to find keying material
given the following statement about RESCAP's security scope.  It seems
as if RESCAP's purpose is to look up auxilliary and non-security
critical information only.

  RC does not attempt to ameliorate the following threats:

  -  Attempts to direct clients to send queries to unauthorized servers

     Even if unauthorized servers contain data which are signed by
     authoritative sources, the data provided by unauthorized servers
     may be stale or obsolete.

     When DNS SRV and address records are used to direct queries to RC
     servers, DNSSEC may be useful in authenticating such records to
     clients.

     NOTE: TLS server certificates could be used by the client to
     determine whether the server can authentically claim to operate on
     behalf of a particular DNS name.  However, authority to operate on
     behalf of a DNS name does not necessarily imply authority to supply
     information about a resource name, particularly when the server
     operator may not be authoritative to make assertions about a
     particular resource, even if the server is the correct one to
     consult for information about that resource.  (e.g. the RC service
     might be outsourced)

[1] http://www.cafax.se/keydist/maillist/2001-12/msg00022.html