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

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

> > Since people seem to be interested in using DNS to distribute keying
> > material, I thought I'd suggest a (somewhat) concrete alternative.
> 
> I'm becoming a little frustrated by the argument that goes:
> 
>   1. People shouldn't axiomatically trust DNSSEC.
>   2. ???
>   3. Therefore, we should use this other method which precludes using
>      a DNSSEC signature chain to verify application keys.
> 
> where "this other method" is usually a SRV or NAPTR referral to some
> other protocol.  How do people go from "not axiomatically" to "never?"

sorry, not my intention at all.  I thought I'd said repeatedly that 
DNSSEC can be useful as part of *a* method of establishing trust in
keys that are made available via external servers, and I thought I'd
already agreed that DNS+DNSSEC can be used as one way to distribute 
keys without an external server.  (though I think it has some fairly 
severe limitations for this).

The parts that bug me are the ideas that (a) DNSSEC should be trusted
axiomatically, and (b) DNS makes a good sole method of key distribution.
 
> (I am perfectly happy with a referral to another protocol, as long as
> that referral includes something--even something as small as a key
> fingerprint--which can allow DNSSEC trust to be chained onto application
> keys.  Just in case people decide, not axiomatically, that they want to
> trust that, or to use it for additional verification.  I believe a key
> fingerprint can be shoehorned into NAPTR with the definition of a new
> flag.)

seems quite reasonable to me, with the possible exception of shoehorning
a key fingerprint onto NAPTR.  But you can certainly store material in
RESCAP which allows it to be securely tied to DNSSEC.

Keith