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

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

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

that's fine with me.

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

I don't think it's quite out of scope - because absent a very clear
applicability statement and recommendations about how to use this 
technology sanely, it seems very likely that the technology will
be misused, and security will suffer as a result.

"security with zero configuration" would be a tempting goal, especially
to marketing folks who quite frequently manage to overrride reason. 
but it's the equivalent of Jeff's magic pixie dust.

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

I agree that a mechanism that doesn't assume that they are the same 
would be more flexible than one that does.  I see two scenarios for 
DNS-based authentication of rescap data:

1. the party that signs data in rescap is the same as the party signing
   the DNS zone that refers the domain to the rescap server.

   in this case, it might be reasonable to use the same key for both.  
   but I don't expect this to be a common case.

2. the party that signs the DNS zone that refers a domain to a rescap
   server also signs one or more certificates, each containing the
   public key of a party that signs rescap data.  

   afaik, such certificates could use the same key as was used to sign 
   the DNS zone.

   such certificates could be conveyed to the client by either rescap 
   or DNS (or both), but rescap places fewer constraints on the cert
   format.

   any of the parties who signed rescap data and whose certs were  
   also signed by the owner of that dns zone could also have additional
   certs asserting the identity of the signer by other trust paths;
   such certs could also be made available by rescap.

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

I agree with that statement.  But is DNSSEC so crippled that the only way 
to accomplish this is to shoehorn the fingerprint into the NAPTR record?

Keith