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

[Keith Moore <moore@cs.utk.edu>]

> >> 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.

whether that coupling is secure depends on whether you trust it for
your purposes.  but you should not axiomatically trust a key from 
DNSSEC, even if you can verify the signatures all the way down 
from the root.  you need to evaluate whether you think each of 
those keys is trustworthy for your particular purpose.

> 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.  

Protocol support for opportunistic encryption exists for email, using 
EHLO/STARTSSL.  Whether you can *trust* the message to be encrypted
is a different question, and again, it depends on whether you can trust
the chain of certificates or keys that establish the identity of the
SMTP server and assocaite that server with the recipient.  The questions
you have to ask about those certs/keys are the same regardless of whether 
those certs/keys are obtained via DNSSEC or by some other means.

Bottom line: there's no substitute for having explicit configuration
of trust parameters.  There is nothing magic about DNSSEC that allows
you to invest more trust in a DNSSEC key than in any other key or cert
provided by the same party, or to trust that the signing party is who 
it says it is.  About the only thing that DNSSEC provides is that the
trust is delegated along the same lines as the DNS name delegation.  
Presumably the X.Y.Z zone has been granted that zone by the Y.Z zone
and has some business relationship with the maintainer of the Y.Z zone,
so this relationship might also be used to establish trust. But being 
trustworthy in a general sense is *very* difficult, perhaps not even
feasible.  Most zone maintainers (including the TLDs) are clearly not 
up to the job.

> > 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.  

No you cannot, at least, not as an axiom.  For instance, of the higher
private keys might have been compromised.  And even if you can trust
the origin of a public key, you have no assurance that the associated
private key has not been compromised either.

> > 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 that were true, it would be equally true of SRV+A+KEY records.

> 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.  

perhaps.  and I don't disagree that DNSSEC is useful.  I'm just
saying that it cannot be axiomatically trusted - that we need the 
potential to use other mechanisms and to configure which mechanisms
and which keys/certs we trust for which purposes.

Keith