. 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; tls@ietf.org
Subject: Re: [TLS] sect571r1
On Wed, Jul 15, 2015 at 6:42
On Wednesday, July 15, 2015 09:42:51 pm Dan Brown 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,
On Wed, Jul 15, 2015 at 11:41:03PM -0400, Jeffrey Walton wrote:
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.
It provides 256-bits of security. Its the only curve I am aware that
can
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. :)
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
On Jul 15, 2015, at 9:19 PM, Benjamin Beurdouche
benjamin.beurdou...@inria.fr wrote:
Hey,
Except if someone has a real need for it,
I would favour removing p571 and keep secp521r1 as the maximum …
+1
It should be noted that I have removed it from RFC4492bis. In terms of
real-world
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 ynir.i...@gmail.com wrote:
On Jul 15, 2015, at 9:19 PM, Benjamin Beurdouche
benjamin.beurdou...@inria.fr
On Wed, Jul 15, 2015 at 1:58 PM, Deirdre Connolly
durumcrustu...@gmail.com wrote:
So, should it stay or should it go now? Opinions?
+1 that sect571r1 be removed.
I also believe that it should be removed.
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
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
This I absolutely cannot agree. P521 must stay, as part of the supported NIST
standard (which BTW we use).
Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
From: Brian Smith
Sent: Wednesday, July 15, 2015 19:40
To: Tony Arcieri
Cc: tls@ietf.org
Subject: Re: [TLS
@ietf.org
Subject: Re: [TLS] sect571r1
On Wed, Jul 15, 2015 at 2:39 PM, Dave Garrett davemgarr...@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
On Wednesday, July 15, 2015 06:06:37 pm Tony Arcieri wrote:
On Wed, Jul 15, 2015 at 2:39 PM, Dave Garrett davemgarr...@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
On Wednesday, July 15, 2015 05:39:26 pm Dave Garrett wrote:
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
___
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]
14 matches
Mail list logo
