Re: [secdir] [TLS] secdir review of

Nicolas Williams <Nicolas.Williams@oracle.com> Sat, 25 September 2010 04:21 UTC

Return-Path: <Nicolas.Williams@oracle.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82D173A68BB; Fri, 24 Sep 2010 21:21:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.399
X-Spam-Level:
X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCGswl0JCHub; Fri, 24 Sep 2010 21:21:54 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 78EAF3A6886; Fri, 24 Sep 2010 21:21:54 -0700 (PDT)
Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o8P4MNCh031176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 25 Sep 2010 04:22:24 GMT
Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o8ONQ7iA028003; Sat, 25 Sep 2010 04:22:23 GMT
Received: from abhmt004.oracle.com by acsmt354.oracle.com with ESMTP id 629328651285388542; Fri, 24 Sep 2010 21:22:22 -0700
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 24 Sep 2010 21:22:22 -0700
Date: Fri, 24 Sep 2010 23:22:17 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Robert Relyea <rrelyea@redhat.com>
Message-ID: <20100925042217.GI9501@oracle.com>
References: <201009242029.o8OKTqcc023470@fs4113.wdf.sap.corp> <4C9D1F8E.70608@REDHAT.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4C9D1F8E.70608@REDHAT.COM>
User-Agent: Mutt/1.5.20 (2010-03-02)
Cc: mrex@sap.com, secdir@ietf.org, certid@ietf.org, iesg@ietf.org, barryleiba@computer.org, tls@ietf.org
Subject: Re: [secdir] [TLS] secdir review of
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Sep 2010 04:21:55 -0000

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