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

[Derek Atkins <warlord@MIT.EDU>]

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

> >   1. (Mine) We have to be able to establish a security chain from the DNS
> >      root to the application data, 
> 
> agree with this part...
> 
> >      such that a client which starts out
> >      knowing only the public key of the DNS root can securely associate
> >      application data with DNS names.
> 
> ...  but it doesn't imply the second part.  no client should axiomatically
> trust "the public key of the DNS root" - that's investing far too much
> trust in one organization.  it would be completely irresponsible for
> IETF to recommend that clients invest such trust.  
> 
> nor does trust in the root (or any zone) imply that the zones under 
> it should be trusted.
> 
> instead, clients need to be configurable as to which public keys they
> trust, and for what purposes.  there's no getting around this.

I belive Greg's statement meant that "a client which starts out
knowing only the public key of the DNS root MUST be able to form a
signature chain from that root key to application data with DNS
names."

There is no implied measure of trust in the contents of that
application data, nor whether the client has other trust entry points
to use.  The only statement was that if the client is configured to
trust the DNS root axiomatically, the MUST be able to do so.  The
client can just as easily be configured not to trust the DNS root
axiomatically, and that is fine too, but how a client would gain trust
in that situation is, IMHO, out of scope of this work.

> >   2. (Mine) We can't use the same key to sign DNS and non-DNS data.  (That
> >      is, if a private key is accessible to whoever signs a DNS zone, it
> >      shouldn't also be accessible to whoever signs a RESCAP data set or
> >      whatever.)
> 
> just curious, why do you say this?  as long as the signatures are made by 
> the same party, why shouldn't the same private key be used?

Well, for one thing, the signatures may NOT be made by the same party.
So you should not assume the keys are the same.  That does not imply
that they MUST be different, (they MAY), however, you MUST NOT assume
that they are the same.

> >   3. (Keith's) We can't have any keys or key fingerprints in DNS except
> >      for the KEY records which protect DNS data.
> 
> that's not what I said.  
> 
> I don't claim to know enough about DNSSEC to specify exactly how the
> keys or fingerprints should be stored, but I do know enough about NAPTR 
> to know that they don't belong there.

Unfortunately I happen to agree with Greg in that if you are going to
lookup a NAPTR to find the location of a service you should also get a
signed hint about the key to use to authenticate the service.  That
signed hint MUST be signed by DNSSec (and MAY be signed by other
authorities).

> Keith

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available