Re: [Cfrg] big-endian short-Weierstrass please

"Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu> Wed, 28 January 2015 23:39 UTC

Return-Path: <prvs=94703ee9bf=uri@ll.mit.edu>
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 763D91A802F for <cfrg@ietfa.amsl.com>; Wed, 28 Jan 2015 15:39:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.208
X-Spam-Level:
X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 wvTMu8jA3dER for <cfrg@ietfa.amsl.com>; Wed, 28 Jan 2015 15:39:33 -0800 (PST)
Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3411A0058 for <cfrg@irtf.org>; Wed, 28 Jan 2015 15:39:33 -0800 (PST)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t0SNctVG009057; Wed, 28 Jan 2015 18:39:30 -0500
From: "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>
To: Nico Williams <nico@cryptonector.com>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Thread-Topic: [Cfrg] big-endian short-Weierstrass please
Thread-Index: AdA6QfeHnVWfJGNlTzek7rmrn4E15gBEvvUAAAkmA5D///TDAIAACxgA//+0JAA=
Date: Wed, 28 Jan 2015 23:38:49 +0000
Message-ID: <D0EED79E.204B1%uri@ll.mit.edu>
References: <810C31990B57ED40B2062BA10D43FBF5D42BDA@XMB116CNC.rim.net> <87386ug2r7.fsf@alice.fifthhorseman.net> <810C31990B57ED40B2062BA10D43FBF5D4413B@XMB116CNC.rim.net> <87r3ueedx7.fsf@alice.fifthhorseman.net> <20150128231006.GJ3110@localhost>
In-Reply-To: <20150128231006.GJ3110@localhost>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.7.141117
x-originating-ip: [172.26.144.105]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3505315120_1371522"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-01-28_02:2015-01-28, 2015-01-28, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1501280236
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/eE8KiTa6iIa8_O3zliJMbRNS0Lc>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] big-endian short-Weierstrass please
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, 28 Jan 2015 23:39:35 -0000

On 1/28/15, 18:10 , "Nico Williams" <nico@cryptonector.com> wrote:

>On Wed, Jan 28, 2015 at 05:30:28PM -0500, Daniel Kahn Gillmor wrote:
>> On Wed 2015-01-28 16:23:27 -0500, Dan Brown wrote:
>> > For example, RFC 4492 allows curves to be specified in Weierstrass
>> > form, not just as named form.  I don't know if any TLS implementations
>> > support the specified curve option, but if they do, then it would be
>> > nice if the new implementations could talk to them, using the new
>> > curves.
>> 
>> Over in the TLS WG, we're working on actively deprecating the custom
>> curve selection mechanism and moving strictly toward pre-named curves
>> (this is true for finite-field DH as well).  Custom curve and FFDHE
>> group selection will be gone in TLS 1.3.
>> 
>>……
>> 
>> I don't think this is a particularly useful half-measure.  I'd rather
>> see implementations pick up new, reasonably-vetted curves than try to
>> muddle through supporting arbitrary curves provided by the peer.
>
>+1

The problem is - reasonably-vetted by who? NIST? DJB? Yourself? All of the
above?

Attractiveness of the ability to select a custom curve is similar to that
of PGP Web of Trust: you can make a choice for yourself, rather than being
forced into what other experts (or “experts” :) decide for you.