Subject: [TLS] sect571r1

From: Dave Garrett <[email-masked]>
Date: Wed, 15 Jul 2015 14:13:21 -0400

In PR 188 for TLS 1.3, I pruned down the allowed elliptic curves to just the ones actually used. (per Sean's recommendation) One point of discussion between Eric and myself: sect571r1. I'm in favor of keeping it, but not very strongly. Eric suggested removing it. It does get some use, though quite a bit less than the others.

The main reason I think this warrants discussion is that dropping it would drop the maximum bits here, which whilst obviously not the only factor to take into account, will possibly not be desired by some. The main arguments for ditching is probably that it might not be safely implemented and nobody actually needs something this big.

So, should it stay or should it go now? Opinions?

Dave

---

From: Benjamin Beurdouche <[email-masked]>
Date: Wed, 15 Jul 2015 20:19:38 +0200

Hey,

Except if someone has a real need for it,
I would favour removing p571 and keep secp521r1 as the maximum …

Cheers,
B.

> On 15 Jul 2015, at 20:13, Dave Garrett <[email-masked]> wrote:
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 15 Jul 2015 18:51:37 +0000

I’m in favor of keeping sect571r1. I realize it doesn’t get a ton of usage.
-- 
Regards,
Uri Blumenthal

On 7/15/15, 14:13 , "TLS on behalf of Dave Garrett" <[email-masked]
on behalf of [email-masked]> wrote:

>In PR 188 for TLS 1.3, I pruned down the allowed elliptic curves to just
>the ones actually used. (per Sean's recommendation) One point of
>discussion between Eric and myself: sect571r1. I'm in favor of keeping
>it, but not very strongly. Eric suggested removing it. It does get some
>use, though quite a bit less than the others.
>
>The main reason I think this warrants discussion is that dropping it
>would drop the maximum bits here, which whilst obviously not the only
>factor to take into account, will possibly not be desired by some. The
>main arguments for ditching is probably that it might not be safely
>implemented and nobody actually needs something this big.
>

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 15 Jul 2015 11:54:51 -0700

> So, should it stay or should it go now? Opinions?

I'd prefer to see it removed. There's no good reason to keep it, IMO.

-- 
Tony Arcieri

---

From: Yoav Nir <[email-masked]>
Date: Wed, 15 Jul 2015 22:52:07 +0300

> On Jul 15, 2015, at 9:19 PM, Benjamin Beurdouche <[email-masked]> wrote:
> 
> Hey,
> 

+1

It should be noted that I have removed it from RFC4492bis. In terms of real-world use secp256r1>>secp384r1>>secp521r1 and everything else is lost in the noise. 

At any rate, if the group decides to keep it, I might as well bring it back to 4492bis as well.

Yoav

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 15 Jul 2015 13:04:13 -0700

We absolutely should have harmony between 1.3 and 4492bis.

Since Uri objected, i'll let the chairs decide if/when we have consensus.

-Ekr

On Wed, Jul 15, 2015 at 12:52 PM, Yoav Nir <[email-masked]> wrote:

> It should be noted that I have removed it from RFC4492bis. In terms of
> real-world use secp256r1>>secp384r1>>secp521r1 and everything else is lost
> in the noise.
>

---

From: Deirdre Connolly <[email-masked]>
Date: Wed, 15 Jul 2015 20:58:24 +0000

> So, should it stay or should it go now? Opinions?

+1 that sect571r1 be removed.

---

From: Adam Langley <[email-masked]>
Date: Wed, 15 Jul 2015 13:59:26 -0700

> +1 that sect571r1 be removed.

I also believe that it should be removed.

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Tanja Lange <[email-masked]>
Date: Wed, 15 Jul 2015 23:06:37 +0200

> The main reason I think this warrants discussion is that dropping it would drop the maximum bits here, which whilst obviously not the only factor to take into account, will possibly not be desired…
Removing it would drop the max number of bits but not necessarily the 
max security. The exact security of binary curves is currently under
discussion. The new algorithms offer at best an asymptotic speedup --
but 571 might be big enough to fall under asymptotics.

I understand that libraries support it, but is it actually being used?
Does anybody have statistics on how many sites use it?
	Tanja

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 15 Jul 2015 21:11:40 +0000

> I also believe that it should be removed.

Same here, I think in this case "less is more".  There is no
compelling reason for this curve, and needless diversity here is
counter-productive.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Wed, 15 Jul 2015 17:39:26 -0400

> Does anybody have statistics on how many sites use it?

It's the most used of the rarely used curves.

https://securitypitfalls.wordpress.com/2015/07/14/june-2015-scan-results/

Server-side support is generally low, however a number of servers prefer to use it for ECDHE. (usage is in the same order of magnitude as P-384 & P-521, though notably less) This is down from the previous month's results but up from the month before. Server support is at a similar rate to other rarely used larger curves, but still a fraction of a percent. Nothing requires it, outright.

It's important to note that the dropped range(s) of curves are listed as "MUST NOT" offer or negotiate for any TLS 1.3 implementation, though I haven't added any requirement to enforce that.

Dropping it really does drop down the max size drastically, but the general CFRG consensus seems to be that nothing above curve448 is even helpful and secp521r1 would still be permitted for those that want bigger numbers. (given the CFRG opinion, even secp521r1 should be on the chopping block, then)

Dave

---

From: Dave Garrett <[email-masked]>
Date: Wed, 15 Jul 2015 17:42:47 -0400

> It's the most used of the rarely used curves.

This statement is potentially confusing, actually, because in comparison to P256 _everything_ is rarely used when it comes to ECDHE.

Dave

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 15 Jul 2015 15:06:37 -0700

> 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

All other curves should be removed, IMO.

---

From: Dave Garrett <[email-masked]>
Date: Wed, 15 Jul 2015 18:22:53 -0400

On Wednesday, July 15, 2015 06:06:37 pm Tony Arcieri wrote:
> On Wed, Jul 15, 2015 at 2:39 PM, Dave Garrett <[email-masked]> wrote:

This does seem to be the growing consensus. I've submitted a PR to drop it:
https://github.com/tlswg/tls13-spec/pull/200/files

Unless someone can provide more detail as to why it might be needed to keep around, it looks like the WG wants rid of it.

Dave

---

From: Rob Stradling <[email-masked]>
Date: Wed, 15 Jul 2015 23:27:37 +0100

AIUI, OpenSSL's default highest preference curve is sect571r1 (aka 
B-571).  See [1] and [2].

The result of calling OpenSSL's recommended SSL_CTX_set_ecdh_auto(ctx, 
1) function is that "the highest preference curve is automatically used 
for ECDH temporary keys used during key exchange." [3]

And sure enough, when my SSL scanner (an OpenSSL-based client) scans 
itself (an httpd/mod_ssl/OpenSSL-based server) [4], it reports that 
sect571r1 is used.  I haven't explicitly configured it to use this 
curve.  In fact, I would reconfigure it to use secp256r1 if I could find 
a mod_ssl directive that would let me do that.

So I'm wondering if most people using sect571r1 are using it simply 
because it's a default setting that they can't change, not because they 
have a particularly strong desire to use it.

+1 to dropping sect571r1 and to Tony's suggestion of further trimming 
the curve list.

[1] 
https://www.ssllabs.com/ssltest/viewClient.html?name=OpenSSL&version=1.0.1l

[2] 
https://www.ssllabs.com/ssltest/viewClient.html?name=OpenSSL&version=1.0.2

[3] http://openssl.org/docs/ssl/SSL_CTX_set_ecdh_auto.html

[4] https://sslanalyzer.comodoca.com/?url=sslanalyzer.comodoca.com

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Rob Stradling <[email-masked]>
Date: Wed, 15 Jul 2015 23:53:35 +0100

> have a particularly strong desire to use it.

s/that they can't change//

In httpd 2.4, the supported curve(s) can be configured using the 
SSLOpenSSLConfCmd directive.  (Thanks to Steve Henson for pointing me in 
the right direction just now).

>> This statement is potentially confusing, actually, because in
>> comparison to P256 _everything_ is rarely used when it comes to ECDHE.
>>
>>
>> Dave
>>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: Brian Smith <[email-masked]>
Date: Wed, 15 Jul 2015 19:40:03 -0400

> - NIST curves (SUPPORTED): P-256, P-384, P-521

I agree, except that I think we should get rid of P-521 too.

Cheers,
Brian

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 15 Jul 2015 16:46:49 -0700

> I agree, except that I think we should get rid of P-521 too.

I'd be fine with that

-- 
Tony Arcieri

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 15 Jul 2015 16:52:55 -0700

I don't feel really strongly about this, but I'd prefer to keep P-521.

I suggest we remove sect571tr1 now and then we can debate P-521 later.

-Ekr

---

From: [email-masked] (Martin Rex)
Date: Thu, 16 Jul 2015 02:20:56 +0200 (CEST)

Tony Arcieri wrote:
[ Charset UTF-8 unsupported, converting... ]
> Dave Garrett <[email-masked]> wrote:
>> 

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.

---

From: Rene Struik <[email-masked]>
Date: Wed, 15 Jul 2015 21:42:25 -0400

Dear colleagues:

It seems prudent to keep some diversity of the gene pool and not only 
have curves defined over prime curves. Similarly, one should perhaps 
have some diversity of gene pool criteria within the set of recommend 
curves and not only include special primes. Should some problem with a 
particular subclass show up over time, one then at least has other 
classes available.

On a general note, I do not understand what is wrong with having a 
dictionary of curves that is well-specified, but whose members are not 
all widely used. To my knowledge, having a dictionary does not force 
everyone to use every term in this (mandatory vs. optional to implement 
vs. mandatory to use, etc.).

If one follows the line of reasoning of some people on the mailing list 
earlier today, doesn't this also call into question Brainpool curves, 
or, e.g., the Misty cipher, etc.? Moreover, this certainly calls into 
question why one would have a whole set of new DLP groups (which 
certainly cannot be widely used yet, since the ink to write the 
parameters down is still wet). What about RSA-1024, etc.?

I would suggest one to have a clear criteria by which to judge 
inclusion/exclusion of cryptographic algorithms.

As a final note: if one can define curves explicitly, then removing 
these from a list does  not really remove them, except "pestering" 
people who would like to use them by forcing sending big chunks of 
descriptive text instead of short-hand references.

Best regards, Rene

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Dan Brown <[email-masked]>
Date: Thu, 16 Jul 2015 01:42:51 +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: [email-masked]
Cc: <[email-masked]>
Subject: Re: [TLS] sect571r1

Tony Arcieri wrote:

-Martin

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 15 Jul 2015 18:46:58 -0700

On Wed, Jul 15, 2015 at 6:42 PM, Dan Brown <[email-masked]> wrote:

> 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.

Others are pushing FFDHE in the event of some ECC disaster. I'm not really
a fan of that either (all these things add attack surface in addition to
being "backups"), but if we're going to keep a little used thing around in
our pocket just in case of an ECC disaster, why do we need backup curves in
addition to FFDHE?

-- 
Tony Arcieri

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 15 Jul 2015 18:48:42 -0700

On Wed, Jul 15, 2015 at 6:42 PM, Rene Struik <[email-masked]> wrote:

> Dear colleagues:
>
> It seems prudent to keep some diversity of the gene pool and not only have
> curves defined over prime curves. Similarly, one should perhaps have some
> diversity of gene pool criteria within the set of recommend curves and not
> only include special primes. Should some problem with a particular subclass
> show up over time, one then at least has other classes available.

I just responded to Dan Brown with this, but it applies here as well:

---------- Forwarded message ----------
From: Tony Arcieri <[email-masked]>
Date: Wed, Jul 15, 2015 at 6:46 PM
Subject: Re: [TLS] sect571r1
To: Dan Brown <[email-masked]>
Cc: Martin Rex <[email-masked]>, "<[email-masked]>" <[email-masked]>

-- 
Tony Arcieri

---

From: Dan Brown <[email-masked]>
Date: Thu, 16 Jul 2015 02:02:26 +0000

FFDHE with prime field is one big step away from FFDHE with binary field, which has quasipoly time DLP, so that's quite a large risk.
ECDHE with binary field is also one big step away from binary FFDHE, but it's a different type of step: hence diversity.
I agree that diversity risks weakest link. Ideally, the rainy day backups should be disabled by default, but possible to quickly enable, by administrator configuration or patch.
From: Tony Arcieri
Sent: Wednesday, July 15, 2015 9:47 PM
To: Dan Brown
Cc: Martin Rex; <[email-masked]>
Subject: Re: [TLS] sect571r1

On Wed, Jul 15, 2015 at 6:42 PM, Dan Brown <[email-masked]<mailto:[email-masked]>> wrote:
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.

Others are pushing FFDHE in the event of some ECC disaster. I'm not really a fan of that either (all these things add attack surface in addition to being "backups"), but if we're going to keep a little used thing around in our pocket just in case of an ECC disaster, why do we need backup curves in addition to FFDHE?

--
Tony Arcieri

---

From: Jeffrey Walton <[email-masked]>
Date: Wed, 15 Jul 2015 22:27:11 -0400

> dictionary of curves that is well-specified, but whose members are not all
> widely used. To my knowledge, having a dictionary does not force everyone to
> use every term in this (mandatory vs. optional to implement vs. mandatory to
> use, etc.).

Related, see Dan Geer's "Heartbleed as Metaphor",
http://www.lawfareblog.com/heartbleed-metaphor.

Geer says, "Nature teaches that monocultures are so unnatural as to
require constant intervention to maintain."

Jeff

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 15 Jul 2015 19:31:12 -0700

To respond more specifically to your concerns:

> show up over time, one then at least has other classes available.

Binary curves in particular are showing warning signs of potential future
security issues:

https://eprint.iacr.org/2015/310.pdf

I think even if we don't completely pare down the TLS curve portfolio to
the list I suggested, if nothing else I would like to see binary curves
removed.

-- 
Tony Arcieri

---

From: Dave Garrett <[email-masked]>
Date: Wed, 15 Jul 2015 22:42:54 -0400

> 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?

Already dropped. That's obviously not irreversible, but it's unambiguously in the virtually unused camp. The initial goal was to drop all largely unused curves.

This question is just about sect571r1, which is far closer to secp384r1 & secp521r1 in terms of usage, though still notably less. If you want to argue for going with sect571k1 and not sect571r1, I don't think the WG is on-board with that. Even if we continued to allow it, I doubt much would add support for it to be worthwhile.

The scan I linked to found one; literally a single server on the entire Internet, that actually supports sect571k1 for ECDHE. The stats also show 1575 "support" it, so I'm not sure what's going on there specifically. (if someone can explain this bit of those stats, please do)

Dave

---

From: Dave Garrett <[email-masked]>
Date: Wed, 15 Jul 2015 22:49:40 -0400

On Wednesday, July 15, 2015 10:42:54 pm Dave Garrett wrote:
> The stats also show 1575 "support" it, so I'm not sure what's going on there specifically. (if someone can explain this bit of those stats, please do)

Actually, now that I think about it, it could just be that every single implementation out there prioritizes sect571r1 over sect571k1. So, it has low support, but everything that supports it defaults to sect571r1.

Note that both are supported by an order of magnitude fewer servers than secp384r1 and secp521r1.

Dave

---

From: Jeffrey Walton <[email-masked]>
Date: Wed, 15 Jul 2015 23:41:03 -0400

> compelling reason for this curve, and needless diversity here is
It provides 256-bits of security. Its the only curve I am aware that
can transport a AES-256 key while maintaining security levels.

(I've been through C&A's where matching security levels were examined).

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 15 Jul 2015 20:48:47 -0700

> can transport a AES-256 key while maintaining security levels.

Why do you think P-521 doesn't provide this?

-- 
Tony Arcieri

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 16 Jul 2015 03:50:17 +0000

> can transport a AES-256 key while maintaining security levels.

It provides a conjectured security level around 256-bits, as does
secp521r1.

> (I've been through C&A's where matching security levels were examined).

An auditor who believes that we can rigourously quantify the security
of these curves precisely enough to say which is stronger or more
closely "matches" AES-256, should be laughed out of the room and fired.

-- 
	Viktor.

---

From: Jeffrey Walton <[email-masked]>
Date: Wed, 15 Jul 2015 23:52:13 -0400

> closely "matches" AES-256, should be laughed out of the room and fired.
Maybe so, but it is what it is. The IETF is probably not going to be
able to change it.

Jeff

---

From: Jeffrey Walton <[email-masked]>
Date: Wed, 15 Jul 2015 23:52:53 -0400

> Why do you think P-521 doesn't provide this?
My bad... I meant over the binary curves.

Jeff

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 16 Jul 2015 04:07:27 +0000

> Maybe so, but it is what it is. The IETF is probably not going to be

Well, the auditor can't ask for curves with TLS that the specification
deprecates.  So removing oddball choices will help users fend off
clueless checklist-wielding auditors.

A modest amount of diversity is fine, but I would posit that anything
beyond a (conservative, performant, backup) triple is counterproductive.
Between the anticipated CFRG curves and the NIST prime curves, I
think we already have a couple too many.

The way I see it:

	conservative = Goldilocks
	performant = 25519
	backup = P-256, P-384, P-521 (legacy triple)

All the above should ultimately be MTI, with each peer prioritizing
either "conservantive" or "performant", and legacy peers do the
same with "P-256" or "P-384" (with P-521 as backup for both camps).

If there are signs that all these are about to fail, and we still
somehow are left with some curves we're willing to trust, we can
change the mix then.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Thu, 16 Jul 2015 00:17:28 -0400

> the list I suggested, if nothing else I would like to see binary curves

As of today's draft version on GitHub [0], the only curves permitted in TLS 1.3+ are:
secp256r1, secp384r1, secp521r1, & sect571r1

NIST naming [1] of these:
P-256, P-384, P-521, & B-571

The other 571-bit is sect571k1 / K-571 (already cut).

NIST notation [2] for these names:
"P" denotes prime, "B" denotes binary, and "K" denotes Koblitz

If there's sufficient evidence that binary curves are likely to be unsafe in the future, then I would certainly consider that to be an additional argument to cut sect571r1. Thus far, I haven't seen much of an argument to keep it.

[0] https://tlswg.github.io/tls13-spec/#negotiated-groups
[1] https://tools.ietf.org/html/rfc4492#appendix-A
[2] http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf

Side question: what is the meaning of the "r" in the naming convention we use? (e.g. secp521r1, & sect571r1 vs. sect571k1)

Dave

---

From: Yoav Nir <[email-masked]>
Date: Thu, 16 Jul 2015 07:17:48 +0300

> closely "matches" AES-256, should be laughed out of the room and fired.

Same kind of auditor who tells you that you can’t replace the library with the next version that fixes the buffer overflow because it was the previous version that was certified.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 16 Jul 2015 04:33:52 +0000

> Same kind of auditor who tells you that you can’t replace the library with the
> next version that fixes the buffer overflow because it was the previous
> version that was certified.

In their defense, you do have to prove that this fix was the ONLY change. :)

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 16 Jul 2015 04:45:06 +0000

On Thu, Jul 16, 2015 at 12:17:28AM -0400, Dave Garrett wrote:

> Side question: what is the meaning of the "r" in the naming convention we
> use? (e.g. secp521r1, & sect571r1 vs. sect571k1)

The "r" means that a mysterious seed can be used to "verify" that
the curve paramets are ("nothing up my sleeve") *r*andom.

-- 
	Viktor.

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 15 Jul 2015 22:07:29 -0700

> My bad... I meant over the binary curves.

Per my comments on the other thread ("selection criteria for crypto
primitives"), I think binary curves don't instill confidence and should
probably be removed

--
Tony Arcieri

---

From: Hubert Kario <[email-masked]>
Date: Mon, 20 Jul 2015 15:08:29 +0200

On Wednesday 15 July 2015 22:42:54 Dave Garrett wrote:
> > 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?
> Already dropped. That's obviously not irreversible, but it's unambiguously
> in the virtually unused camp. The initial goal was to drop all largely
> unused curves.
> 
> This question is just about sect571r1, which is far closer to secp384r1 &
> secp521r1 in terms of usage, though still notably less. If you want to
> argue for going with sect571k1 and not sect571r1, I don't think the WG is
> on-board with that. Even if we continued to allow it, I doubt much would
> add support for it to be worthwhile.

This is likely just an artefact of use of OpenSSL curve order, if K-571 was 
first, the servers would likely select it over B-571 more often

> The scan I linked to found one; literally a single server on the entire
> Internet,

_not_ a single server in the Internet, a single server among Alexa top 1 
million websites - the scan is checking only a set of popular _websites_, not 
even all popular services that use TLS, let alone the whole Internet

> that actually supports sect571k1 for ECDHE. The stats also show
> 1575 "support" it, so I'm not sure what's going on there specifically. (if
> someone can explain this bit of those stats, please do)

The "Supported PFS" section describes what the server selects if the client 
advertises default OpenSSL order of all defined curves. The "Prefer" lines, 
means that the ciphersuite selected by server by default uses this key 
exchange.

IOW, if server supports FFDHE 2048 and ECDHE P-256 and prefers ECDHE, then the 
server will be counted in three lines:
DH,2048bits
ECDH,P-256,256bits
Prefer ECDH,P-256,256bits

The "Supported ECC curves" section describes what curves the server will use 
for ECDHE key exchange if its preferred one is not advertised by client (in 
most cases that means what happens if the client doesn't advertise P-256 
curve). Then that curve is removed and the process repeated until the server 
picks a ciphersuite that doesn't use ECDHE or aborts connection.

feel free to ask more questions about the scans if something is still unclear
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Johannes Merkle <[email-masked]>
Date: Tue, 21 Jul 2015 16:39:17 +0200

Rene Struik schrieb am 16.07.2015 um 03:42:
> Dear colleagues:
> 
> It seems prudent to keep some diversity of the gene pool and not only have curves defined over prime curves. Similarly,
> one should perhaps have some diversity of gene pool criteria within the set of recommend curves and not only include
> special primes. Should some problem with a particular subclass show up over time, one then at least has other classes
> available.
> 
> On a general note, I do not understand what is wrong with having a dictionary of curves that is well-specified, but
> whose members are not all widely used. To my knowledge, having a dictionary does not force everyone to use every term in
> this (mandatory vs. optional to implement vs. mandatory to use, etc.).
> 
> If one follows the line of reasoning of some people on the mailing list earlier today, doesn't this also call into
> question Brainpool curves, or, e.g., the Misty cipher, etc.? Moreover, this certainly calls into question why one would
> have a whole set of new DLP groups (which certainly cannot be widely used yet, since the ink to write the parameters
> down is still wet). What about RSA-1024, etc.?
> 

I absolutely back up this position. Currently, the TLS 1.3 draft only permits curves over special primes. It has become
quite clear in the discussions in CFRG and at the NIST ECC workshop that some parties (major hardware manufacturers,
certification bodies) prefer curves over random primes. And as Rene has pointed out, allowing both would also give more
agility w.r.t potential future attacks on certain sub-classes.

Why can't the draft just specify the curves that are MTI but allow (at least some) alternative options, instead of
putting all our eggs in one basket?

Johannes

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 21 Jul 2015 17:47:05 +0300

> agility w.r.t potential future attacks on certain sub-classes.

I thought that Brainpool curves weren't removed (even if those aren't
explicitly in), which are random prime curves.

Also, the security of binary curves seems quite questionable.

And I would expect that if more curves croak, either relatively few
curves croak (in style of MOV or SASS), or almost everything croaks.

-Ilari

---

From: Dave Garrett <[email-masked]>
Date: Tue, 21 Jul 2015 11:30:15 -0400

> Also, the security of binary curves seems quite questionable.

Brainpool curves aren't in the TLS 1.3 draft, but they're not prohibited either.

If there's no strong objection, I'd like to add them to the list, if just to document the current NamedGroup registry. I could add a recommendation to stick to standards track, for those worrying about them.

https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8

Dave

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 21 Jul 2015 20:20:11 +0300

On Tue, Jul 21, 2015 at 11:30:15AM -0400, Dave Garrett wrote:
> If there's no strong objection, I'd like to add them to the list, if
> just to document the current NamedGroup registry. I could add a
> recommendation to stick to standards track, for those worrying about them.

Related: There's the following draft: draft-iab-crypto-alg-agility
(currently in IETF LC) which contains the following:

3.4 National Cipher Suites

"The default server or
responder configuration SHOULD disable such algorithms; in this way,
explicit action by the system administrator is needed to enable them
where they are actually required."

While the thing is about cipher suites, it also goes for curves.

Also, Brainpool is much slower than the special prime stuff,
so I think the defaults should be high-performance where it is
not known to hurt security.

This could also be applied to some actual ciphersuite stuff, namely
ARIA and CAMELLIA (there doesn't seem to be any usable SEED ciphers).

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Jul 2015 21:42:03 +0200

> ARIA and CAMELLIA (there doesn't seem to be any usable SEED ciphers).

I would be comfortable with taking a hard look at these.

-Ekr