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