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

Theodore Tso <tytso@mit.edu> Thu, 26 February 2009 14:38 UTC

Return-Path: <tytso@mit.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 78A9E28C2E3 for <saag@core3.amsl.com>; Thu, 26 Feb 2009 06:38:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.741
X-Spam-Level:
X-Spam-Status: No, score=-1.741 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, IP_NOT_FRIENDLY=0.334]
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 xgGR+qZwU0go for <saag@core3.amsl.com>; Thu, 26 Feb 2009 06:38:04 -0800 (PST)
Received: from thunker.thunk.org (THUNK.ORG [69.25.196.29]) by core3.amsl.com (Postfix) with ESMTP id 0289428C2E2 for <saag@ietf.org>; Thu, 26 Feb 2009 06:37:53 -0800 (PST)
Received: from root (helo=closure.thunk.org) by thunker.thunk.org with local-esmtp (Exim 4.50 #1 (Debian)) id 1LchNL-0007nm-Cg; Thu, 26 Feb 2009 09:38:11 -0500
Received: from tytso by closure.thunk.org with local (Exim 4.69) (envelope-from <tytso@mit.edu>) id 1LchNJ-0003Za-Sb; Thu, 26 Feb 2009 09:38:09 -0500
Date: Thu, 26 Feb 2009 09:38:09 -0500
From: Theodore Tso <tytso@mit.edu>
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
Message-ID: <20090226143809.GF7227@mit.edu>
References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tytso@mit.edu
X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false
Cc: der Mouse <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: Thu, 26 Feb 2009 14:38:05 -0000

On Wed, Feb 25, 2009 at 05:35:04PM -0800, Hallam-Baker, Phillip wrote:
>  
> If people really think that Amazon.com is going to say 'I know that
> only 95% of browsers support SHA1, but I am going to get an SHA2
> cert and lose that 5% of sales so that our transactions are as
> secure as possible' because someone finds a practical attack on
> SHA1, then let them say that. So far nobody has challenged the
> analysis directly, they have merely described themselves as
> unconvinced that there is a problem.
>  

OK, so let's get real here.  The reality is that transitioning between
crypto algorithms is *hard*, and that the tragedy of the commons is
hitting us hard.  We can try to create technical solutions (such as
the Svengali-style suicide note which causes browsers to break
intranets), but their have shortcomings because this is fundamentally
a social problem.

There are couple of things we need to do in order to successfully
carry off a migration:

(1) We need to get browsers to add support for the new crypto algorithm
(2) We need to get users to upgrade to the new browsers with support
	for the new crypto algorithm
(3) Once (1) and (2) are done, we need to get secure commerce sites to
	upgrade to use certificates that utilize the new crypto algorithm.
	(In practice this will be the crypto checksum; but the same thing
	applies if we ever need to get nervous about replacing the PK
	algorithm.)

This normally takes time --- years, but it is possible to speed things
up.  For example, an interested body, perhaps funded by far-sighted
merchants and other concerned citizens, could track which browsers
have added the new algorithms, and jawbone (and perhaps in the later
part of the effort, publically shame) entities distributing browsers
to implement the new algorithm.

For (2), sites who were interested in being "good citizens" could test
to see if the browser supports the new crypto algorithm, and display a
"nag screen" if the browser apparently doesn't support the new crypto
algorithm.  Said nag message could be gentle at first, but could get
increasingly strident; a lot of this would be up to the web site(s)
involved, of course.

So it's possible to encourage the ecosystem to move in a particular
way, but it all requires effort and coordination, and the tragedy of
the commons is that until the emergency comes up, it's unlikely that
such an effort will get funding and support.  

But again, this is all nothing new, and I suspect one of the reasons
why we're thrashing a little in this discussion is because it really
is much more of a social problem than a technical problem, which means
it's a bit outside of the IETF's core competency.

					- Ted