Re: [TLS] sect571r1
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; tls@ietf.org Subject: Re: [TLS] sect571r1 On Wed, Jul 15, 2015 at 6:42 PM, Dan Brown dbr...@certicom.commailto:dbr...@certicom.com 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
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, 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) https://securitypitfalls.wordpress.com/2015/07/14/june-2015-scan-results/ Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
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 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 CA'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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
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. :) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] sect571r1
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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
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 use secp256r1secp384r1secp521r1 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
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 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 secp256r1secp384r1secp521r1 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
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. 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
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] sect571r1 Tony Arcieri basc...@gmail.com 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 to adopt a curve portfolio like this: - CFRG curves (RECOMMENDED): Curve25519, Ed448-Goldilocks - 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 smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
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: 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 this: - CFRG curves (RECOMMENDED): Curve25519, Ed448-Goldilocks - NIST curves (SUPPORTED): P-256, P-384, P-521 All other curves should be removed, IMO. smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
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 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. 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
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=OpenSSLversion=1.0.1l [2] https://www.ssllabs.com/ssltest/viewClient.html?name=OpenSSLversion=1.0.2 [3] http://openssl.org/docs/ssl/SSL_CTX_set_ecdh_auto.html [4] https://sslanalyzer.comodoca.com/?url=sslanalyzer.comodoca.com On 15/07/15 22:42, Dave Garrett wrote: 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls