[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Steve Hanna <steve.hanna@sun.com>
Cc: Greg Hudson <ghudson@MIT.EDU>, Simon Josefsson <simon+keydist@josefsson.org>, keydist@cafax.se
From: Derek Atkins <warlord@MIT.EDU>
Date: 04 Jan 2002 11:07:52 -0500
Delivery-Date: Fri Jan 4 17:07:59 2002
In-Reply-To: Steve Hanna's message of "Thu, 03 Jan 2002 15:59:19 -0500"
Sender: owner-keydist@cafax.se
Subject: Re: From whence we came...

Steve,

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.

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?

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

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

-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

Home | Date list | Subject list