Re: [keyassure] Opening issue #21: "Need to specify which crypto

Peter Gutmann <pgut001@cs.auckland.ac.nz> Fri, 04 March 2011 01:18 UTC

Return-Path: <pgut001@login01.cs.auckland.ac.nz>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1C463A683F for <keyassure@core3.amsl.com>; Thu, 3 Mar 2011 17:18:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.594
X-Spam-Level:
X-Spam-Status: No, score=-103.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 pAUiYG1-sCtT for <keyassure@core3.amsl.com>; Thu, 3 Mar 2011 17:18:41 -0800 (PST)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id A1A0F3A6814 for <keyassure@ietf.org>; Thu, 3 Mar 2011 17:18:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1299201591; x=1330737591; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<pgut001@cs.auckland.ac.nz> |To:=20hallam@gmail.com,=20paul.hoffman@vpnc.org|Subject: =20Re:=20[keyassure]=20Opening=20issue=20#21:=20"Need=20t o=20specify=20which=20crypto|Cc:=20keyassure@ietf.org |In-Reply-To:=20<AANLkTi=3DgzGr9qiP0mF-FGqhQnv5n1iyVZU1Ch 12JK=3Dou@mail.gmail.com>|Message-Id:=20<E1PvJgK-0003AF-0 4@login01.fos.auckland.ac.nz>|Date:=20Fri,=2004=20Mar=202 011=2014:19:48=20+1300; bh=kNvNZ1wwmZr0Uq7329hAo/KBUYsGz/MIl6a13iWmpNw=; b=NJ3IqrV9T0KJIJ902nio/UXeqyc72RRCE/mLO2gRP0b1o9wLzCxj3Lws 4FX0xzglSRmJBKjZ4gYAMYGhFpnMxKHjVHMKwAJAWKJsJ4uZ1rCL1O38f lbrO69hPuU26nYYbVlMdM775Drk4dq2UMG5aV747htH4MFIhTxPPqsunf M=;
X-IronPort-AV: E=Sophos;i="4.62,261,1296990000"; d="scan'208";a="49097943"
X-Ironport-HAT: APP-SERVERS - $RELAYED
X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing
Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 04 Mar 2011 14:19:48 +1300
Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1PvJgK-0004dp-GM; Fri, 04 Mar 2011 14:19:48 +1300
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1PvJgK-0003AF-04; Fri, 04 Mar 2011 14:19:48 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: hallam@gmail.com, paul.hoffman@vpnc.org
In-Reply-To: <AANLkTi=gzGr9qiP0mF-FGqhQnv5n1iyVZU1Ch12JK=ou@mail.gmail.com>
Message-Id: <E1PvJgK-0003AF-04@login01.fos.auckland.ac.nz>
Date: Fri, 04 Mar 2011 14:19:48 +1300
Cc: keyassure@ietf.org
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyassure>
List-Post: <mailto:keyassure@ietf.org>
List-Help: <mailto:keyassure-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2011 01:18:42 -0000

Paul Hoffman <paul.hoffman@vpnc.org> writes:

>1) Make support for SHA2-256 and SHA2-384 REQUIRED

Why the oddball SHA384, which is just a truncated SHA512?  If SHA256 isn't
enough then use the full SHA512, not some oddball variant.

In any case what we should really be specifying is SHA256 and SHA3.  If SHA256
really isn't cromulent enough for people then SHA384 won't be either, and by
the time this sees significant deployment we'll have SHA3 anyway.  How much
real-world support is there for SHA384?  I've only just seen SHA256 creeping
in here and there, but never SHA384.  Again, by the time there's even single-
digit deployment of SHA384 (if there ever is), we'll have SHA3 ready to go.

Peter.