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

Eric Rescorla <ekr@networkresonance.com> Mon, 02 March 2009 16:58 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 EC24E3A6A71 for <saag@core3.amsl.com>; Mon, 2 Mar 2009 08:58:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Level:
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 VaCelh8tRS74 for <saag@core3.amsl.com>; Mon, 2 Mar 2009 08:58:19 -0800 (PST)
Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 16AF43A6879 for <saag@ietf.org>; Mon, 2 Mar 2009 08:58:19 -0800 (PST)
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id DA43650822; Mon, 2 Mar 2009 09:21:35 -0800 (PST)
Date: Mon, 02 Mar 2009 09:21:35 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: Nicolas Williams <Nicolas.Williams@sun.com>
In-Reply-To: <20090302161134.GG9992@Sun.COM>
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>
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: <20090302172135.DA43650822@romeo.rtfm.com>
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 16:58:20 -0000

At Mon, 2 Mar 2009 10:11:35 -0600,
Nicolas Williams wrote:
> 
> On Thu, Feb 26, 2009 at 06:23:59PM -0800, Eric Rescorla wrote:
> > I don't want to get into an extensive argument about this on SAAG,
> > but I don't think this direction is particularly promising, for
> > reasons I've indicated before: namely that you're handwaving
> > the difficult part of the problem, UI, which we have no real 
> > idea how to solve. Sure, if we solved that, there are any
> > number of things we could do, but absent that, the other things
> > are fairly useless.
> 
> I'm not entirely handwaving the UI part.  There are two major UI
> problems: a) the desire for full-screen apps, and, more generally, apps
> that have full access to human interface I/O, b) the desire of web
> application developers to have full control over credentials prompts.
> 
> (a) is practically insurmountable -- SAS helps, but I doubt users will
> be happy to use SAS every time they are prompted for credentials.  My
> knee-jerk reaction would be to reject full-screen apps.
> 
> In my scheme (b) is solved by letting apps prompt for identities,
> but not any passwords -- and training users not to enter passwords into
> non-secure dialogs (see SAS comment) -- and by having authentication
> mechanisms where the relying party does not get to impersonate the
> client just because the client authenticated itself (this, in turn,
> creates another problem in that lots of web services need delegation).
> 
> In particular I think the solution to (b) needs to go hand-in-hand with
> any solution to the mutual authentication problem.

I would characterize this as handwaving. 

As long as the user's credential provided to their client is a human
readable password (and I think that's pretty clearly an invariant in a
large number of cases), then you have to worry about the user being
conned into typing their password into a dialog box controlled by the
attacker. Seeing as the available evidence suggests that there is
almost no UI chrome that can stop them from doing so, even when the
attacker only controls the ordinary browser interface.

Sure, you can imagine training users not to do that, but since
there's no evidence that you can in fact do so, that seems fairly
speculative.

-Ekr

P.S. I don't see how SAS is at all relevant here. SAS depends on the existence
of a trusted channel to carry the SAS, and that's precisely what we don't
have.