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

Phillip Hallam-Baker <hallam@gmail.com> Fri, 04 March 2011 13:56 UTC

Return-Path: <hallam@gmail.com>
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 C32953A686D for <keyassure@core3.amsl.com>; Fri, 4 Mar 2011 05:56:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.563
X-Spam-Level:
X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 iaLAKzn8Vhe1 for <keyassure@core3.amsl.com>; Fri, 4 Mar 2011 05:56:01 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 0A4CF3A67F0 for <keyassure@ietf.org>; Fri, 4 Mar 2011 05:56:00 -0800 (PST)
Received: by bwz13 with SMTP id 13so2433184bwz.31 for <keyassure@ietf.org>; Fri, 04 Mar 2011 05:57:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+STIRGGS306OgLrgqSsxWtj09frbPAnSJraaOLBEaQE=; b=EDmk9V7BPhEy5QF/9PIRu04jQYm7YlzYF9ZmeawAoet7gJ05lD6WojX1PMoouWGQok BKrj5ANbSa8PrqIl75x7JPadnFMvWqgJOislT+qSse2aREwxXZfxhBoBMFo3kNGDQDKY ccBpmTilUbf6bRCJ28Sm9TlSEPYkILcfuY9RI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qVJkdKfOq7uZE03Rsai7ohPFau8bgPbbln/88rDzpnfqbIlwNmaBPMx6op56f/Ur6h 3s1K+x6Iaz/fBU29VyfRXMosUrlkGNIckUYCIqlXpdj6lS/aWUIfIXMV4rAJeikhXdjk tdjrnPV/D71+eATcOIyH+1ZSZnCwdO1tDhMog=
MIME-Version: 1.0
Received: by 10.204.126.148 with SMTP id c20mr580779bks.87.1299247029148; Fri, 04 Mar 2011 05:57:09 -0800 (PST)
Received: by 10.204.14.139 with HTTP; Fri, 4 Mar 2011 05:57:09 -0800 (PST)
In-Reply-To: <201103041246.p24CkHZt011245@fs4113.wdf.sap.corp>
References: <7CDBED48-C800-4169-AF59-72075BA7EC2E@kumari.net> <201103041246.p24CkHZt011245@fs4113.wdf.sap.corp>
Date: Fri, 04 Mar 2011 08:57:09 -0500
Message-ID: <AANLkTik1r-sZvnNHCUtKO1De2CGb53x1Wk+ojRPOhOih@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: mrex@sap.com
Content-Type: multipart/alternative; boundary="0016e6d6415aa5dc08049da88515"
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 13:56:02 -0000

OK, how about this

Define code points for

SHA2-256
SHA2-512
SHA3-256 (reserved)
SHA3-512 (reserved)

If SHA3 is ready in time (i.e. we are still not ready in 2012) we could
consider making SHA3-256 the required algorithm. If not make SHA2-256 and
SHA2-512 the required algorithms.


I don't see the objective here being 'algorithm agility' like we were
fixated on in the 90s. We are not picking eight algorithms with a similar
level of security in the hope that one of them is going to be secure.

What we are doing here is coping with the fact that at the moment we do not
have an industry standard digest function that we can be completely happy
with and we are currently in the mid point of a transition.


On Fri, Mar 4, 2011 at 7:46 AM, Martin Rex <mrex@sap.com> wrote:

> Warren Kumari wrote:
> >
> > After watching the thread, I'd like to propose this as a strawman:
> >
> > Mandatory to implement algorithms are SHA-256 and SHA-384.
> > For now, these are all we specify.
> >
> > 2: Having more than 1 algorithm forces implementations to understand that
> > there is not just one, and so should help lead towards algorithm agility
>
> I'm OK with defining SHA-256 plus another, stronger hash for use with DANE
>
> I'm OK with mandating SHA-256.
>
>
> I do NOT buy the assertion that it is necessary to have _two_mandatory_
> algorithms for algorithm agility.  For other protocols in the security
> area, one single manadatory and additional recommended&optional
> algorithms are perfectly sufficient.
>
> SHA-384 also looks like an oddball to me.  For agility and interop tests,
> defining SHA-512 should be fine.  I would expect that by the time
> we need to move away from SHA-256, there is a SHA-3 available, and
> it would be OK for DANE to move from SHA-256 mandatory to SHA-3 manadatory
> without ever making SHA-512 mandatory (only recommended).
>
> -Martin
> _______________________________________________
> keyassure mailing list
> keyassure@ietf.org
> https://www.ietf.org/mailman/listinfo/keyassure
>



-- 
Website: http://hallambaker.com/