[Cfrg] generic curves ... RE: big-endian short-Weierstrass please

Dan Brown <dbrown@certicom.com> Thu, 29 January 2015 22:09 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 596671A8878 for <cfrg@ietfa.amsl.com>; Thu, 29 Jan 2015 14:09:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id lafNcYHFAZ8m for <cfrg@ietfa.amsl.com>; Thu, 29 Jan 2015 14:09:27 -0800 (PST)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com []) by ietfa.amsl.com (Postfix) with ESMTP id 7E09A1A8876 for <cfrg@irtf.org>; Thu, 29 Jan 2015 14:09:26 -0800 (PST)
Received: from xct105cnc.rim.net ([]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 29 Jan 2015 17:09:20 -0500
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT105CNC.rim.net ([fe80::d13d:b7a2:ae5e:db06%16]) with mapi id 14.03.0210.002; Thu, 29 Jan 2015 17:09:19 -0500
From: Dan Brown <dbrown@certicom.com>
To: "'nico@cryptonector.com'" <nico@cryptonector.com>, "'ynir.ietf@gmail.com'" <ynir.ietf@gmail.com>
Thread-Topic: generic curves ... RE: [Cfrg] big-endian short-Weierstrass please
Thread-Index: AdA8AesG7iT5/NihS7+0fk6r2j3zuw==
Date: Thu, 29 Jan 2015 22:09:18 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF5D45067@XMB116CNC.rim.net>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0082_01D03BE6.512EE8D0"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/Odf8RvMu0c2vxD96sCN0xZESRMg>
Cc: "'cfrg@irtf.org'" <cfrg@irtf.org>
Subject: [Cfrg] generic curves ... RE: 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: Thu, 29 Jan 2015 22:09:38 -0000

New thread name ... should have done so earlier.

When TLS asked CFRG for new curves, I didn't interpret that to mean that 
generic curves would be banned. Banishing generic curves adds slightly more 
weight to the TLS request, because users cannot easily opt out of the chosen 
few elite curves.

Upon further reflection, I think CFRG already spent enough time to find an 
answer that weightier question, and in particular, I'll keep my vote the same.

The current set of TLS named curves includes NIST (and some SECG?) and 
Brainpool curves, right?  Is there some of these current curves that TLS plans 
to disallow?

I'd suggest that TLS and IETF protocols only keep (EC)DH groups with at least 
2^256 - S elements (for small S), but grandfathering in Curve25519, P256, (and 
maybe secp256k1, if there ???).  In other words, smaller curves, 163 bits, 192 
bits, and so on, could be removed.  Actually, this should be redundant, as 
long protocols match symmetric key sizes ...

By the sounds of it, TLS doesn't yet have a good way to negotiate curves on 
the fly (even CA / server pre-validated curves?), yet.

My proposal for generic curves presumes that the generic elliptic curve domain 
parameters are authenticated, i.e. Alice and Bob are not duped into using a 
curve that they don't agree upon, and validated, perhaps in advance. 
Actually, the old standards, SEC1, X9, etc., pretty much make this a 
requirement before doing ECC.  Having tried to maintain a couple of these old 
standards, I sometimes take such things for granted.  Anyway, if TLS is unable 
to only achieve this authentication by using vetted and named curves, then my 
generic curve proposal would not apply to TLS.

Best regards,


PS While we're tracking thread discussions, I remember suggesting to one the 
lists last year that TLS add for support generic curves, but I was mistakenly 
confusing TLS and PKIX: it was PKIX that had restricted named-curves only.  I 
don't recall this much discussion in response, other a couple people 
correcting my mistake.  If it was pointed out at that time that TLS was unable 
to securely support generic curves, then I apologize for forgetting.