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

Eric Rescorla <ekr@networkresonance.com> Mon, 02 March 2009 21:49 UTC

Return-Path: <ekr@networkresonance.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 07E563A67EC for <saag@core3.amsl.com>; Mon, 2 Mar 2009 13:49:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.541
X-Spam-Level:
X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599]
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 fQMl24nsVH2p for <saag@core3.amsl.com>; Mon, 2 Mar 2009 13:49:51 -0800 (PST)
Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 3EB0E3A67D0 for <saag@ietf.org>; Mon, 2 Mar 2009 13:49:51 -0800 (PST)
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 5368850823; Mon, 2 Mar 2009 14:13:08 -0800 (PST)
Date: Mon, 02 Mar 2009 14:13:08 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: Nicolas Williams <Nicolas.Williams@sun.com>
In-Reply-To: <20090302171646.GN9992@Sun.COM>
References: <20090226165448.GK9992@Sun.COM> <E1Lcwdo-0006dv-ES@wintermute01.cs.auckland.ac.nz> <20090302171646.GN9992@Sun.COM>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20090302221308.5368850823@romeo.rtfm.com>
Cc: saag@ietf.org, mouse@Rodents-Montreal.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 21:49:52 -0000

At Mon, 2 Mar 2009 11:16:47 -0600,
Nicolas Williams wrote:
> 
> 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.

That's because there are already well-known mechanisms for
deriving keys from passwords, as long as you're willing to
live with low entropy. See PKCS#5.


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

Huh?

At a high level, if what you want is an authentication mechanism
derived form a password, there are only two sets of technical
mechanisms:

- Symmetric-key based systems like TLS-PSK, CRAM-MD5, Digest, etc.
- ZKPP/PAKE systems such as SRP, EKE, etc.

All the protocols in the former class have dictionary attacks on
the password. The protocols in the latter class do not.
TLS-PSK does not explicitly provide for passwords because
we did not want to encourage the use of mechanisms which we
knew were subject to offline dictionary attacks. This is a policy
question, not a technical one. The technical problem is easily
solved by specifying a mechanism to derive a shared key from a
a password (e.g., PBKDF2). The credentials are quite portable.

-Ekr