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

Jeffrey Hutzelman <jhutz@cmu.edu> Mon, 02 March 2009 18:18 UTC

Return-Path: <jhutz@cmu.edu>
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 C3E1728C13E for <saag@core3.amsl.com>; Mon, 2 Mar 2009 10:18:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.338
X-Spam-Level:
X-Spam-Status: No, score=-6.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, 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 NewkVZIYsf3A for <saag@core3.amsl.com>; Mon, 2 Mar 2009 10:18:50 -0800 (PST)
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id DBDB43A659C for <saag@ietf.org>; Mon, 2 Mar 2009 10:18:49 -0800 (PST)
Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n22IJDk5008421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2009 13:19:14 -0500 (EST)
Date: Mon, 02 Mar 2009 13:19:13 -0500
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Nicolas Williams <Nicolas.Williams@sun.com>, Eric Rescorla <ekr@networkresonance.com>
Message-ID: <864C82388E530D27DCB6002F@minbar.fac.cs.cmu.edu>
In-Reply-To: <200903021720.n22HKZOv006388@grapenut.srv.cs.cmu.edu>
References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@Sun.COM> <20090227022359.8D45150822@romeo.rtfm.com> <20090302161134.GG9992@Sun.COM> <20090302172135.DA43650822@romeo.rtfm.com> <200903021720.n22HKZOv006388@grapenut.srv.cs.cmu.edu>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Cc: saag@ietf.org, der Mouse <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 18:18:50 -0000

--On Monday, March 02, 2009 11:11:22 AM -0600 Nicolas Williams 
<Nicolas.Williams@sun.com> wrote:

> It will be a long time before users can be trained not to type passwords
> into attacker-controlled dialogs -- that is definitely true.

No, no.  It's a long way down the road to the chemist's.  It will be 
_forever_ before users can be trained not to type passwords into 
attacker-controlled dialogs.  We've been trying for decades, and some of 
the users in question have _been here_ for decades, and the message still 
hasn't gotten through.

> And we'll
> also have passwords for a long time yet.

Again, probably forever.


> DIGEST-MD5 exists, and I'd advocate its use, but currently that always
> results in a browser-controlled dialog that app designers hate

To a certain extent, this is too bad.  For password dialogs to be safe, 
they _must_ be browser-controlled (or system-controlled) dialogs over which 
the app designers have no control.  Note that virtually all of the security 
problems the web has today result from app designers demanding and browser 
vendors granting more control over the client computer than the system was 
designed to give them.

Just for the record, the amount of control the system was designed to give 
app designers over the client computer is.... zero!  Every security, 
performance, and usability problem the Web has today can be traced to 
violations of that design principle.

-- Jeff