Re: From whence we came...

[Steve Hanna <steve.hanna@sun.com>]

Derek Atkins wrote:
> Steve Hanna <steve.hanna@sun.com> writes:
> > The requirement for a single global trusted root does bother me.
> > That's why I would rather use a PKI, where the user can configure
> > their own set of trust anchors. Most users will be happy with
> > whatever ships with the browser, but people who care can always
> > change it. And administrators who care can change the defaults
> > in the configuration files they distribute with the browser.
> 
> You cannot change the anchors of the DNS Hierarchy, so why would
> you want to change the anchors of key distribution.  One problem
> with multiple trusted roots if that if ANY of them get compromised,
> EVERYONE is bitten.  Have you counted the number of trusted root
> certificates in Netscape or IE lately?  If _any_ of those certs
> is compromised, all users are in trouble.

I agree that having many trusted roots is not good. I'm not
arguing for that. I'm arguing that users should have the ability
to choose their own trust anchors and not be forced into using
a single global trusted root. Many users won't care and they'll
use whatever comes with their software. But users who do care
should be able to choose. I'm surprised to see you arguing against
that.

> Getting back to the DNS issue, you are already trusting the
> DNS to give you a correct response to the A record query.  If
> that fails, all is lost.  Since you already have to trust that,
> why not trust it for keying information as well?

Because DNSSEC locks me into a single global trusted root.
IKE and SSL and S/MIME use certificates to authenticate. If they
get bad information from the DNS (or if somebody is spoofing the
intended recipient's IP address), there's no security risk (except
possible DOS).

> Nothing says that it has to be the _ONLY_ key distribution mechanism.
> And nothing says that you can't use multiple methods at one time.  For
> example, here is how I envision SSH to work when you want to connect
> to a host for the first time:
> 
>  1) you lookup the A and <ApplicationKey> record in DNS for the host
>  2) you get back DNSSec-protected A and <ApplicationKey> records
>  3) you validate the DNS records
>  4) you connect to the IP address
>  5) the peer sends their public key
>  6) you match the key against the key you obtained from DNS
>  6a) if it fails, you warn the user and ask whether to proceed
>  6b) if it matches, you cache the key locally and continue
>  7) proceed with SSH connection

Understood. That makes sense, if we decide to use DNS and DNSSEC
for key distribution.

> > There's no need for everyone to share the same trusted anchor. People
> 
> People already have to share the same trusted anchor for DNS
> information...

But the security of IKE and SSL and S/MIME doesn't depend on the
DNS giving correct answers. Using certificates frees them from the
dependency on a single global trusted root.

-Steve