Re: [saag] SHA-1 to SHA-n transition

Nicolas Williams <Nicolas.Williams@sun.com> Mon, 02 March 2009 17:33 UTC

Return-Path: <Nicolas.Williams@sun.com>
X-Original-To: saag@core3.amsl.com
Delivered-To: saag@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58E563A6908 for <saag@core3.amsl.com>; Mon, 2 Mar 2009 09:33:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.993
X-Spam-Level:
X-Spam-Status: No, score=-5.993 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
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 sphsI878hgVY for <saag@core3.amsl.com>; Mon, 2 Mar 2009 09:33:09 -0800 (PST)
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 359613A6902 for <saag@ietf.org>; Mon, 2 Mar 2009 09:32:54 -0800 (PST)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n22HXKpL006940 for <saag@ietf.org>; Mon, 2 Mar 2009 17:33:20 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n22HXJka015704 for <saag@ietf.org>; Mon, 2 Mar 2009 10:33:19 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n22HGlcN012997; Mon, 2 Mar 2009 11:16:47 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n22HGl9K012996; Mon, 2 Mar 2009 11:16:47 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Mon, 02 Mar 2009 11:16:47 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Message-ID: <20090302171646.GN9992@Sun.COM>
References: <20090226165448.GK9992@Sun.COM> <E1Lcwdo-0006dv-ES@wintermute01.cs.auckland.ac.nz>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <E1Lcwdo-0006dv-ES@wintermute01.cs.auckland.ac.nz>
User-Agent: Mutt/1.5.7i
Cc: mouse@Rodents-Montreal.ORG, saag@ietf.org
Subject: Re: [saag] SHA-1 to SHA-n transition
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Mar 2009 17:33:10 -0000

On Fri, Feb 27, 2009 at 07:56:12PM +1300, Peter Gutmann wrote:
> Nicolas Williams <Nicolas.Williams@sun.com> writes:
> 
> >What we need is something like DIGEST-MD5, but tied into browser apps in a
> >different way than DIGEST-MD5 is today (more on this below).  Given this we
> >can forego PKI -- just do channel binding to TLS (with or without server
> >certs, whether CA-issued or self-signed).
> 
> We already have this, and have had for some years, it's called TLS-PSK.

TLS-PSK is not sufficient by itself, and for two reasons:

a) As the RFC says: "[h]owever, this document is not intended for web
   password authentication, but rather for other uses of TLS."

   Thus there is nothing about how to derive PSKs from passwords.

   Now, we could have PSKs bootstrapped by passwords, but that requires
   an enrolment protocol, and the result is non-portable credentials
   (where portable credentials are ones that require no physical devices
   in order to carry, except, perhaps, pen and paper).

b) For any solution to scale that adds mutual authentication we'll need
   either the user to use the same password for all identities or
   federation.

   TLS-PSK does nothing about passwords (see (a)) and nothing about
   federation.

> Unfortunately the browser vendors' approach is to keep on waiting for PKI to
> start working, forever if necessary.  "PKI meurt, elle ne se rend pas!" [0].

Not surpringly given the lack of usable mechanisms for mutual
authentication.

Nico
--