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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Fri, 27 February 2009 06:55 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 8F0653A67F3 for <saag@core3.amsl.com>; Thu, 26 Feb 2009 22:55:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 UW4RGOw06XWw for <saag@core3.amsl.com>; Thu, 26 Feb 2009 22:55:57 -0800 (PST)
Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by core3.amsl.com (Postfix) with ESMTP id CE9E33A67A5 for <saag@ietf.org>; Thu, 26 Feb 2009 22:55:55 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 19D6A4820C4; Fri, 27 Feb 2009 19:56:17 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBml8J5sFjCi; Fri, 27 Feb 2009 19:56:16 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 8199E481B21; Fri, 27 Feb 2009 19:56:16 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 92D891DE4001; Fri, 27 Feb 2009 19:56:12 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <pgut001@wintermute01.cs.auckland.ac.nz>) id 1Lcwdo-0006dv-ES; Fri, 27 Feb 2009 19:56:12 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Nicolas.Williams@sun.com, sommerfeld@sun.com
In-Reply-To: <20090226165448.GK9992@Sun.COM>
Message-Id: <E1Lcwdo-0006dv-ES@wintermute01.cs.auckland.ac.nz>
Sender: pgut001 <pgut001@cs.auckland.ac.nz>
Date: Fri, 27 Feb 2009 19:56:12 +1300
Cc: 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: Fri, 27 Feb 2009 06:55:58 -0000

Nicolas Williams <Nicolas.Williams@sun.com> writes:

>What we need is something like DIGEST-MD5, but tied into browser apps in a
>different way than DIGEST-MD5 is today (more on this below).  Given this we
>can forego PKI -- just do channel binding to TLS (with or without server
>certs, whether CA-issued or self-signed).

We already have this, and have had for some years, it's called TLS-PSK.
Unfortunately the browser vendors' approach is to keep on waiting for PKI to
start working, forever if necessary.  "PKI meurt, elle ne se rend pas!" [0].

Peter.

[0] Hat tip to Luther Martin for the quote :-).