IETF Logo Mail Archive

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

"Hallam-Baker, Phillip" <pbaker@verisign.com> Thu, 26 February 2009 16:08 UTC

Return-Path: <pbaker@verisign.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 86B5928C1F4 for <saag@core3.amsl.com>; Thu, 26 Feb 2009 08:08:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.435
X-Spam-Level:
X-Spam-Status: No, score=-5.435 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 z3OKq1s3vDpL for <saag@core3.amsl.com>; Thu, 26 Feb 2009 08:08:30 -0800 (PST)
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id 0E3113A69F5 for <saag@ietf.org>; Thu, 26 Feb 2009 08:08:29 -0800 (PST)
Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n1QG8oN5021999; Thu, 26 Feb 2009 08:08:50 -0800
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Feb 2009 08:08:50 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9982C.829E479A"
Date: Thu, 26 Feb 2009 08:05:37 -0800
Message-ID: <2788466ED3E31C418E9ACC5C3166155768B2D6@mou1wnexmb09.vcorp.ad.vrsn.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [saag] SHA-1 to SHA-n transition
Thread-Index: AcmYKy4+CGCwq+rESwGOOBJffP4v2QAAOHlO
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>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: Bill Sommerfeld <sommerfeld@sun.com>, Theodore Tso <tytso@mit.edu>
X-OriginalArrivalTime: 26 Feb 2009 16:08:50.0169 (UTC) FILETIME=[83111E90:01C9982C]
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 16:08:35 -0000

The need to test code paths is a really good point.
 
It might mean that we would want to avoid a hard-switchover.
 
But then it is hard to create a soft landing.

________________________________

From: Bill Sommerfeld [mailto:sommerfeld@sun.com]
Sent: Thu 2/26/2009 10:58 AM
To: Theodore Tso
Cc: Hallam-Baker, Phillip; der Mouse; saag@ietf.org
Subject: Re: [saag] SHA-1 to SHA-n transition




On Thu, 2009-02-26 at 09:38 -0500, Theodore Tso wrote:

> There are couple of things we need to do in order to successfully
> carry off a migration:
>
> (1) ...
> (2) ...
> (3) Once (1) and (2) are done, <deploy certs using sha-n>

So, that sort of transition plan is doomed.  (1) and (2) will never be
"done" because there will always be sites and clients running old
software.

What's more, software which has not been tested does not work.  We don't
know until we start trying to deploy sha-n certs on a wide scale if we
got all the details right, and if we got something wrong and have to
tweak the browsers again...

IMHO we need a transition plan which allows websites to deploy with
sha-n certs in parallel to sha-1 certs from day 1 (and, if I dare
mention it, we need to find some way to do this without making them pay
a bunch of nuisance fees to CA operators).

That way the hard part of the transition plan looks more like:

 n) release software which expects sha-n and considers sha-1 an
exceptional case.

and the triggering event for this can be somewhat more flexible.  It may
still happen shortly after a "cnn moment", but which would be a much
more graceful transition than if we had to throw the switch starting
today.

v2.23.0 | Report a Bug | By Email