Re: From whence we came...

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

Derek Atkins wrote:
> Steve Hanna <steve.hanna@sun.com> writes:
> 
> > That's certainly not what I intended.
> 
> It did come across that way.

Sorry.

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

You're probably right that it will be more work to modify SSH to
use certificates than to change it to use DNS. But I don't think
it's a huge difference. And I think that we should not base such a
decision on minor differences in ease of implementation. I've been
down that path before!

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

You see if you can build and validate a path from one of your
trust anchors. If not, you don't trust the cert.

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

Agreed. A self-signed cert adds no value in that case.

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

I don't think so. I have seen several comments like this:

  I used to be for using DNS, but now am unsure.

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

Fine. Can we settle the matter of keys vs. certs first? Edward
sent out a good list of FOR and AGAINST earlier in the week.

-Steve