Re: [Cfrg] MAY use specified curves
Dan Brown <dbrown@certicom.com> Tue, 09 September 2014 19:38 UTC
Return-Path: <dbrown@certicom.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 62FC31A01E6 for <cfrg@ietfa.amsl.com>; Tue, 9 Sep 2014 12:38:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 jn-OtyNbPvsi for <cfrg@ietfa.amsl.com>; Tue, 9 Sep 2014 12:38:57 -0700 (PDT)
Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id C33B81A01CA for <cfrg@irtf.org>; Tue, 9 Sep 2014 12:38:56 -0700 (PDT)
Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs210cnc.rim.net with ESMTP/TLS/AES128-SHA; 09 Sep 2014 15:38:53 -0400
Received: from XCT112CNC.rim.net (10.65.161.212) by XCT102CNC.rim.net (10.65.161.202) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 9 Sep 2014 15:38:53 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT112CNC.rim.net ([::1]) with mapi id 14.03.0174.001; Tue, 9 Sep 2014 15:38:53 -0400
From: Dan Brown <dbrown@certicom.com>
To: "'stephen.farrell@cs.tcd.ie'" <stephen.farrell@cs.tcd.ie>, "'cfrg@irtf.org'" <cfrg@irtf.org>
Thread-Topic: [Cfrg] MAY use specified curves
Thread-Index: Ac/MS9WEcVQyhv+MQ4eAE/FZsUdlsAAMq3oAAAe27ZA=
Date: Tue, 09 Sep 2014 19:38:52 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF5CD8FC8@XMB116CNC.rim.net>
References: <810C31990B57ED40B2062BA10D43FBF5CD8CE5@XMB116CNC.rim.net> <540F48B4.1090600@cs.tcd.ie>
In-Reply-To: <540F48B4.1090600@cs.tcd.ie>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.251]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0077_01CFCC44.285671B0"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/AF-l-nsmjsvHJGx0xZZqP7Ty-Wo
Subject: Re: [Cfrg] MAY use specified 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: Tue, 09 Sep 2014 19:38:59 -0000
> -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > > On 09/09/14 18:03, Dan Brown wrote: > > > > My understanding is that many IETF WGs have applied a MUST NOT to the > > ANSI/SECG mechanisms of specifying an elliptic curve. > > I'm not clear what you mean here. Can you provide citations? > > I think its fair to say that people generally prefer named curves for > simplicity and > interop reasons but I don't know what "MUST NOT" statements you mean. Well, I guess I was thinking of PKIX: RFC 5480 Section 2.1.1, has a literal "MUST NOT" http://tools.ietf.org/html/rfc5480#section-2 By contrast, RFC 3279 allowed specified curves, which I had forgotten. My proposal is for CFRG to recommend PKIX reverting to something more the previous state. But I was exactly wrong about TLS. Oops, terribly sorry. Haste on my part. Thanks for catching my mistake. I should be more careful. For certificates, I thought TLS followed PKIX, but I now see that RFC 4492 refers to RFC 3279, which still allowed specified curves. But 3279 is updated by 5480, so I'm not sure what rule is in effect for 4492 certificates. Anyway, based on this poor misunderstanding, I presumed that 4492 followed disallowed specified curves ECDHE. My mistake here is a much worse here, because there's plenty of text in 4492 about specifying curves. Specifically, RFC 4492, Section 5.4 allows explicit prime ECDHE parameters, though it uses a different format than ANSI/SECG. (In particular, it does not allow the seed to be sent, but I guess that's okay, because the server is sending the curve parameters, and the client already has to trust the server.) Also, 4492 does not allow client to specify curves ... but maybe that saves servers from headaches. I vaguely recall some TLS WG list emails agreeing to move towards named DHE parameters, and perhaps dropping DHE parameters. Perhaps the TLS WG plans on doing the same for ECDHE? If so, then my proposal is for CFRG to ask to retain the option of specified curves. Since I was so wrong about TLS, my understanding about other WGs is probably wrong too: they allow users to specify their own curves. Well, now that it seems many IETF WG already allow users to specify their own curves, CFRG might suggest ways to specify curves (and formats) for the new types of curves of being proposed. That would be a formatting issue though, not a curve choice issue.
- [Cfrg] MAY use specified curves Dan Brown
- Re: [Cfrg] MAY use specified curves Stephen Farrell
- Re: [Cfrg] MAY use specified curves Manuel Pégourié-Gonnard
- Re: [Cfrg] MAY use specified curves Dan Brown
- Re: [Cfrg] MAY use specified curves Stephen Farrell
- Re: [Cfrg] MAY use specified curves Daniel Kahn Gillmor
- Re: [Cfrg] MAY use specified curves David Leon Gil
- Re: [Cfrg] MAY use specified curves Watson Ladd