Re: [Cfrg] On "non-NIST"

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 25 February 2015 19:36 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30ED11A1AAF for <cfrg@ietfa.amsl.com>; Wed, 25 Feb 2015 11:36:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08AWgdQv0OSs for <cfrg@ietfa.amsl.com>; Wed, 25 Feb 2015 11:36:06 -0800 (PST)
Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9C611A1BCA for <cfrg@irtf.org>; Wed, 25 Feb 2015 11:36:04 -0800 (PST)
Received: by lbiw7 with SMTP id w7so6154828lbi.9 for <cfrg@irtf.org>; Wed, 25 Feb 2015 11:36:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+ujnJbBtI7hBSxqVuVm+35YXWugkJpLGF3C+Ama2CIw=; b=g6/myYu8Bn+7iulZpTMDvCjFtl/lmlfTgyJRqKG1miZanh6aJtVr/ClzQ4+keV4bET i/+u1Vo+90UgrNCEGnWeNwgVejjlVwH3CpC1mWarRB+U1KtnT97H88ArO2L4ljZTshzn tV7eWynmDS1kTZtPH5yOVHcSAS3hEQj0irLGL9i1rM5gY0ZS0Pn4//nILgm8I0X6GMPq g8SDbTMCpj9PdXdo2kQVSqs6H/soPgTZ2baA2RPAQslmMEEgO61CuabTNffcVO1TYRKk oX0P1Rd1bn8L9hEgRuJ10uPfnWV3SH2+fZolXBy68lw22EvXhh6NZtMiL2T/fJVd/M6F 6CYA==
MIME-Version: 1.0
X-Received: by 10.152.179.135 with SMTP id dg7mr4475270lac.58.1424892963139; Wed, 25 Feb 2015 11:36:03 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.113.3.165 with HTTP; Wed, 25 Feb 2015 11:36:02 -0800 (PST)
In-Reply-To: <D1135B9A.5C434%paul@marvell.com>
References: <54EDDBEE.5060904@isode.com> <54EDEE67.1010102@cs.tcd.ie> <D02DF679-9485-467F-A47C-FFF15139278B@vpnc.org> <q0xidr.nkcbrp.2vaesh-qmf@mercury.scss.tcd.ie> <D1135B9A.5C434%paul@marvell.com>
Date: Wed, 25 Feb 2015 14:36:02 -0500
X-Google-Sender-Auth: _b1AE7bUlevH-oORjYk9_u15maM
Message-ID: <CAMm+LwgJxgygyURTQwC+hZueHDvpjPuMpQY90=ytLsFTFZM67w@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Paul Lambert <paul@marvell.com>
Content-Type: multipart/alternative; boundary=001a11349ae6e936d5050feebe83
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/94_OdSpdHWPHLz79ZnFLIFnBE5k>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, "paul.hoffman@vpnc.org" <paul.hoffman@vpnc.org>
Subject: Re: [Cfrg] On "non-NIST"
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/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: Wed, 25 Feb 2015 19:36:07 -0000

On Wed, Feb 25, 2015 at 2:31 PM, Paul Lambert <paul@marvell.com> wrote:

>
>
> On 2/25/15, 10:38 AM, "stephen.farrell@cs.tcd.ie"
> <stephen.farrell@cs.tcd.ie> wrote:
>
> >
> >
> >On Wed Feb 25 18:05:47 2015 GMT, Paul Hoffman wrote:
> >> On Feb 25, 2015, at 7:46 AM, Stephen Farrell
> >><stephen.farrell@cs.tcd.ie> wrote:
> >> > I do "prefer" that CFRG document only one of those as being
> >> > the usual non-NIST choice for >128 bit work factor.
> >>
> >> The term "non-NIST" is predictive, and the crypto community kinda sucks
> >>at predictions. We have no idea what NIST will do in the future if a
> >>bunch of IETF WGs adopt specific elliptic curves that are not P256/P384.
> >>Unfortunately, I suspect current NIST folks also have no idea what NIST
> >>will do in that case either. In the past, NIST has sometimes (but not
> >>always) responded to pressure from the real world about crypto
> >>algorithms and modes; let's hope for the best here.
> >
> >Sure, I agree it'd be good if NIST also annoint the output from this cfrg
> >process. But right now non-NIST is the correct distinguishing term for
> >what I meant. I see no reason that term will be needed in an RFC though
> >if that helps assuage some sensitivity somewhere in the universe :-)
>
> Branding is very important Š  "non-NIST" is adversarial and will
> discourage adoption.  NIST is also not the only Government agency
> recommending specific curve parameters.
>
> The NIST and other recommended Small Weierstrass curves are all based on
> the late 90¹s technology and requirements.
>
> The CFRG recommendations for Œnew curves¹ represent significant
> improvements based on more contemporary mathematical techniques and
> industry requirements. The well identified benefits and more modern
> aspects of the recommendations should be emphasized.
>
>
Further, NIST is holding a workshop on ECC curves specifically asking what
it can do to encourage deployment. So we are pushing against an open door
here.