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.