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

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

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

>> 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.
>
> Server certificates used in SSL don't have a secure coupling either.

Exactly, that is one use of DNSSEC.

> Trust in an SSL cert requires trust in the CA that signed the cert.
> If the client has reason to trust the CA for that purpose, this is 
> perfectly satisfactory; if the client doesn't trust the CA, then the
> cert does not establish the identity of the server to the 
> satisfaction of the client.

One of the things I'd like to see solved here is "opportunistic"
encryption a'la the IPSEC draft, but in general.  I especially would
like to see it for email.  This is where you talk to some random
host/person and want encryption to happen. The traditional PKIX model
doesn't handle this -- you cannot assume that everyone knows the
public key of the CA you use (let alone trust it).  You can't even
assume that everyone is able to locate (via LDAP) the public key of
other person.  However, storing KEY's in DNS, protected with DNSSEC,
might achieve this.

> The same would be true of DNSSEC - the fact that a DNS RR was signed
> using DNSSEC does not axiomatically mean that the client should consider
> that signature trustworthy.  It depends on whether the client trusts
> the chain of authorities that validate that signature for the particular
> purpose the client has in mind.

Agreed. I am not saying that you should trust a public key coming from
DNS because of DNSSEC.  But you _can_ trust what the origins of the
public key are with DNSSEC.  That is the purpose of DNSSEC. For some
applications ("opportunistic IPSEC") it is sufficient.  For other
applications, that needs data authentication, it is not sufficient,
they need PKIX or similar.

> You can think of RESCAP as a fancy and more flexible DNS-like service.
> A SRV RR pointing to a RESCAP server is no less secure than an 
> NS RR pointing to a DNS server.  Either RR could be signed by DNSSEC, 
> but that doesn't necessarily provide a "secure coupling" (for the 
> client's purpose) in either case.

Getting A+KEY records from DNS (with DNSSEC) for a host achieves this
secure coupling.  If you do not have anything else in common with the
party you want to communicate with (like trusting a shared CA) this
seem to be as good as you can wish for.  This isn't possible today,
but could be using DNSSEC.