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 w
On Wednesday, July 15, 2015 10:15:23 am Ilari Liusvaara wrote:
> Let's review: draft-ietf-tls-tls13-07
Eric obviously does all the heavy lifting here, but I can reply to a
few bits in the areas I've touched.
> (Note: I omitted some stuff I saw recently discussed (e.g. pruning
> unused crypto algo
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 qui
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 wrote:
>
> In PR 188 for TLS 1.3, I pruned down the allowed elliptic curves to just the
> ones actually used. (per Sean's recomm
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" 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) On
On Wed, Jul 15, 2015 at 11:13 AM, Dave Garrett
wrote:
> 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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/ma
On Mon, June 29, 2015 4:31 am, Hubert Kario wrote:
> On Friday 26 June 2015 20:39:24 Geoffrey Keating wrote:
>> Dave Garrett writes:
>> > On Friday, June 26, 2015 07:48:01 pm Attila Molnar wrote:
>> > > Currently SRP cannot be used with newer crypto primitives such as
>> > > ciphers in AEAD mode
> On Jul 15, 2015, at 9:19 PM, Benjamin Beurdouche
> 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 use secp256r1>>secp384r1
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 wrote:
>
> > On Jul 15, 2015, at 9:19 PM, Benjamin Beurdouche <
> benjamin.beurdou...@inria.fr> wrote:
> >
> > H
> So, should it stay or should it go now? Opinions?
>
+1 that sect571r1 be removed.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Wed, Jul 15, 2015 at 1:58 PM, Deirdre Connolly
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 implemente
On Wed, Jul 15, 2015 at 01:59:26PM -0700, Adam Langley wrote:
> On Wed, Jul 15, 2015 at 1:58 PM, Deirdre Connolly
> wrote:
> >
> >> So, should it stay or should it go now? Opinions?
> >
> > +1 that sect571r1 be removed.
>
> I also believe that it should be removed.
Same here, I think in this ca
On Wednesday, July 15, 2015 05:06:37 pm Tanja Lange wrote:
> > 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
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
___
On Wed, Jul 15, 2015 at 2:39 PM, 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, Ed4
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:
Subject:
On Wednesday, July 15, 2015 06:06:37 pm Tony Arcieri wrote:
> On Wed, Jul 15, 2015 at 2:39 PM, 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 curv
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]
A
On 15/07/15 23:27, Rob Stradling wrote:
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 k
On 15 July 2015 at 15:18, Blumenthal, Uri - 0553 - MITLL
wrote:
> I'd rather not lose the 571 curve.
I'd like to understand why you think it's worth keeping.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Tony Arcieri wrote:
> On Wed, Jul 15, 2015 at 2:39 PM, 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
On Wed, Jul 15, 2015 at 4:40 PM, Brian Smith wrote:
> I agree, except that I think we should get rid of P-521 too.
>
I'd be fine with that
--
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
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
On Wed, Jul 15, 2015 at 4:46 PM, Tony Arcieri wrote:
> On Wed, Jul 15, 2015 at 4:40 PM, Brian Smith wrote:
>
>> I agree, except that I think we s
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:
Subject: Re: [TLS] sect571r1
To
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:
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 s
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
On Wed, Jul 15, 2015 at 6:42 PM, Dan Brown 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 supportin
On Wed, Jul 15, 2015 at 6:42 PM, Rene Struik 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 an
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.
> 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
To respond more specifically to your concerns:
On Wed, Jul 15, 2015 at 6:42 PM, Rene Struik 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 criteria within the
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 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
implement
>> >> So, should it stay or should it go now? Opinions?
>> >
>> > +1 that sect571r1 be removed.
>>
>> 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.
>
On Wed, Jul 15, 2015 at 8:41 PM, Jeffrey Walton wrote:
> It provides 256-bits of security. Its the only curve I am aware that
> can transport a AES-256 key while maintaining security levels.
Why do you think P-521 doesn't provide this?
--
Tony Arcieri
_
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
> c
>> (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.
>
Maybe
On Wed, Jul 15, 2015 at 11:48 PM, Tony Arcieri wrote:
> On Wed, Jul 15, 2015 at 8:41 PM, Jeffrey Walton wrote:
>>
>> It provides 256-bits of security. Its the only curve I am aware that
>> can transport a AES-256 key while maintaining security levels.
>
> Why do you think P-521 doesn't provide th
On Wed, Jul 15, 2015 at 11:52:13PM -0400, Jeffrey Walton wrote:
> > 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.
>
> Maybe so,
On Wednesday, July 15, 2015 10:31:12 pm Tony Arcieri wrote:
> 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,
On Jul 16, 2015, at 6:50 AM, Viktor Dukhovni wrote:
> 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.
Same kind of auditor who tell
> 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. :)
___
Ilari,
Thanks for your detailed comments.
> > Header
>
> Isn't 4346 already obsoleted by 5246, which this document also obsoletes?
>
> 4366 seems to be jointly obsoleted by 5246 and 6066.
>
> 5246 and 5077 are not in numerical order, whereas the rest are.
This was updated in a recent PR by Dave
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 sle
On Wed, Jul 15, 2015 at 8:52 PM, Jeffrey Walton wrote:
> 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
___
47 matches
Mail list logo
