Re: [TLS] sect571r1

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: mrex@sap.com
Cc: <tls@ietf.org>
Subject: Re: [TLS] sect571r1

Tony Arcieri wrote:
[ Charset UTF-8 unsupported, converting... ]
> Dave Garrett <davemgarrett@gmail.com> 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.

-Martin

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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls