To respond more specifically to your concerns:
On Wed, Jul 15, 2015 at 6:42 PM, Rene Struik rstruik@gmail.com wrote:
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
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
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]
I like Tony's recommendation - except that I'd rather not lose the 571 curve.
But I'm not going to fight the entire WG over this.
Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
From: Tony Arcieri
Sent: Wednesday, July 15, 2015 18:07
To: Dave Garrett
Cc:
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]
Let's review: draft-ietf-tls-tls13-07
This is abridged version of mail I sent earlier, but was too large for
the list due to its sheer size.
(Note: I omitted some stuff I saw recently discussed (e.g. pruning
unused crypto algorithms) or I remember discussed. I didn't explicitly
check issue list
16 matches
Mail list logo
