Re: [TLS] sect571r1
I looks like we’ve come to WG consensus that the sect571r1 curve should be removed from the TLS 1.3 & 4492bis drafts. spt On Jul 20, 2015, at 09:08, Hubert Kario wrote: > On Wednesday 15 July 2015 22:42:54 Dave Garrett wrote: >> 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. > > 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___ > 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 Wednesday 15 July 2015 22:42:54 Dave Garrett wrote: > 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. 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 signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
Damn the spell-checkers. I CONCUR. :-) Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. Original Message From: Blumenthal, Uri - 0553 - MITLL Sent: Thursday, July 16, 2015 09:18 To: Viktor Dukhovni; tls@ietf.org Subject: Re: [TLS] sect571r1 I concurrent. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. Original Message From: Viktor Dukhovni Sent: Thursday, July 16, 2015 00:08 To: tls@ietf.org Reply To: tls@ietf.org Subject: Re: [TLS] sect571r1 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, but it is what it is. The IETF is probably not going to be > able to change it. 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
I concurrent. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. Original Message From: Viktor Dukhovni Sent: Thursday, July 16, 2015 00:08 To: tls@ietf.org Reply To: tls@ietf.org Subject: Re: [TLS] sect571r1 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, but it is what it is. The IETF is probably not going to be > able to change it. 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
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
___
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
Re: [TLS] sect571r1
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 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
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, but it is what it is. The IETF is probably not going to be > able to change it. 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
>> (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 so, but it is what it is. The IETF is probably not going to be able to change it. Jeff ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
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 this? My bad... I meant over the binary curves. Jeff ___ 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 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
>> >> 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. > 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). ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
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 ___ 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
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; Subject: Re: [TLS] sect571r1 On Wed, Jul 15, 2015 at 6:42 PM, Dan Brown mailto: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 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 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
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: m...@sap.com Cc: Subject: Re: [TLS] sect571r1 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: > > - CFRG curves (RECOMMENDED): Curve25519, Ed448-Goldilocks > - NIST curves (SUPPORTED): P-256, P-384, P-521 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. ___ 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
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: > > - CFRG curves (RECOMMENDED): Curve25519, Ed448-Goldilocks > - NIST curves (SUPPORTED): P-256, P-384, P-521 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. ___ 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: Subject: Re: [TLS] sect571r1 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 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 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 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 > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
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
Re: [TLS] sect571r1
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 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
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
Re: [TLS] sect571r1
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 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. 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). +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 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 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. ___ 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=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 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
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 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
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: Re: [TLS] sect571r1 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, 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 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, Ed448-Goldilocks - NIST curves (SUPPORTED): P-256, P-384, P-521 All other curves should be removed, IMO. ___ 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
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 > > 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? 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
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 case "less is more". There is no compelling reason for this curve, and needless diversity here is counter-productive. -- Viktor. ___ 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
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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
> 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
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 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 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 > > ___ > 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 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>>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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
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/mailman/listinfo/tls
Re: [TLS] sect571r1
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) 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 smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
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 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 ___ 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
