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
