[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] [secdir] secdir review of
From:       Nicolas Williams <Nicolas.Williams () oracle ! com>
Date:       2010-09-25 4:22:17
Message-ID: 20100925042217.GI9501 () oracle ! com
[Download RAW message or body]

On Fri, Sep 24, 2010 at 03:00:46PM -0700, Robert Relyea wrote:
> SSH is good for small numbers of point to point connections where the
> user controls both sides. SSH model is not appropriate for the general
> population connection to millions of webservers. That is why SSH is used
> extensively in admin deployments (where the admin controls both
> machines) and is not used for e-commerce. If you want that semantic use
> SSH. If you want security for the masses, use SSL (with full PKI).

It shall not surprise anyone that I don't quite agree with the above.
That is, I agree with the part about the pre-shared public keys (ssh
known_hosts files) not scaling (not even to a corporate network), and
the part about ssh leap-of-faith not being a great model (though you
were not that specific).  In particular, what PKI is this that you speak
of?  The PKI we have is not really.  Even leap-of-faith is better than
the "PKI" we have now.

The PKI we will have (DNSSEC) (one hopes) won't be a joke.  But even a
true PKI, with one root (or one root per-country or region of the world)
is not quite what we need -- though it just might well do well enough.

I would much prefer federated authentication mechanisms + channel
binding to TLS -- TLS is the secure transport that we have for HTTP, and
TLS is a decent enough secure transport, if you don't care about
authentication.  Yes, a combination of "PKI" (and "stickiness") may well
be part of how federated authentication mechanisms work, but even so,
the impact of "PKI" on the user agent and UIs would be minimized, and
that'd be a very good thing.

Nico
-- 

[prev in list] [next in list] [prev in thread] [next in thread]