IETF Logo Mail Archive

Re: [Cfrg] revised requirements for new curves

"Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> Mon, 08 September 2014 15:14 UTC

Return-Path: <Kenny.Paterson@rhul.ac.uk>
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 222DB1A884D for <cfrg@ietfa.amsl.com>; Mon, 8 Sep 2014 08:14:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 BKg9hPuT0OK7 for <cfrg@ietfa.amsl.com>; Mon, 8 Sep 2014 08:14:53 -0700 (PDT)
Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0075.outbound.protection.outlook.com [213.199.154.75]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AD8F1A884B for <cfrg@irtf.org>; Mon, 8 Sep 2014 08:14:53 -0700 (PDT)
Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB384.eurprd03.prod.outlook.com (10.141.10.20) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Mon, 8 Sep 2014 15:14:51 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.00.1015.018; Mon, 8 Sep 2014 15:14:51 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Thread-Topic: [Cfrg] revised requirements for new curves
Thread-Index: AQHPy07l29iFHJb+W02/iURsgQFUO5v3T7UAgAAZqwA=
Date: Mon, 08 Sep 2014 15:14:51 +0000
Message-ID: <D033856A.2C9A5%kenny.paterson@rhul.ac.uk>
References: <D0333B6F.2C8CF%kenny.paterson@rhul.ac.uk> <CAMm+Lwi9rgAQNGW1k3TW52syexFUBOL1O48GizmLpcARrhBhgg@mail.gmail.com>
In-Reply-To: <CAMm+Lwi9rgAQNGW1k3TW52syexFUBOL1O48GizmLpcARrhBhgg@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.3.140616
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [134.219.227.30]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;
x-forefront-prvs: 03283976A6
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199003)(189002)(24454002)(479174003)(31966008)(79102001)(85306004)(46102001)(83506001)(110136001)(74662001)(74482001)(106356001)(77982001)(105586002)(101416001)(2656002)(85852003)(106116001)(20776003)(74502001)(76482001)(107046002)(83322001)(99396002)(19580395003)(19580405001)(76176999)(54356999)(21056001)(90102001)(92566001)(95666004)(87936001)(66066001)(83072002)(4396001)(86362001)(80022001)(92726001)(81342001)(81542001)(97736003)(36756003)(50986999); DIR:OUT; SFP:; SCL:1; SRVR:DBXPR03MB384; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <62660566A528AD4B9BD92A6CB51AF26E@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/q8kG4P148jZc1yHOfvmMmDj5Jcc
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] revised requirements for new curves
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: Mon, 08 Sep 2014 15:14:55 -0000

Hi

You're correct, there was not consensus on this point. The whole
requirement is marked as [NC] on my list, meaning "no consensus". It's
true that I did not specifically call this aspect out as being "NC".

However, 192-bit security was in the initial request from TLS WG as an
option. I don't see why we can't also solve this problem too (but I'm
prepared to drop it if it looks like it will prevent us from making
progress).

Cheers

Kenny 

On 08/09/2014 15:42, "Phillip Hallam-Baker" <phill@hallambaker.com> wrote:

>I didn't see consensus that we needed 192 bit curves.
>
>These seem superfluous to me If I want speed then I will go to 128
>bits. If I want high assurance I will go to 256. 192 is neither fish
>nor fowl.
>
>In a perfect world folk can make fine tuned choices between speed and
>security but I only have two security levels: paranoid and till the
>sun goes supernova secure level paranoid.

v2.23.0 | Report a Bug | By Email