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

Jeffrey Hutzelman <jhutz@cmu.edu> Wed, 25 February 2009 16:29 UTC

Return-Path: <jhutz@cmu.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 CD8FE3A6AEC for <saag@core3.amsl.com>; Wed, 25 Feb 2009 08:29:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.09
X-Spam-Level:
X-Spam-Status: No, score=-6.09 tagged_above=-999 required=5 tests=[AWL=0.509, 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 Z+4osSfzVGDR for <saag@core3.amsl.com>; Wed, 25 Feb 2009 08:29:17 -0800 (PST)
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id C2CFE3A67B5 for <saag@ietf.org>; Wed, 25 Feb 2009 08:29:17 -0800 (PST)
Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n1PGTUaj021101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Feb 2009 11:29:32 -0500 (EST)
Date: Wed, 25 Feb 2009 11:29:30 -0500
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>, Stephen Kent <kent@bbn.com>, saag@ietf.org
Message-ID: <5A6509457B6F0F71878AA5D2@atlantis.pc.cs.cmu.edu>
In-Reply-To: <200902231914.n1NJEDA3011916@raisinbran.srv.cs.cmu.edu>
References: <p06240802c5c5c22d92f0@[128.89.89.88]> <200902231914.n1NJEDA3011916@raisinbran.srv.cs.cmu.edu>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
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, 25 Feb 2009 16:29:18 -0000

--On Monday, February 23, 2009 11:13:55 AM -0800 "Hallam-Baker, Phillip" 
<pbaker@verisign.com> wrote:

> Let us see, I suggest that we might need to slay a sacred PKIX cow or two
> in order to make the SHA-n transition work. Stephen:
> * Describes the suggestion as 'offensive'

Yes, this sort of crack is offensive and counterproductive.  Knock it off.

If you have a proposal to make, then fine, make it.
Don't start off by deliberately attacking people who you think will oppose 
your proposal, on the basis of arguments that haven't yet been made and 
probably won't be.  _That_ is offensive.

So, by the way, is the "sacred cow" comparsion, to some folks.


Your actual proposal makes a number of very large assumptions, such as...


- that interactive Web browsers with access to stable storage and
  nearly-continuous access to the connected Internet are the only
  problem worth solving.

  Possibly true for your company, and other CA's, and browser vendors.
  Definitely _not_ true for the IETF.

- that because certain conditions hold now, they always will

  Definitely not true for anyone, outside of an extremely tightly
  controlled environment, and maybe not even then.

- that it is OK for browser software to silently make configuration
  changes based on external stimulus and without the user's consent.

  This is definitely not true, and will actively screw people if the
  browser vendors ever implement your proposal.  Suppose you distribute
  your so-called "suicide note", causing my browser to reconfigure itself
  (silently and without my consent) to disallow SHA-1.  Unfortunately,
  my entire enterprise PKI was based on SHA-1 certificates, and you have
  just thrown my organization into chaos, potentially costing billions
  of dollars.  Can you imagine the lawsuits when Microsoft does this to
  a major financial institution?  Can you imagine the economic impact
  when Microsoft does this to _every_ major financial institution?


-- Jeff