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

"Hallam-Baker, Phillip" <pbaker@verisign.com> Wed, 04 March 2009 18:34 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 6D0B428C172 for <saag@core3.amsl.com>; Wed, 4 Mar 2009 10:34:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.242
X-Spam-Level:
X-Spam-Status: No, score=-6.242 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 8JrVNxj+AgMM for <saag@core3.amsl.com>; Wed, 4 Mar 2009 10:34:35 -0800 (PST)
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id 93F5328C123 for <saag@ietf.org>; Wed, 4 Mar 2009 10:34:35 -0800 (PST)
Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n24IYw9h005331; Wed, 4 Mar 2009 10:34:58 -0800
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 10:34:59 -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_01C99CF7.EB5D2CC2"
Date: Wed, 04 Mar 2009 10:34:57 -0800
Message-ID: <2788466ED3E31C418E9ACC5C3166155768B2FA@mou1wnexmb09.vcorp.ad.vrsn.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [saag] SHA-1 to SHA-n transition
Thread-Index: Acmc5sctBEbpTWrTQrasOfazvo7AxgAD9Y7Q
References: <E1Lekmy-0001Zx-KD@wintermute01.cs.auckland.ac.nz> <2788466ED3E31C418E9ACC5C3166155768B2F7@mou1wnexmb09.vcorp.ad.vrsn.com> <1A3A77AE3B3614022A6C60C3@atlantis.pc.cs.cmu.edu>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: Jeffrey Hutzelman <jhutz@cmu.edu>, Peter Gutmann <pgut001@cs.auckland.ac.nz>, saag@ietf.org
X-OriginalArrivalTime: 04 Mar 2009 18:34:59.0007 (UTC) FILETIME=[EC2E1CF0:01C99CF7]
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: Wed, 04 Mar 2009 18:34:36 -0000

Thanks Jeff.

At this point I think that it is clear that we can solve this problem, albeit with solutions that are somewhat 'yukky'. The most important questions in my mind are:

* Is the deployment deadlock problem real?
* Is the problem significant enough to add a barnacle to SSL or PKIX?

The problem with barnacles is not the individual barnacle, its the fact that they accumulate and eventually slow the ship down. I don't see the 'yuk' factor as being trivial. On the other hand a deployment deadlock on SHA-n makes me nervous.


-----Original Message-----
From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu]
Sent: Wed 3/4/2009 11:32 AM
To: Hallam-Baker, Phillip; Peter Gutmann; saag@ietf.org
Cc: jhutz@cmu.edu
Subject: RE: [saag] SHA-1 to SHA-n transition
 
--On Wednesday, March 04, 2009 05:34:43 AM -0800 "Hallam-Baker, Phillip" 
<pbaker@verisign.com> wrote:

> We are now into the identity issue which has precisley nothing to do with
> algorithm transitions.

Thanks for bringing us back around to the original point.  I'm not sure how 
we got into talking about identity and user credentials, but I seem to 
recall this thread started with a discussion of hash algorithm transition, 
and rather quickly moved away from that topic without any real resolution. 
Can we perhaps get back to discussing a technical problem we can solve, 
instead of one that is outside our expertise?

-- Jeff