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


To: Steve Hanna <steve.hanna@sun.com>
Cc: Paul Hoffman / IMC <phoffman@imc.org>, keydist@cafax.se
From: Derek Atkins <warlord@MIT.EDU>
Date: 04 Jan 2002 13:53:54 -0500
Delivery-Date: Fri Jan 4 20:03:30 2002
In-Reply-To: Steve Hanna's message of "Fri, 04 Jan 2002 12:59:08 -0500"
Sender: owner-keydist@cafax.se
Subject: Re: From whence we came...

Steve Hanna <steve.hanna@sun.com> writes:

> That's certainly not what I intended.

It did come across that way.

> Let me review where I think we are. SSH uses preconfigured keys.
> You want a more scalable and less error-prone mechanism for securely
> distributing keys. We're discussing various options. The primary
> candidates seem to be:
> 
> 1) storing keys in DNS, authenticated with DNSSEC
> 2) certificates (X.509, PGP, or whatever), stored in DNS
> 3) certificates, exchanged in application protocols
> 4) certificates, stored in some other location (like an LDAP
>    directory)
> 
> I pointed out that one big disadvantage of solution 1) is that
> DNSSEC uses a top-down trust model with a single root. That
> may be OK for DNS, but it's a bummer for many other applications
> (including SSH, I would suggest).
>
> Would you care to discuss the merits of these various options?

The benefit of #1 is that it requires the least changes to
applications.  Changing SSH to use certificates is going to be more
challenging than changing it to use DNS, because the data in DNS can
be stored in the same format as it would be stored in, e.g. a file.
(theoretically).

The question with #2,3,4 is: how do you know that a CA is authoritative
for the domain?  For example, I connect to 18.18.1.138 and I get a
certificate for no-such-host.mit.edu which is signed by joe-poedunk-ca
-- how do I know that joe-poedunk-ca is allowed to sign for mit.edu?

Note that #2 is somewhat special: you could theoretically have a
self-signed certificate stored in DNS that uses the DNSSec security
for binding the certificate to the DNS name.  This is probably both
the best and worst of both worlds.

> BTW, I expect that SSH (and IPsec) will continue to support
> preconfigured keys, no matter what we do. I think that's a
> fine thing, for many environments. It doesn't scale well and
> it's prone to user error, but that's not a big problem for
> a dozen machines with technically savvy administrators.

True, but that is out of scope for this discussion.  I think there
will be multiple key distribution methods, too.

The questions are:
	1) should DNS be used to distribute application keys, and
	2) if yes, what are the requirements?

I think that most people on this list (with the obvious exception of
Randy ;) belive that the answer to #1 is "yes"

Also, note that within question #2 there are a number of un-asked
sub-questions which I think should wait.  I do believe that there are
multiple methods and formats with which keys can be stored, and I
believe that in the end we will have to support them all.  But
that discussion is for another day.

> -Steve

-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