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

You are right.  The distinction is between trusting the key and
trusting the coupling between the name and the key.  The first does
not follow from the latter.

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

I agree with this, but still believe there is value in retrieving the
keys from DNS [possibly only using a referral stored in DNS, and using
RESCAP or something else to actually retrieve the key] protected with
DNSSEC.  The point is that while it is possible to spoof the data in
DNS due to lazy or incompetent administrators, and even have it be
signed with DNSSEC, this is more difficult than creating Joe's CA and
signing a certificate used for TLS, which doesn't take any effort at
all.

Since there isn't absolute trust, one must add whatever reasonable
counter-measures are easily available.  Moving from unsecured public
keys to public keys secured by DNSSEC is worthwhile, as it doesn't
require any protocol-level changes to DNS.  Especially since it allows
for distribution of PKIX certs and TSIG protected distribution of
application keys as well, which doesn't have the problems discussed
here.

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

Yes.  (Or, did you mean SRV+A+SIG?  That does not, in general, provide
a strong coupling between the owner name and the key received from the
server pointed to by the SRV record.)