Re: [TLS] sect571r1

Dan Brown <> Thu, 16 July 2015 01:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 129BD1B2CDB for <>; Wed, 15 Jul 2015 18:42:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RM89_mhkHK0K for <>; Wed, 15 Jul 2015 18:42:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5CC661B2CD8 for <>; Wed, 15 Jul 2015 18:42:53 -0700 (PDT)
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 15 Jul 2015 21:42:53 -0400
Received: from ([fe80::45d:f4fe:6277:5d1b]) by ([fe80::d824:6c98:60dc:3918%16]) with mapi id 14.03.0210.002; Wed, 15 Jul 2015 21:42:52 -0400
From: Dan Brown <>
To: Martin Rex <>, Tony Arcieri <>
Thread-Topic: [TLS] sect571r1
Thread-Index: AQHQv0IwQsvdAJpzLEuyOkTGR5u8jJ3dUfsAgAAHmICAACWHAP//09Vm
Date: Thu, 16 Jul 2015 01:42:51 +0000
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-CA, en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "<>" <>
Subject: Re: [TLS] sect571r1
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Jul 2015 01:42:55 -0000

Binary curves have some risks, due to recent work of Semaev on subexponential ECDLP, building on much past work.

Even so, there's an argument from Koblitz and Menezes that special curves (e.g. binary curves) may survive some wider collapse. I think it's a weak argument, but for those for whom supporting more curves is easy, it could justify supporting a diversity of curves.

What about sect571k1, a Koblitz curve, aka NIST curve K-571? (By the way it has no unexplained constants...). Has it been removed already, or does the question also refer K-571 too?

The issue of malicious curves seems off-topic to this thread about max curve size, so briefly, to respond to the issue of unexplained constants it is a difficult issue, which CFRG is working on, and NIST too. My thought here is Brainpool deals best with this issue, so far, but it is a far-fetched issue, and other security issues are at least as important.

  Original Message
From: Martin Rex
Sent: Wednesday, July 15, 2015 8:21 PM
To: Tony Arcieri
Reply To:
Cc: <>
Subject: Re: [TLS] sect571r1

Tony Arcieri wrote:
[ Charset UTF-8 unsupported, converting... ]
> Dave Garrett <> wrote:
>> It's the most used of the rarely used curves.
> I think all "rarely used curves" should be removed from TLS. Specifically,
> I think it would make sense for TLS to adopt a curve portfolio like this:
> - CFRG curves (RECOMMENDED): Curve25519, Ed448-Goldilocks
> - NIST curves (SUPPORTED): P-256, P-384, P-521

P-256 and P-384 seem to be pretty important to some folks
(those with a NIST/NSA Suite B checklist).  I'm OK with P-521,
but I would prefer to get rid of pretty much all _other_
NIST curves with unexplained parameters, including 571

Either the NIST curves with unexplained constants _are_ backdoored,
then you get screwed no matter which one of them you use.
Or the NIST curves are OK, then P-521 will be good enough.  IMO.


Microsoft SChannel seems to implent the 3 NIST curves (P-256, P-384, P-521),
and MSIE 10 exhibits a curious behaviour on my Win7 machine:
when only TLSv1.0 is enabled, then MSIE 10 sends a ClientHello
with P-521 as the first curve in the named_curve extension.
when TLSv1.2 is also enabled, then MSIE 10 sends a ClientHello
with P-256 as the first curve in the named_curve extension.

TLS mailing list