Re: [Cfrg] [saag] [Fwd: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt]

"Dan Harkins" <dharkins@lounge.org> Mon, 04 October 2010 17:50 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: cfrg@core3.amsl.com
Delivered-To: cfrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C9A53A6FFC for <cfrg@core3.amsl.com>; Mon, 4 Oct 2010 10:50:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.761
X-Spam-Level:
X-Spam-Status: No, score=-5.761 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 FGnAyLpOiecM for <cfrg@core3.amsl.com>; Mon, 4 Oct 2010 10:50:42 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 741243A6FF6 for <cfrg@irtf.org>; Mon, 4 Oct 2010 10:50:42 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 426981E00BA; Mon, 4 Oct 2010 10:51:38 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 4 Oct 2010 10:51:38 -0700 (PDT)
Message-ID: <092405dc28038119878c75f1b01f29bc.squirrel@www.trepanning.net>
In-Reply-To: <p06240834c8cea6ec688d@[10.20.30.158]>
References: <4CA65AD7.80300@ieca.com> <p06240808c8cd060efcb4@[10.20.30.158]> <4CA8ECA9.9020201@gondrom.org> <p06240834c8cea6ec688d@[10.20.30.158]>
Date: Mon, 04 Oct 2010 10:51:38 -0700
From: Dan Harkins <dharkins@lounge.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 1 (Highest)
Importance: High
Cc: Tobias Gondrom <tobias.gondrom@gondrom.org>, cfrg@irtf.org, saag@ietf.org
Subject: Re: [Cfrg] [saag] [Fwd: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt]
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Oct 2010 17:50:43 -0000

On Sun, October 3, 2010 2:35 pm, Paul Hoffman wrote:
>>One further comment: I am a bit uncertain to why you refer to SHA-256
>>from the SHA-2 family only (and thus not mention/exclude SHA-512)?
>
> Because the IETF almost always deals only with 128-bit strength security,
> and using SHA-384 or SHA-512 is just as waste of processor and network
> resources in such cases.

  That's an odd statement. There is suite B guidance for use of quite alot
of IETF protocols-- TLS, SSH, IKE/IPsec, S/MIME-- that provide for more
than "128-bit strength security". The qualifier ("almost always") even adds
to the oddness. Check out the D-H groups for use in IKE. They run the gamut
of strength estimates. Arguably neither of the cryptographic suites for
IPsec from RFC 4308, of which you are the author, provides 128-bits of
strength security (the required D-H groups afford approximately 80 to
"VPN-A" and 112 bits to "VPN-B").

  We continue to define the use of ciphers with > 128 bit keys. We
continue to define the use of D-H groups that produce shared secrets
of > 128 bits of approximate strength. Hash algorithms that can be used
in key derivation, key confirmation, and digital signatures which afford
greater than 128-bits of approximate strength should not be excluded.

  Dan.