[Cfrg] Brazil Curves -> Re: Safecurves draft redux
Paul Lambert <paul@marvell.com> Mon, 20 January 2014 20:11 UTC
Return-Path: <paul@marvell.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 0D8001A0215 for <cfrg@ietfa.amsl.com>; Mon, 20 Jan 2014 12:11:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.332
X-Spam-Level:
X-Spam-Status: No, score=0.332 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, 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 JUNeHOESKnGQ for <cfrg@ietfa.amsl.com>; Mon, 20 Jan 2014 12:11:55 -0800 (PST)
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 28D9A1A0246 for <cfrg@irtf.org>; Mon, 20 Jan 2014 12:11:54 -0800 (PST)
Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s0KKBrkG014978; Mon, 20 Jan 2014 12:11:53 -0800
Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0b-0016f401.pphosted.com with ESMTP id 1hfp05r7dd-26 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 20 Jan 2014 12:11:53 -0800
Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Mon, 20 Jan 2014 12:11:51 -0800
From: Paul Lambert <paul@marvell.com>
To: Watson Ladd <watsonbladd@gmail.com>, "cfrg@irtf.org" <cfrg@irtf.org>
Date: Mon, 20 Jan 2014 12:11:49 -0800
Thread-Topic: Brazil Curves -> Re: [Cfrg] Safecurves draft redux
Thread-Index: Ac8WG9rS+vlpRL5sRy+WON+/k+Uyzg==
Message-ID: <CF02C06C.2CD92%paul@marvell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-20_03:2014-01-20, 2014-01-20, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1401200142
Subject: [Cfrg] Brazil Curves -> Re: Safecurves draft redux
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, 20 Jan 2014 20:11:56 -0000
> >The naming issue is fine: we can say "the safecurve Mxxx has been >found to be unsafe" without risk of being misunderstood. If there is >consensus that we should call the IANA registry something else, say >"Chicago curves", I'm not opposed to it. More of the curves seem appear to have come from Brazil (not necessarily the movie) than Chicago. There was a thread on clear naming conventions that has some consensus that did not add confusion by creating cute names. Could we please proceed with a consensus based draft. I also believe we are rushing too fast on the Œtrimming¹ before we have clearly identified and listed the attributes of the curves we have under recommend. A draft list the alternates and attributes seems essential. Consensus might then be possible when we can have are more coherent and documented review process. Also, there is value in having strong recommendations for a few curves used for identity/authentication. There is also value in describing alternatives for new protocols that might wish to have some crypto diversity. Documented a larger set with well described properties and possible applications would meet both requirements. Paul