Re: Cipher suits, signature algorithms, curves in Firefox
On Friday 06 May 2016 10:34:37 Zoogtfyz wrote: > > the larger key size helps w.r.t. quantum computers. > > If quantum computers are currently on the level of breaking AES-128, > then they are on the level of breaking any asymmetric cryptography > (RSA, DHE or ECDHE key exchange) we are using - which makes support > for AES-256 moot. That's not correct. Grover's algorithm requires you to perform 2^(n/2) operations to break symmetric crypto, and it uses n qbits to do that. To break aes-128 you need quantum computer with 128 qbits, and 2^64 operations. To break AES-256 you need 256 qbits and 2^128 operations. To break RSA you need quantum computer which can do Shor's algorithm, which requires n*3/2 qbits and around (log n)^2 operations. So for 2048 bit RSA you need 3072 qbit QC and about 83 operations. In other words, quantum computer that breaks AES-128 can't even scratch RSA. Quantum computer that breaks AES-256 doesn't make it possible to actually recover plaintext, and it still don't break currently used RSA. > Moving away from AES-256 will put even more > pressure on the crypto community to come up with a solution as > opposed to the *relative* complacency we are seeing now. I don't think we are in the position to demand crypto community to do anything in particular... -- Regards, Hubert Kario Senior 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. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cipher suits, signature algorithms, curves in Firefox
Zoogtfyz, On 5/6/2016 07:34, Zoogtfyz wrote: Websites that prefer AES-256, such as internal websites, can always instruct their users/customers to toggle a switch in Firefox to enable AES-256. I am proposing having AES-256 ciphersuits toggled off by default. IMO, that is impractical. I would recommend against doing this. It was discussed on the Chrome mailing list. They are not yet enabled by default in Chrome stable, it is not yet decided if/when it will be enabled. Nevertheless, other AES-256 cipher suites are already enabled in Chrome. I don't think anyone is proposing to remove those from Chrome. MO, we should not remove any AES-256 cipher suites from Firefox/NSS. I would agree with the proposal to reorder them, however, and prioritize AES-GCM over AES-CBC. Since application developers may have different opinions about priority order of cipher suites, I think it would be helpful to implement the following 2 NSS ERs which I filed recently : https://bugzilla.mozilla.org/show_bug.cgi?id=1267894 https://bugzilla.mozilla.org/show_bug.cgi?id=1267896 Only the first one is related to Firefox, but both are related. There are other considerations to take into account other than "strength". Indeed, and those considerations might be application-specific, or hardware-specific, which is why I think the above 2 ERs make sense to implement. When it comes to signature algorithms and curves, IMO, there should be some runtime support for configuring them and prioritizing them. Right now, AFAIK, we don't have any kind of runtime configuration for either. Both are hardcoded at compile-time. IMO, it is time for this to change. We should have at the very least runtime APIs to to enable/disable curves and enable/disable signature algorithms. Several other libraries already offer this. Preferably, we should also have a configurable ordered list for those, as I'm proposing we add for cipher suites. Julien -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cipher suits, signature algorithms, curves in Firefox
Brian Smith wrote: > A lot of people have interpreted what I wrote as saying AES-256 is bad. I was not really referring to what you wrote about AES-256. I was referring to for example https://eprint.iacr.org/2009/374 . Even though those are related key attacks (which should not be relevant to *proper* implementation in TLS), it gets people worried about the constructions in AES-256 compared to AES-128. We should be moving away from AES as it is currently standardized, due it's small number of rounds anyway (the internal NSA version of AES uses a larger number of rounds). > the larger key size helps w.r.t. quantum computers. If quantum computers are currently on the level of breaking AES-128, then they are on the level of breaking any asymmetric cryptography (RSA, DHE or ECDHE key exchange) we are using - which makes support for AES-256 moot. Moving away from AES-256 will put even more pressure on the crypto community to come up with a solution as opposed to the *relative* complacency we are seeing now. > the larger key size helps in preventing some multi-user attacks. Given relatively widespread hardware acceleration, it makes no difference regarding AES-128 compared to AES-256. > Even if we think that these merits are small, others do dot think they are > small. And as is too often the case, people get crypto wrong :) > and so there will always be websites that prefer AES-256. Websites that prefer AES-256, such as internal websites, can always instruct their users/customers to toggle a switch in Firefox to enable AES-256. I am proposing having AES-256 ciphersuits toggled off by default. > Also, with AES-NI and similar optimizations on CPUs, AES-256 is not too much > slower than AES-128. My concerns are not much with respect to performance. AES-NI are common on desktops, but most mobile devices are not yet ARMv8 so they don't get hardware acceleration. > the ECDHE-AES-256-GCM cipher suites should be added to Firefox. They will be added to NSS, just to have support for them. The question is whether they will be toggled on by default in Firefox. > they were just recently added to Google Chrome. It was discussed on the Chrome mailing list. They are not yet enabled by default in Chrome stable, it is not yet decided if/when it will be enabled. > if people want non-ECC DHE cipher suites, then at a minimum we need to define > new cipher suite IDs. What is likely happening is new TLS extension to advertise support for that. In the meantime, we should not support DHE - note that Chrome stable currently does not advertise support for DHE ciphersuits (but they have a fallback mechanism). > There are other considerations to take into account other than "strength". True. My proposal is just something to change in the meantime while waiting for TLSv1.3. Most of these suggestions would help with a smoother transition to TLSv1.3 once it's out. Regarding the signature algorithms, supporting the ones that Chrome supports and ordering them the same way can help with hard-to-track-down compatibility issues, while we wait for TLSv1.3. Personally, I would even get rid of the SHA512 algorithms, but removing those does break *few* not *none* websites. > Is your test data set and code available somewhere? It sounds interesting. I will put in a request with legal on Monday to get the code opensourced and data publicly available. It will have to be redacted though, because it contains TLS applications that are accessible over the internet, but likely should not be public (such as many mailservers, xmpp servers, irc servers, webcams, and other applications running on non-standard ports). I used a subset of the data, only considering TLS servers running on TCP port 443, with a properly resolving DNS name, with a valid certificate for that domain (valid and trusted according to Firefox 45esr). In this subset of data, no new handshake errors were introduced by my proposed changes. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cipher suits, signature algorithms, curves in Firefox
On Fri, May 6, 2016 at 10:12 AM, Peter Bowen wrote: > Is a reasonable path to implement > https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-10 and > treat ECDHE suites as being DHE using a Supported Group? This would > avoid new cipher suite IDs and accomplish the same result. I'm implementing it now. Not because we need it for TLS 1.2 (where it's not clear that it is 100% safe), but because we need it for TLS 1.3. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cipher suits, signature algorithms, curves in Firefox
On Fri, May 6, 2016 at 9:33 AM, Brian Smith wrote: > So, I don't think that dropping AES-256 is the right thing to do. Instead, > the ECDHE-AES-256-GCM cipher suites should be added to Firefox. Note that > they were just recently added to Google Chrome. These are also coming to NSS, likely in 3.25 (Firefox 49 if everything goes to plan). Supporting different PRF hashes (we need SHA-384 for those suites) turns out to be a little bit intrusive. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cipher suits, signature algorithms, curves in Firefox
On Thu, May 5, 2016 at 4:33 PM, Brian Smith wrote: > Zoogtfyz wrote: >> >> 3) DHE (not ECDHE) cipher suits are far too often implemented incorrectly, >> most often with default common DH primes, DH parameter reuse, or generally >> weak bitstrenght (equivalent to 1024bit RSA, which is already considered >> insecure in Firefox). Hence it's better to remove support for DHE (not >> ECDHE) cipher suits rather than give false sense of security. >> > > I agree. I think if people want non-ECC DHE cipher suites, then at a > minimum we need to define new cipher suite IDs for them that imply keys of > at least 2048 bits. Unless/until that happens, they are more trouble than > they are worth. > > Note that Chrome recently reached the same conclusion. Is a reasonable path to implement https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-10 and treat ECDHE suites as being DHE using a Supported Group? This would avoid new cipher suite IDs and accomplish the same result. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cipher suits, signature algorithms, curves in Firefox
Zoogtfyz wrote: > This is my recommendation for changes to the supported ciphersuits in > Mozilla Firefox. I performed rigorous compatibility testing and everything > works as advertized. I used Firefox telemetry data, SSL Pulse data, and my > own tests to verify that *not a single* publicly accessible website would > get handshake errors compared to today. > Awesome. > > Reasoning: > 1) Too many people put 256bit CBC cipher suits at higher priority than > 128bit AEAD cipher suits because they don't know what they are doing. > Agreed. > 2) 256bit AES cipher suits have known issues compared to 128bit AES cipher > suits. It is not well studied yet how much those issues apply to the cipher > suit implementation in TLS. Given that 256bit GCM cipher suits will not be > added to Firefox, it is better to disable 256bit AES cipher suits > completely. > When I the part of https://briansmith.org/browser-ciphersuites-01 regarding AES-256, I didn't do a good job. A lot of people have interpreted what I wrote as saying AES-256 is bad or worse cryptographically than AES-128. That isn't what I meant to write. AES-256 still has some significant advantages over AES-128. In particular, the larger key size helps w.r.t. quantum computers. Further, the larger key size helps in preventing some multi-user attacks. Even if we think that these merits are small, others do not think they are small, and so there will always be websites that prefer AES-256. Also, with AES-NI and similar optimizations on CPUs, AES-256 is not too much slower than AES-128. So, I don't think that dropping AES-256 is the right thing to do. Instead, the ECDHE-AES-256-GCM cipher suites should be added to Firefox. Note that they were just recently added to Google Chrome. > 3) DHE (not ECDHE) cipher suits are far too often implemented incorrectly, > most often with default common DH primes, DH parameter reuse, or generally > weak bitstrenght (equivalent to 1024bit RSA, which is already considered > insecure in Firefox). Hence it's better to remove support for DHE (not > ECDHE) cipher suits rather than give false sense of security. > I agree. I think if people want non-ECC DHE cipher suites, then at a minimum we need to define new cipher suite IDs for them that imply keys of at least 2048 bits. Unless/until that happens, they are more trouble than they are worth. Note that Chrome recently reached the same conclusion. > Additionally, Firefox 45esr currently supports these signature algorithms > in this ordering: > SHA256/RSA, SHA384/RSA, SHA512/RSA, SHA1/RSA, SHA256/ECDSA, SHA384/ECDSA, > SHA512/ECDSA, SHA1/ECDSA, SHA256/DSA, SHA1/DSA > > I recommend changing it to these in this ordering: > SHA512/ECDSA, SHA512/RSA, SHA384/ECDSA, SHA384/RSA, SHA256/ECDSA, > SHA256/RSA, SHA1/ECDSA, SHA1/RSA > I suggest you read the text that Google's David Benjamin added to the TLS 1.3 draft regarding this. Also, see https://groups.google.com/d/msg/mozilla.dev.security.policy/smAUN2Rtc78/EuQoSyvmAwAJ where I argued something similar. Reasoning: > 1) *not a single* publicly accessible website uses DSA (not ECDSA) > signatures anymore. I agree DSA should be dropped > 3) Ordering from strongest to weakest, as opposed to what it is today. > There are other considerations to take into account other than "strength", as David Benjamin's proposal and my suggestion linked above show. > Additionally, Firefox 45esr currently supports these elliptic curves in > this ordering: > secp256r1, secp384r1, secp521r1 > > I recommend removing support for secp521r1 since it is not supported in > the wild, Chrome does not support it, and we should be moving away from > secp curves to e.g. x25519. Once again, *not a single* publicly accessible > website breaks with this change. > I agree. See https://bugzilla.mozilla.org/show_bug.cgi?id=1128792. Is your test data set and code available somewhere? It sounds interesting. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cipher suits, signature algorithms, curves in Firefox
On 05/05/16 15:22, Zoogtfyz wrote: > This is my recommendation for changes to the supported ciphersuits in > Mozilla Firefox. I performed rigorous compatibility testing and > everything works as advertized. I used Firefox telemetry data, SSL > Pulse data, and my own tests to verify that *not a single* publicly > accessible website would get handshake errors compared to today. We went through the process of evaluating this 1-2 years ago; I recall Brian Smith was involved. If people can dig up the old messages or bugs, it would make it easier to interact with new suggestions. Gerv -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Cipher suits, signature algorithms, curves in Firefox
This is my recommendation for changes to the supported ciphersuits in Mozilla Firefox. I performed rigorous compatibility testing and everything works as advertized. I used Firefox telemetry data, SSL Pulse data, and my own tests to verify that *not a single* publicly accessible website would get handshake errors compared to today. Firefox 45esr currently supports these ciphersuits in this ordering: C02B TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 C02F TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 C00A TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA C009 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA C013 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA C014 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 0033 TLS_DHE_RSA_WITH_AES_128_CBC_SHA 0039 TLS_DHE_RSA_WITH_AES_256_CBC_SHA 002F TLS_RSA_WITH_AES_128_CBC_SHA 0035 TLS_RSA_WITH_AES_256_CBC_SHA 000A TLS_RSA_WITH_3DES_EDE_CBC_SHA I recommend changing it to these in this ordering: C02B TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 C02F TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 C009 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA C013 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 002F TLS_RSA_WITH_AES_128_CBC_SHA 000A TLS_RSA_WITH_3DES_EDE_CBC_SHA Reasoning: 1) Too many people put 256bit CBC cipher suits at higher priority than 128bit AEAD cipher suits because they don't know what they are doing. 2) 256bit AES cipher suits have known issues compared to 128bit AES cipher suits. It is not well studied yet how much those issues apply to the cipher suit implementation in TLS. Given that 256bit GCM cipher suits will not be added to Firefox, it is better to disable 256bit AES cipher suits completely. 3) DHE (not ECDHE) cipher suits are far too often implemented incorrectly, most often with default common DH primes, DH parameter reuse, or generally weak bitstrenght (equivalent to 1024bit RSA, which is already considered insecure in Firefox). Hence it's better to remove support for DHE (not ECDHE) cipher suits rather than give false sense of security. 4) Additionally, once chacha20 lands in Firefox, move it to top. If we wanted to be even more strict, we could change the supported cipher suits to these in this order: C02B TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 C02F TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 002F TLS_RSA_WITH_AES_128_CBC_SHA 000A TLS_RSA_WITH_3DES_EDE_CBC_SHA Reasoning: 1) Still *not a single* publicly accessible website gets handshake errors compared to today - because we still have the two backwards compatible cipher suits. (002f and 000a). 2) It puts additional pressure on server operators to support AEAD cipher suits if they want ECDHE ciphersuits. Overall, this once again limits the number of ciphersuits in the wild, and makes it easier to remove supported weak ciphersuits from server applications. Additionally, Firefox 45esr currently supports these signature algorithms in this ordering: SHA256/RSA, SHA384/RSA, SHA512/RSA, SHA1/RSA, SHA256/ECDSA, SHA384/ECDSA, SHA512/ECDSA, SHA1/ECDSA, SHA256/DSA, SHA1/DSA I recommend changing it to these in this ordering: SHA512/ECDSA, SHA512/RSA, SHA384/ECDSA, SHA384/RSA, SHA256/ECDSA, SHA256/RSA, SHA1/ECDSA, SHA1/RSA Reasoning: 1) *not a single* publicly accessible website uses DSA (not ECDSA) signatures anymore. 2) This brings it in line with Chrome. 3) Ordering from strongest to weakest, as opposed to what it is today. Additionally, Firefox 45esr currently supports these elliptic curves in this ordering: secp256r1, secp384r1, secp521r1 I recommend removing support for secp521r1 since it is not supported in the wild, Chrome does not support it, and we should be moving away from secp curves to e.g. x25519. Once again, *not a single* publicly accessible website breaks with this change. Thank you for your consideration. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto