Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
Am Montag, 3. Februar 2014 22:50:38 UTC+1 schrieb Chris Newman: As a non-Firefox/non-HTTP consumer of NSS, I'd like to see an NSS API flag indicating a cipher suite is retained for backwards compatibility but considered inferior by cryptographic community standards at the time the NSS library was built. Yes, awesome. That's the NSS-equivalent of my proposal. Basically, there should be a definition for ciphers that says ok or weak, exposed via API. A. is unacceptable because it breaks copy/paste of URLs Copy/paste does some magic here (Firefox currently does not show http://; but copies the complete URL string). B. For UI, I'd suggest a ? over the padlock rather than a red bar. The community believes RC4 may be vulnerable to high-skill attackers and is likely to become more vulnerable to other attackers over time. That's questionable security, not no security. It's still a lot better than unencrypted (which is what you get if you remove RC4 prematurely). Hmm, good point. You have to think about your friend's parents, though, any not-entirely-obvious UI (even if it is actually correct) may confuse people. But let's leave that to the UI team. My sketch was for illustratory purposes only. C. The https URI scheme specifies the protocol not the policy so it technically does not imply the connection is or will be secure. But I agree this is non-obvious to at least some users and prefer option B. Most people are trained to look for https: on banking sites (because they were told that's how they identify a secure connection), so they may not see that the security on that connection is weak. But again, UI is for UI team. ;) Regardless, I think NSS should provide the flag, and Firefox can design the UI. Yes, I agree. Best regards, Florian Bender -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
Hi folks, there is consensus that some algorithms/ciphers (e.g. RC4) allowed by default should not be considered secure, though because of interop issues, they cannot be removed at this point. The problem with this is that people may think they are using a secure connection while in fact, someone could eavedrop. To reduce the impact of this problem, I propose to implement a visual indicator for when a connection should not be considered secure. The goal is not to show an OMG-BEWARE message but instead to not show a (falsy) secure indicator. Currently, there is a padlock shown for HTTPS connections in Firefox (see first part of [1]). For insecure (but encrypted connections), there are three options: A. Make it look like an HTTP connection: No padlock but the world icon, no https: string. B. Indicate a broken padlock (e.g. with a big fat red bar crossing the padlock), show the https: string (like in the second part of [2]). C. Make it look like an HTTP connection but not lie about the protocol: Use the globe icon but show the https: string (like part 3 of [1]). (A) is lying but mostly obvious, i.e. it says that the user is not on an encrypted connection and should act accordingly. (C) is non-obvious because the globe can mean anything and the https: may confuse / mislead people who are used to looking for this string. (B) may not be completely obvious but it shows that there is something wrong although you are on an encrypted connection - I prefer this last option. I understand that this is not dev.firefox but I think this is a solution that most can live with for the foreseeable future (this is no long-term solution!). Do you agree? (The UI resolution can also be adopted for HTTP/2.0 unauthenticated HTTPS, and on any connection where the user bypassed any blocking mechanism, e.g. for failed cert checks. It may require changes to the identity panel as well to explain why the connection is shown as unencrypted.) Best regards, Florian Bender [1] http://imgur.com/C6wOlRm Am Samstag, 14. Dezember 2013 07:48:01 UTC+1 schrieb marlen...@hushmail.com: I present a proposal to remove some vulnerable/deprecated/legacy TLS ciphersuits from Firefox. I am not proposing addition of any new ciphersuits, changing of priority order, protocol removal, or any other changes in functionality. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
As a non-Firefox/non-HTTP consumer of NSS, I'd like to see an NSS API flag indicating a cipher suite is retained for backwards compatibility but considered inferior by cryptographic community standards at the time the NSS library was built. A. is unacceptable because it breaks copy/paste of URLs B. For UI, I'd suggest a ? over the padlock rather than a red bar. The community believes RC4 may be vulnerable to high-skill attackers and is likely to become more vulnerable to other attackers over time. That's questionable security, not no security. It's still a lot better than unencrypted (which is what you get if you remove RC4 prematurely). C. The https URI scheme specifies the protocol not the policy so it technically does not imply the connection is or will be secure. But I agree this is non-obvious to at least some users and prefer option B. Regardless, I think NSS should provide the flag, and Firefox can design the UI. - Chris --On February 3, 2014 8:49:27 -0800 florian.ben...@quantumedia.de wrote: Hi folks, there is consensus that some algorithms/ciphers (e.g. RC4) allowed by default should not be considered secure, though because of interop issues, they cannot be removed at this point. The problem with this is that people may think they are using a secure connection while in fact, someone could eavedrop. To reduce the impact of this problem, I propose to implement a visual indicator for when a connection should not be considered secure. The goal is not to show an OMG-BEWARE message but instead to not show a (falsy) secure indicator. Currently, there is a padlock shown for HTTPS connections in Firefox (see first part of [1]). For insecure (but encrypted connections), there are three options: A. Make it look like an HTTP connection: No padlock but the world icon, no https: string. B. Indicate a broken padlock (e.g. with a big fat red bar crossing the padlock), show the https: string (like in the second part of [2]). C. Make it look like an HTTP connection but not lie about the protocol: Use the globe icon but show the https: string (like part 3 of [1]). (A) is lying but mostly obvious, i.e. it says that the user is not on an encrypted connection and should act accordingly. (C) is non-obvious because the globe can mean anything and the https: may confuse / mislead people who are used to looking for this string. (B) may not be completely obvious but it shows that there is something wrong although you are on an encrypted connection - I prefer this last option. I understand that this is not dev.firefox but I think this is a solution that most can live with for the foreseeable future (this is no long-term solution!). Do you agree? (The UI resolution can also be adopted for HTTP/2.0 unauthenticated HTTPS, and on any connection where the user bypassed any blocking mechanism, e.g. for failed cert checks. It may require changes to the identity panel as well to explain why the connection is shown as unencrypted.) Best regards, Florian Bender [1] http://imgur.com/C6wOlRm Am Samstag, 14. Dezember 2013 07:48:01 UTC+1 schrieb marlen...@hushmail.com: I present a proposal to remove some vulnerable/deprecated/legacy TLS ciphersuits from Firefox. I am not proposing addition of any new ciphersuits, changing of priority order, protocol removal, or any other changes in functionality. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Monday, January 27, 2014 4:35:34 PM UTC-7, Brian Smith wrote: On Mon, Jan 27, 2014 at 10:49 AM, ripber...@aol.com wrote: On Monday, January 27, 2014 10:52:44 AM UTC-7, Brian Smith wrote: On Mon, Jan 27, 2014 at 9:26 AM, ripber...@aol.com wrote: Thanks much Brian and Alan for the links - and the 800-52 reference which I haven't read yet. FIPS 140-2 certification is not fun. It probably takes a consultant and about a year to get a binary approved and if you change it, it has to be re-certified. Most folks seem to be content that your crypto-library is at least derived (i.e. patched) from a version that was certified. Good luck on your efforts there. I'll try to get back to this soon. Cheers, Rick -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On 2014-01-27 02:43, ripber...@aol.com wrote: Hi, So I didn't get to the bottom of this thread because some of it is 'loading' I really recommend that you do read all the messages. All of this has been discussed in various thread both here and on other lists. Encryption: AES-256 - 256 bit AES-192 - 192 bit AES-128 - 128 bit Triple-Key Triple DES (3DES) - 112 bit (NOTICE: No Camilla, RC4, SEED, DES or 2DES). Other recommendations don't not recommend 3DES, but do recommend Camellia. The reason to have RC4 and 3DES enabled is that there are servers that do not support AES and only support either RC4 or 3DES. Actually running with RC4 disabled makes me run into some of those sites. Digital Signature Generation: DSA with p=2048, q=224 - 112 bit RSA with n=2048 - 112 bit EC-DSA with n224- 112 bit This generally affects what type of certifcates you need. Notice RSA-2048 now required (no RSA-1024). Following CA/Browser baseline requirements, everything should now be 2048 bit or more, but some CAs aren't ready for this. 1024 bits is now below 1%. I think all ECDSA are 256 bit or more, and DSA isn't used. Hash Functions: Digital Signature Generation: SHA-224: 112 bit SHA-256: 128 bit SHA-384: 192 bit SHA-512: 256 bit (NOTICE: No MD5, no SHA-1) Please note that both MD5 and SHA-1 still have a preimage resistance of = 112 bit, but their collision resistance isn't that good. That means in an HMAC they can perfectly be used. A Suite B TLS client configured at a minimum level of security of 128 bits MUST offer the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 or the We do not have a minimum level of 128. As you say yourself, 112 bit is enough. I'd suggest you follow NIST 800-131a, but if not at least give a configuration switch to drop NON-FIPS algorithms. From the above list, I'd drop the RC4, MD5 and CAMELLIA options - at least if a FIPS configuratoin switch is activated. Better - no switch and drop them. If you have to included them for some reason - put them at the bottom if the preference list. 3DES, RC4 and MD5 are actually at the bottom of the list. I think in general, you could say the shorter the key or hash, the faster it runs, so if all you are trying to get to as 112 bit security (all that is required in 2014), I'd consider preferring suites with AES_128 encryption and SHA MACs over AES_256 or SHA-256 or SHA-384. We prefer GCM, and AES128 over AES256. But GCM doesn't use a HMAC and so needs SHA256. 3DES is still acceptable for 2014. It's still in the list. The following suite is the MANDATORY suite required by TLS 1.1 (RFC 4346). If you are going to allow the browser to enable TLS 1.1, you should make sure this is enabled when TLS 1.1 is enabled. There's also no reason to take it out if the minimum security protocol is TLS 1.2 - just leave it at the bottom as you have it. 000A TLS_RSA_WITH_3DES_EDE_CBC_SHA So maybe you could argue that if we do a fall back from TLS 1.2 to 1.1 that it should be included. But RFC 4346 is obsolete, and I don't see any real problems with dropping it. The following suite is the MANDATORY suite required by TLS 1.0 (RFC 2246). If you are going to allow the browser to enable TLS 1.0, you should probably make sure this is enabled when TLS 1.0 is enabled. There's also no reason to take it out if the minimum security protocol is TLS 1.1 or TLS 1.2 - just leave it at the bottom as you have it. This is less important since I don't think DSA certrificates are much used. 0013 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA Also obsolete. I'm also not sure why you aren't supporting: C0 08 - TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA 00 13 - TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 00 16 - TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA If the answer is no one uses them or not in NSS - that's fine. However they would be OK for NIST 800-131a. 3DES is slow, support should be removed, no point in adding support for it anymore, you should move to AES or Camellia. Might also ask why you didn't include any DH key negotiation cipher suites (e.g. C004, C003, 0031, 0030, 000D, 0010) It's OK for the server to have a static DH key provided the client uses an ephemeral DH key. If the answer is no one uses them or not in NSS - that's fine. However the above ones would be OK for NIST 800-131a. static (EC)DH keys do not offer forward security. They do cause you to spend more time on the key exchange. So what is the advantage of them? Not sure why you included C02B and C02F or why they are at the top. The SHA-256 is overkill for 2014 - I know if you want GCM - it only comes with at least SHA-256. I haven't researched GCM vs CBC. My first take would be you don't need them - but there might be some reason to include and maybe even to put first. C02B does
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Monday, January 27, 2014 6:19:42 AM UTC-7, Kurt Roeckx wrote: I really recommend that you do read all the messages. All of this has been discussed in various thread both here and on other lists. Ok - I will try (but it will be after this post). Other recommendations don't not recommend 3DES, but do recommend Camellia. The reason to have RC4 and 3DES enabled is that there are servers that do not support AES and only support either RC4 or 3DES. Actually running with RC4 disabled makes me run into some of those sites. So a few things: 1) I understand 3DES doesn't perform well. You could push them further down in the preference list if you want to 'not recommend' them more. You could remove them all together if there are no legacy servers that use it - but I assume there are. 2) NIST is a US government standards board that drives a lot of compliance regulation. There are companies what will want to be able show that they are NIST compliant. The standard at this point does NOT allow you to use Camellia. So there should be some way to configure the browser so that it uses only FIPS approved algorithms (i.e. NOT CAMELLIA). Otherwise you're probably going to be getting the same sort of feedback about I can't use Firefox because it cannot be made NIST 800-131a compliant that you got about I can't use Firefox because it does not support TLS 1.2. 3) NIST/FIPS may eventually allow Camellia. Some folks may want to use it. Some sites may support it and not support AES. There are reasons to probably allow Camellia and that should probably be the default for Firefox general users. However, I would put Camellia lower in the preference list than AES suites (IMHO). 4) I think the flaws in the TLS 1.1 CBC definition (no random IV) drove folks away from AES and to use RC4 - it was the best thing left in TLS 1.1 - or Camellia which is probably as good or better than AES though rather new and therefore risky - but better than a broken AES-CBC implementation. 5) I'm trying to tell you what the standard says - not whether I agree with it. I don't get to pick. The standard does not allow Camellia (because it is too new). But the standard does support and justify taking away the set of suites that Marlen suggested. I was just giving a more explicit rational for dropping them. Digital Signature Generation: RSA with n=2048 - 112 bit This generally affects what type of certifcates you need. Notice RSA-2048 now required (no RSA-1024). Following CA/Browser baseline requirements, everything should now be 2048 bit or more, but some CAs aren't ready for this. 1024 bits is now below 1%. I think all ECDSA are 256 bit or more, and DSA isn't used. The standard is telling you what you should use, not whether anyone does or not support it. The standard is saying everyone should already be at 112 security bit strength now. Agree you might as well ignore DSA if no one implemented it which means you can forget about TLS_DH, TLS_DHE_DSS suites. I understand some sites may not use RSA-2048 keys in certificates. However using RSA-1024 bit keys has only 80 bits of security strength which is no longer secure (NIST worries about it saying secure for say another 20 years). Even worse than RSA-1024 I suspect will be the use of SHA-1 in certificate signatures. The client is not obligated to enforce NIST 800-131a. But I would suggest two things: 1) There should be a visible indication whenever a web site ends up with a connections that has less than 112 bit security. Perhaps even ask the user if he really wants to connect to a site with 'weak' security. This might motivate some of these sites to fix their security. 2) There should be a configuration control to block connection to a weak sites period. Weak = See description at end of post. Hash Functions: (NOTICE: No MD5, no SHA-1) Please note that both MD5 and SHA-1 still have a preimage resistance of = 112 bit, but their collision resistance isn't that good. That means in an HMAC they can perfectly be used. MD5 is not a FIPS approved algorithm. It has known issues with collision resistance. The NIST 800-131a standard says do not use it - not even in an HMAC. Kind of agree that it should be relatively OK in an HMAC, but any known flaw is a potential attack vector. SHA-1 is 160 bits which as a hash gives it 80 bit security strength. In an HMAC, it has 160 bit security which is fine. The item above is about digital signatures - not MACs - the point is - all those RSA-/SHA-1 signatures on Certificates out there are NOT good. Also using SHA-1 in the TLS signing protocol is not good - and that's what you get even with TLS 1.2 if you don't send a Hash and
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Mon, Jan 27, 2014 at 9:26 AM, ripber...@aol.com wrote: On Monday, January 27, 2014 6:19:42 AM UTC-7, Kurt Roeckx wrote: 2) NIST is a US government standards board that drives a lot of compliance regulation. There are companies what will want to be able show that they are NIST compliant. The standard at this point does NOT allow you to use Camellia. So there should be some way to configure the browser so that it uses only FIPS approved algorithms (i.e. NOT CAMELLIA). Otherwise you're probably going to be getting the same sort of feedback about I can't use Firefox because it cannot be made NIST 800-131a compliant that you got about I can't use Firefox because it does not support TLS 1.2. Camellia may get disabled by default soon. But, RC4 won't get disabled by default soon; we may do what MSIE11 does, but that's not quite the same thing. You can configure Firefox to disable RC4 and Camellia cipher suites using about:config. Search for rc4 and camellia to find those prefs. 5) I'm trying to tell you what the standard says - not whether I agree with it. I don't get to pick. The standard does not allow Camellia (because it is too new). But the standard does support and justify taking away the set of suites that Marlen suggested. I was just giving a more explicit rational for dropping them. No NIST standard is the standard for Firefox. I have sent feedback to NIST about its draft recommendations for TLS, trying to convince them that they should change their guidance to be in line with what web browsers do in their default configurations. However, NIST doesn't dictate what we do. In particular, we won't constrain ourselves to doing only things that NIST 800-131a recommends in the default configuration. However, assuming it isn't too much work, we'll support options that allow you to configure Firefox to conform with NIST guidance. The client is not obligated to enforce NIST 800-131a. But I would suggest two things: 1) There should be a visible indication whenever a web site ends up with a connections that has less than 112 bit security. Perhaps even ask the user if he really wants to connect to a site with 'weak' security. This might motivate some of these sites to fix their security. 2) There should be a configuration control to block connection to a weak sites period. Weak = See description at end of post. This seems like a reasonable suggestion. = 112 bit, but their collision resistance isn't that good. That means in an HMAC they can perfectly be used. MD5 is not a FIPS approved algorithm. It has known issues with collision resistance. The NIST 800-131a standard says do not use it - not even in an HMAC. Kind of agree that it should be relatively OK in an HMAC, but any known flaw is a potential attack vector. There are real compatibility issues with turning off the HMAC-MD5-based cipher suite. However, you can turn it off in about:config; search for md5 SHA-1 is 160 bits which as a hash gives it 80 bit security strength. In an HMAC, it has 160 bit security which is fine. The item above is about digital signatures - not MACs - the point is - all those RSA-/SHA-1 signatures on Certificates out there are NOT good. Also using SHA-1 in the TLS signing protocol is not good - and that's what you get even with TLS 1.2 if you don't send a Hash and Signature Algorithm extension that prohibits SHA-1. It is a good point that we need to change what we do in the TLS handshake when we stop accepting SHA-1 signatures. It may be reasonable to implement a don't accept SHA-1 signatures preference similar to the one we just removed for MD5. I might be wrong, but I thought as long as the client and the server do not BOTH use a static key, then you still have forward perfect secrecy. And I thought the definition in TLS provided for the certificate owner to have a static DH key and for the authenticator to use an ephemeral key when DH or ECDH was used. If this is correct, I'd guess the static key on the server side might save some time. Anyway I'm on shaky ground here perhaps - in my mind, I like it when there are fewer options and clearer choices about what to use. I do notice that the Suite B cipher suites only use ECDHE so that might be some indication that DH or ECDH are not a strategic path. Again - the only point is the standard allows them if there is any reason to support them. I do think that ephemeral-static key exchange is something that we could consider. I even mentioned it in my original proposal: https://briansmith.org/browser-ciphersuites-01.html. However, there are basically zero servers that support it. And BTW - I haven't heard the answer about the Client hello extension for Hash and Signature Algorithm. Does FF send this? Do we know what % of sites tolerate it? We include it in TLS 1.2 client hellos and we include
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Mon, Jan 27, 2014 at 09:26:20AM -0800, ripber...@aol.com wrote: 2) NIST is a US government standards board that drives a lot of compliance regulation. There are companies what will want to be able show that they are NIST compliant. I'm sure it is important to some. But I think it would be more important to get the server to be compliant rather than the client. The client currently has to work in a lot of different environments where it can't be sure that the other end is compliant with those standards. NIST is, like you said, a US government standard, and as such doesn't have any official status outside the US. That doesn't mean that if it has good recommendations that we shouldn't try to follow them. But we have to live in the real world, and it's more complicated. 4) I think the flaws in the TLS 1.1 CBC definition (no random IV) drove folks away from AES and to use RC4 - it was the best thing left in TLS 1.1 - or Camellia which is probably as good or better than AES though rather new and therefore risky - but better than a broken AES-CBC implementation. I think you mean TLS 1.0? 5) I'm trying to tell you what the standard says - not whether I agree with it. I don't get to pick. The standard does not allow Camellia (because it is too new). But the standard does support and justify taking away the set of suites that Marlen suggested. I was just giving a more explicit rational for dropping them. AES is from 1998, Camellia from 2000. I wouldn't call that too new. But it is used less. Digital Signature Generation: RSA with n=2048 - 112 bit This generally affects what type of certifcates you need. Notice RSA-2048 now required (no RSA-1024). Following CA/Browser baseline requirements, everything should now be 2048 bit or more, but some CAs aren't ready for this. 1024 bits is now below 1%. I think all ECDSA are 256 bit or more, and DSA isn't used. The standard is telling you what you should use, not whether anyone does or not support it. The standard is saying everyone should already be at 112 security bit strength now. Agree you might as well ignore DSA if no one implemented it which means you can forget about TLS_DH, TLS_DHE_DSS suites. I understand some sites may not use RSA-2048 keys in certificates. However using RSA-1024 bit keys has only 80 bits of security strength which is no longer secure (NIST worries about it saying secure for say another 20 years). Even worse than RSA-1024 I suspect will be the use of SHA-1 in certificate signatures. The CA/Browser requirements are good in changing the certificates being generated. It resulted in the 1024 bits keys going from 10% last year to 1% now, and with the current rate should be near 0% in a few months. I would also like to see them to change the SHA-1 requirement to SHA-2, and some CAs are working on that. But there seems to be existing software that still can't handle it. SHA-1 is known to be only providing about 60 bit of security for a collision attack, which is a problem. To make it more hard the CAB requirements state that the CA should add at least 20 bit of entropy and at least some people say that that is not enough. The client is not obligated to enforce NIST 800-131a. But I would suggest two things: 1) There should be a visible indication whenever a web site ends up with a connections that has less than 112 bit security. Perhaps even ask the user if he really wants to connect to a site with 'weak' security. This might motivate some of these sites to fix their security. 2) There should be a configuration control to block connection to a weak sites period. Weak = See description at end of post. You can actually disable things like MD5, RC4 and 3DES and set the minimum version to TLS 1.2. You will just run into many sites that just don't work. It will show you that it's weak or strong if you first click the icon and press more info. Not sure on what that is based. I think in general, you could say the shorter the key or hash, the faster it runs, so if all you are trying to get to as 112 bit security (all that is required in 2014), I'd consider preferring suites with AES_128 encryption and SHA MACs over AES_256 or SHA-256 or SHA-384. We prefer GCM, and AES128 over AES256. But GCM doesn't use a HMAC and so needs SHA256. There's not much point in having one algorithm with more security than another - the least secure algorithm determines the security level of the implementation and the higher security algorithm just burns performance. AES-128 and SHA-256 hashes are same strength. AES-192 and SHA-384 hashes are same strength. AES-256 and SHA-512 hashes are the same strength. For 112 bit security strength - AES-128 is sufficient so don't need
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Monday, January 27, 2014 10:52:44 AM UTC-7, Brian Smith wrote: On Mon, Jan 27, 2014 at 9:26 AM, ripber...@aol.com wrote: On Monday, January 27, 2014 6:19:42 AM UTC-7, Kurt Roeckx wrote: 2) NIST is a US government standards board that drives a lot of compliance regulation. There are companies what will want to be able show that they are NIST compliant. The standard at this point does NOT allow you to use Camellia. So there should be some way to configure the browser so that it uses only FIPS approved algorithms (i.e. NOT CAMELLIA). Otherwise you're probably going to be getting the same sort of feedback about I can't use Firefox because it cannot be made NIST 800-131a compliant that you got about I can't use Firefox because it does not support TLS 1.2. Camellia may get disabled by default soon. But, RC4 won't get disabled by default soon; we may do what MSIE11 does, but that's not quite the same thing. You can configure Firefox to disable RC4 and Camellia cipher suites using about:config. Search for rc4 and camellia to find those prefs. Camellia disabled by default - I'd say this is appropriate. Ability to disable RC4 and Camellia - I'd say this was sufficient. I believe that folks are using RC4 to get around the broken AES-CBC implementation in TLS 1.1. That should revert back to using AES-CBC once they are on TLS 1.2 (in an ideal world) - but in the short term - I agree - you are stuck with defaulting to enabling, hopefully at the bottom of the preference order. 5) I'm trying to tell you what the standard says - not whether I agree with it. I don't get to pick. The standard does not allow Camellia (because it is too new). But the standard does support and justify taking away the set of suites that Marlen suggested. I was just giving a more explicit rational for dropping them. No NIST standard is the standard for Firefox. I can't speak for FF - and I've certainly read enough standards to say that there are too many standards. I do think that the IETF does listen to NIST however. And if you care about security, the security of your implementation is a function of the cryptographic algorithms used. So I'd suggest that NIST is telling FF and everyone else where they should be to be secure. That being said, the reality of rolling forward to a new security level in the real world is much more of a random walk through the park. I appreciate your consideration of my comments. I have sent feedback to NIST about its draft recommendations for TLS, trying to convince them that they should change their guidance to be in line with what web browsers do in their default configurations. However, NIST doesn't dictate what we do. In particular, we won't constrain ourselves to doing only things that NIST 800-131a recommends in the default configuration. However, assuming it isn't too much work, we'll support options that allow you to configure Firefox to conform with NIST guidance. That is as good as I could have hoped for Brian. I'll tell you that (for work reasons) I've had to try to decipher between all the standards what is needed for security compliance. It is much more messy than I had hoped. I have to fault the standards groups for not making it more obvious. If you understand what it is saying, NIST 800-131a is actually pretty clear on what it recommends and why; and it points to other standards that do some of the explaining. However, it would have been very helpful if they had actually bothered in an appendix to indicate all the cipher suites that are OK (for TLS and IPSEC). This might have motivated other standards groups to update other standards and perhaps help more implementors make good choices. I can't even assure you that everything I'm saying is correct - but I think I've got enough background to provide an educated opinion on some of this stuff. I will say this though. NIST's guide line is about achieving a specific security level that they feel is needed at a given period of time. This has nothing to do with what is out in the real world - it has to do with getting the real world to go where it needs to go. I would like to hear more about what you are recommending NIST do to align with default configurations (perhaps something for a separate email). I work on some server implementations and have an equivalent problem of trying to figure out if I limit the server to be NIST compliant - will it work with any existing browsers? If everyone could get on the same page about what we need to do now and what we need to do soon, we probably wouldn't be having this discussion. It would be good if the IETF wrote some standards to obsolete stuff that is not used and tell folks to get off stuff that is known to be not secure. Perhaps it is a work in progress - it's hard to
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On 27/01/14 17:26, ripber...@aol.com wrote: 2) NIST is a US government standards board that drives a lot of compliance regulation. There are companies what will want to be able show that they are NIST compliant. The standard at this point does NOT allow you to use Camellia. So there should be some way to configure the browser so that it uses only FIPS approved algorithms (i.e. NOT CAMELLIA). https://developer.mozilla.org/en/docs/NSS/FIPS_Mode_-_an_explanation -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Mon, Jan 27, 2014 at 10:49 AM, ripber...@aol.com wrote: On Monday, January 27, 2014 10:52:44 AM UTC-7, Brian Smith wrote: On Mon, Jan 27, 2014 at 9:26 AM, ripber...@aol.com wrote: I can't speak for FF - and I've certainly read enough standards to say that there are too many standards. I do think that the IETF does listen to NIST however. And if you care about security, the security of your implementation is a function of the cryptographic algorithms used. So I'd suggest that NIST is telling FF and everyone else where they should be to be secure. That being said, the reality of rolling forward to a new security level in the real world is much more of a random walk through the park. I appreciate your consideration of my comments. NIST is one input into the IETF process, and NIST and IETF are both inputs into our decision making. We also help IETF and NIST to update their proposed standards. There is currently work going on at the IETF to define best practices for TLS, including recommended cipher suites, recommended TLS versions to support, and recommended features to support. However, I suspect that those recommendations will written such that they define the minimum set of functionality that a good implementation should support. I suspect they won't fully define what an application like Firefox has to do to be simultaneously secure and backward-compatible. The good news, though, is that things are getting better all around, AFAICT. If you understand what it is saying, NIST 800-131a is actually pretty clear on what it recommends and why; and it points to other standards that do some of the explaining. However, it would have been very helpful if they had actually bothered in an appendix to indicate all the cipher suites that are OK (for TLS and IPSEC). You should look at the SP800-52 draft, which more clearly specifies how NIST recommends that TLS applications work. http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-52-Rev.%201. I would like to hear more about what you are recommending NIST do to align with default configurations (perhaps something for a separate email). I will send my feedback regarding the NIST SP800-52 draft to this mailing list in a separate thread. It would be good if the IETF wrote some standards to obsolete stuff that is not used and tell folks to get off stuff that is known to be not secure. Perhaps it is a work in progress - it's hard to keep up. Even better if they had more implementation guidelines for implementors. IETF is currently working on BCP documents to define best practices for the use of TLS in applications, including web browsers and web servers. I recommend that you subscribe to the IETF UTA and TLS working group mailing lists: https://tools.ietf.org/wg/uta/ https://www.ietf.org/mailman/listinfo/uta https://tools.ietf.org/wg/tls/ https://www.ietf.org/mailman/listinfo/tls Also, the HTTP working group at IETF has added some improved minimum requirements for the use of TLS by HTTP/2 clients and servers, based on feedback from Mozilla, Google, and others. See http://http2.github.io/http2-spec/index.html#TLSUsage A control to stop accepting SHA-1 signatures would be desirable. I would say for the forseeable future, it would have to default to off - I'll give you odds that 90% of the certificates still have SHA-1. Agreed. You may be interested in https://bugzilla.mozilla.org/show_bug.cgi?id=942515 which is about a way for transitioning away from SHA-1 without breaking backward compatibility. So perhaps I'll try to make an offer here. I really like FF's ideology. I'd like to try to put together a set of 'guidelines' for configuring it to be NIST 800-131a compliant - e.g. describe what configuration controls are necessary. I think you've told me most of that above - though I think there were a few other things in the list to check out. I'll take that offline from this chat. It's something I could use in my environment. It might be something that would be useful to others as a reference. It would be great if you could write this up. Please start a new thread with your initial submission. I think one issue you may run into is that Firefox's current version of NSS isn't FIPS-140 validated. You may find the following useful: http://kb.mozillazine.org/Security.tls.version.* https://developer.mozilla.org/en/docs/NSS/FIPS_Mode_-_an_explanation Note that the FIPS Mode - an explanation and the support.mozilla.org article it links to are somewhat outdated. Also, I recommend that you write your document for Firefox 27 and later, because Firefox 27 makes substantial changes to the default TLS configuration of Firefox, including enabling TLS 1.2 and AES-GCM by default. Thanks! Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
Hi, So I didn't get to the bottom of this thread because some of it is 'loading' but I didn't see any mention of NIST 800-131a in all the posts I saw. This standard (along with NIST 800-57 Part 1) provides information about security strength and what is required. Basically NIST is saying you should have at least 112 bit security by 2014 and that this is generally acceptable to 2031. They also say that you have to use FIPS approved algorithms. The list of approved algorithms and related security strength as related to TLS cipher suites and certificates: Encryption: AES-256 - 256 bit AES-192 - 192 bit AES-128 - 128 bit Triple-Key Triple DES (3DES) - 112 bit (NOTICE: No Camilla, RC4, SEED, DES or 2DES). Digital Signature Generation: DSA with p=2048, q=224 - 112 bit RSA with n=2048 - 112 bit EC-DSA with n224- 112 bit This generally affects what type of certifcates you need. Notice RSA-2048 now required (no RSA-1024). Hash Functions: Digital Signature Generation: SHA-224: 112 bit SHA-256: 128 bit SHA-384: 192 bit SHA-512: 256 bit (NOTICE: No MD5, no SHA-1) MAC Generation: HMAC with key = 112 bits (note: SHA-1 can be used in MAC) CMAC with 3DES - 112 bit CMAC with AES - 128 bit+ CCM GCM/GMAC Related, NIST says some environments may need more than 112 bit security and offers two profiles, NSA Suite B - 128 bit and NSA Suite B - 192 bit (RFC 6460) For Suite B TLS, GCM cipher suites MUST be used; therefore, a Suite B TLS client MUST implement TLS version 1.2 or later. A Suite B TLS client configured at a minimum level of security of 128 bits MUST offer the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 or the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite in the ClientHello message. The TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite is preferred; if offered, it MUST appear before the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite. If configured at a minimum level of security of 192 bits, the client MUST offer the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite and MUST NOT offer the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite. So starting with your info: The current list for Firefox 27 beta is: 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 C00A TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA C014 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA C012 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA C007 TLS_ECDHE_ECDSA_WITH_RC4_128_SHA C011 TLS_ECDHE_RSA_WITH_RC4_128_SHA 0033 TLS_DHE_RSA_WITH_AES_128_CBC_SHA 0032 TLS_DHE_DSS_WITH_AES_128_CBC_SHA 0045 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA 0039 TLS_DHE_RSA_WITH_AES_256_CBC_SHA 0038 TLS_DHE_DSS_WITH_AES_256_CBC_SHA 0088 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA 0016 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA 002F TLS_RSA_WITH_AES_128_CBC_SHA 0041 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA 0035 TLS_RSA_WITH_AES_256_CBC_SHA 0084 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA 000A TLS_RSA_WITH_3DES_EDE_CBC_SHA 0005 TLS_RSA_WITH_RC4_128_SHA 0004 TLS_RSA_WITH_RC4_128_MD5 I'd suggest you follow NIST 800-131a, but if not at least give a configuration switch to drop NON-FIPS algorithms. From the above list, I'd drop the RC4, MD5 and CAMELLIA options - at least if a FIPS configuration switch is activated. Better - no switch and drop them. If you have to included them for some reason - put them at the bottom of the preference list. I think in general, you could say the shorter the key or hash, the faster it runs, so if all you are trying to get to as 112 bit security (all that is required in 2014), I'd consider preferring suites with AES_128 encryption and SHA MACs over AES_256 or SHA-256 or SHA-384 or dropping AES-256 and SHA-256 suites. 3DES is still acceptable for 2014: The following suite is the MANDATORY suite required by TLS 1.1 (RFC 4346). If you are going to allow the browser to enable TLS 1.1, you should make sure this is enabled when TLS 1.1 is enabled. There's also no reason to take it out if the minimum security protocol is TLS 1.2 - just leave it at the bottom as you have it. 000A TLS_RSA_WITH_3DES_EDE_CBC_SHA The following suite is the MANDATORY suite required by TLS 1.0 (RFC 2246). If you are going to allow the browser to enable TLS 1.0, you should probably make sure this is enabled when TLS 1.0 is enabled. There's also no reason to take it out if the minimum security protocol is TLS 1.1 or TLS 1.2 - just leave it at the bottom as you have it. This is less important since I don't think DSA certificates are much used. 0013 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA For forward perfect secrecy (a good thing even if it hurts performance some) - perfer EC-DHE and
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Sunday, January 26, 2014 6:25:58 PM UTC-7, ripb...@aol.com wrote: Hi, So I didn't get to the bottom of this thread because some of it is 'loading' but I didn't see any mention of NIST 800-131a in all the posts I saw. This standard (along with NIST 800-57 Part 1) provides information about security strength and what is required. Basically NIST is saying you should have at least 112 bit security by 2014 and that this is generally acceptable to 2031. They also say that you have to use FIPS approved algorithms. The list of approved algorithms and related security strength as related to TLS cipher suites and certificates: Encryption: AES-256 - 256 bit AES-192 - 192 bit AES-128 - 128 bit Triple-Key Triple DES (3DES) - 112 bit (NOTICE: No Camilla, RC4, SEED, DES or 2DES). Digital Signature Generation: DSA with p=2048, q=224 - 112 bit RSA with n=2048 - 112 bit EC-DSA with n224- 112 bit This generally affects what type of certifcates you need. Notice RSA-2048 now required (no RSA-1024). Hash Functions: Digital Signature Generation: SHA-224: 112 bit SHA-256: 128 bit SHA-384: 192 bit SHA-512: 256 bit (NOTICE: No MD5, no SHA-1) MAC Generation: HMAC with key = 112 bits (note: SHA-1 can be used in MAC) CMAC with 3DES - 112 bit CMAC with AES - 128 bit+ CCM GCM/GMAC Related, NIST says some environments may need more than 112 bit security and offers two profiles, NSA Suite B - 128 bit and NSA Suite B - 192 bit (RFC 6460) For Suite B TLS, GCM cipher suites MUST be used; therefore, a Suite B TLS client MUST implement TLS version 1.2 or later. A Suite B TLS client configured at a minimum level of security of 128 bits MUST offer the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 or the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite in the ClientHello message. The TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite is preferred; if offered, it MUST appear before the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite. If configured at a minimum level of security of 192 bits, the client MUST offer the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite and MUST NOT offer the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite. So starting with your info: The current list for Firefox 27 beta is: 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 C00A TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA C014 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA C012 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA C007 TLS_ECDHE_ECDSA_WITH_RC4_128_SHA C011 TLS_ECDHE_RSA_WITH_RC4_128_SHA 0033 TLS_DHE_RSA_WITH_AES_128_CBC_SHA 0032 TLS_DHE_DSS_WITH_AES_128_CBC_SHA 0045 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA 0039 TLS_DHE_RSA_WITH_AES_256_CBC_SHA 0038 TLS_DHE_DSS_WITH_AES_256_CBC_SHA 0088 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA 0016 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA 002F TLS_RSA_WITH_AES_128_CBC_SHA 0041 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA 0035 TLS_RSA_WITH_AES_256_CBC_SHA 0084 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA 000A TLS_RSA_WITH_3DES_EDE_CBC_SHA 0005 TLS_RSA_WITH_RC4_128_SHA 0004 TLS_RSA_WITH_RC4_128_MD5 I'd suggest you follow NIST 800-131a, but if not at least give a configuration switch to drop NON-FIPS algorithms. From the above list, I'd drop the RC4, MD5 and CAMELLIA options - at least if a FIPS configuration switch is activated. Better - no switch and drop them. If you have to included them for some reason - put them at the bottom of the preference list. I think in general, you could say the shorter the key or hash, the faster it runs, so if all you are trying to get to as 112 bit security (all that is required in 2014), I'd consider preferring suites with AES_128 encryption and SHA MACs over AES_256 or SHA-256 or SHA-384 or dropping AES-256 and SHA-256 suites. 3DES is still acceptable for 2014: The following suite is the MANDATORY suite required by TLS 1.1 (RFC 4346). If you are going to allow the browser to enable TLS 1.1, you should make sure this is enabled when TLS 1.1 is enabled. There's also no reason to take it out if the minimum security protocol is TLS 1.2 - just leave it at the bottom as you have it. 000A TLS_RSA_WITH_3DES_EDE_CBC_SHA The following suite is the MANDATORY suite required by TLS 1.0 (RFC 2246). If you are going to allow the browser to enable TLS 1.0, you should probably make sure this is enabled when
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
Hi, So I didn't get to the bottom of this thread because some of it is 'loading' but I didn't see any mention of NIST 800-131a in all the posts I saw. This standard (along with NIST 800-57 Part 1) provides information about security strength and what is required. Basically NIST is saying you should have at least 112 bit security by 2014 and that this is generally acceptable to 2031. They also say that you have to use FIPS approved algorithms. The list of approved algorithms and related security strength as related to TLS cipher suites and certificates: Encryption: AES-256 - 256 bit AES-192 - 192 bit AES-128 - 128 bit Triple-Key Triple DES (3DES) - 112 bit (NOTICE: No Camilla, RC4, SEED, DES or 2DES). Digital Signature Generation: DSA with p=2048, q=224 - 112 bit RSA with n=2048 - 112 bit EC-DSA with n224- 112 bit This generally affects what type of certifcates you need. Notice RSA-2048 now required (no RSA-1024). Hash Functions: Digital Signature Generation: SHA-224: 112 bit SHA-256: 128 bit SHA-384: 192 bit SHA-512: 256 bit (NOTICE: No MD5, no SHA-1) MAC Generation: HMAC with key = 112 bits (note: SHA-1 can be used in MAC) CMAC with 3DES - 112 bit CMAC with AES - 128 bit+ CCM GCM/GMAC Related, NIST says some environments may need more than 112 bit security and offers two profiles, NSA Suite B - 128 bit and NSA Suite B - 192 bit (RFC 6460) For Suite B TLS, GCM cipher suites MUST be used; therefore, a Suite B TLS client MUST implement TLS version 1.2 or later. A Suite B TLS client configured at a minimum level of security of 128 bits MUST offer the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 or the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite in the ClientHello message. The TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite is preferred; if offered, it MUST appear before the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite. If configured at a minimum level of security of 192 bits, the client MUST offer the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite and MUST NOT offer the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite. So starting with: These are the default available ciphersuits in Firefox Aurora 28.0a2 on a Windows system: 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 C00A TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA C014 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA C012 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA C007 TLS_ECDHE_ECDSA_WITH_RC4_128_SHA C011 TLS_ECDHE_RSA_WITH_RC4_128_SHA 0033 TLS_DHE_RSA_WITH_AES_128_CBC_SHA 0032 TLS_DHE_DSS_WITH_AES_128_CBC_SHA 0045 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA 0039 TLS_DHE_RSA_WITH_AES_256_CBC_SHA 0038 TLS_DHE_DSS_WITH_AES_256_CBC_SHA 0088 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA 0016 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA 002F TLS_RSA_WITH_AES_128_CBC_SHA 0041 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA 0035 TLS_RSA_WITH_AES_256_CBC_SHA 0084 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA 000A TLS_RSA_WITH_3DES_EDE_CBC_SHA 0005 TLS_RSA_WITH_RC4_128_SHA 0004 TLS_RSA_WITH_RC4_128_MD5 I'd suggest you follow NIST 800-131a, but if not at least give a configuration switch to drop NON-FIPS algorithms. From the above list, I'd drop the RC4, MD5 and CAMELLIA options - at least if a FIPS configuratoin switch is activated. Better - no switch and drop them. If you have to included them for some reason - put them at the bottom if the preference list. I think in general, you could say the shorter the key or hash, the faster it runs, so if all you are trying to get to as 112 bit security (all that is required in 2014), I'd consider preferring suites with AES_128 encryption and SHA MACs over AES_256 or SHA-256 or SHA-384. 3DES is still acceptable for 2014. The following suite is the MANDATORY suite required by TLS 1.1 (RFC 4346). If you are going to allow the browser to enable TLS 1.1, you should make sure this is enabled when TLS 1.1 is enabled. There's also no reason to take it out if the minimum security protocol is TLS 1.2 - just leave it at the bottom as you have it. 000A TLS_RSA_WITH_3DES_EDE_CBC_SHA The following suite is the MANDATORY suite required by TLS 1.0 (RFC 2246). If you are going to allow the browser to enable TLS 1.0, you should probably make sure this is enabled when TLS 1.0 is enabled. There's also no reason to take it out if the minimum security protocol is TLS 1.1 or TLS 1.2 - just leave it at the bottom as you have it. This is less important since I don't think DSA certrificates are much used. 0013 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA For forward perfect secrecy (a good thing even if it hurts performance some) - perfer
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Thu, Jan 09, 2014 at 12:59:40PM -0500, Julien Vehent wrote: I started a scan of Alexa's top 1 million websites. It's going to take a few days to have all the results. So far, 21 out of 1396 websites scanned support neither AES or 3DES. I'm about half way through the scan, but it's unlikely that the numbers will change from now. The raw results are below, and I posted an analysis on my blog: https://jve.linuxwall.info/blog/index.php?post/TLS_Survey SSL/TLS survey of 317270 websites from Alexa's top 1 million Supported Ciphers Count Percent -+-+--- 3DES 29762593.8081 3DES Only 3952 1.2456 AES 29040991.5337 AES Only 298 0.0939 CAMELLIA 12030237.9179 CAMELLIA Only 1 0.0003 RC4 28213988.9271 RC4 Only 4838 1.5249 z:ADH-DES-CBC-SHA 651 0.2052 z:ADH-SEED-SHA418 0.1317 z:AECDH-NULL-SHA 1 0.0003 z:DES-CBC-MD5 38276 12.0642 z:DES-CBC-SHA 88306 27.8331 z:DHE-DSS-SEED-SHA1 0.0003 z:DHE-RSA-SEED-SHA55195 17.3969 z:ECDHE-RSA-NULL-SHA 1 0.0003 z:EDH-DSS-DES-CBC-SHA 6 0.0019 z:EDH-RSA-DES-CBC-SHA 82910 26.1323 z:EXP-ADH-DES-CBC-SHA 451 0.1422 z:EXP-DES-CBC-SHA 68527 21.599 z:EXP-EDH-DSS-DES-CBC-SHA 6 0.0019 z:EXP-EDH-RSA-DES-CBC-SHA 60199 18.9741 z:EXP-RC2-CBC-MD5 73301 23.1037 z:IDEA-CBC-MD55248 1.6541 z:IDEA-CBC-SHA37419 11.7941 z:NULL-MD5291 0.0917 z:NULL-SHA290 0.0914 z:NULL-SHA256 5 0.0016 z:RC2-CBC-MD5 43848 13.8204 z:SEED-SHA65974 20.7943 Supported Handshakes Count Percent -+-+--- DHE 18873959.4884 ECDHE 67560 21.2942 Supported PFS Count Percent PFS Percent -+-++--- DH,1024bits 18520058.373 98.1249 DH,1539bits 1 0.0003 0.0005 DH,2048bits 2751 0.8671 1.4576 DH,3072bits 2 0.0006 0.0011 DH,3248bits 2 0.0006 0.0011 DH,4096bits 990.0312 0.0525 DH,512bits580.0183 0.0307 DH,768bits628 0.1979 0.3327 ECDH,B-163,163bits240.0076 0.0355 ECDH,B-233,233bits236 0.0744 0.3493 ECDH,B-571,570bits249 0.0785 0.3686 ECDH,P-224,224bits3 0.0009 0.0044 ECDH,P-256,256bits66920 21.0924 99.0527 ECDH,P-384,384bits780.0246 0.1155 ECDH,P-521,521bits940.0296 0.1391 Prefer PFS19455461.3213 0 Support PFS 23999775.6444 0 Supported Protocols Count Percent -+-+--- SSL2 59615 18.79 SSL2 Only 280.0088 SSL3 31605299.6161 SSL3 Only 3539 1.1155 TLS1 31339998.7799 TLS1 Only 557 0.1756 TLS1.110042531.6529 TLS1.210361232.6574 TLS1.2 Only 3 0.0009 TLS1.2 but not 1.18338 2.628 --- Julien Vehent http://jve.linuxwall.info -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Fri, Jan 10, 2014 at 08:11:02PM -0500, Julien Vehent wrote: On Thu, Jan 09, 2014 at 12:59:40PM -0500, Julien Vehent wrote: I started a scan of Alexa's top 1 million websites. It's going to take a few days to have all the results. So far, 21 out of 1396 websites scanned support neither AES or 3DES. I'm about half way through the scan, but it's unlikely that the numbers will change from now. The raw results are below, and I posted an analysis on my blog: https://jve.linuxwall.info/blog/index.php?post/TLS_Survey Thanks for doing this. There are some pretty scary numbers in there. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On 2013-12-15 02:41, Brian Smith wrote: On Sat, Dec 14, 2013 at 4:47 PM, Kosuke Kaizuka cai.0...@gmail.com wrote: little supported, never negotiated cipher One of the largest websites which support Camellia is Yahoo!. Firefox 26 or lower use TLS_RSA_WITH_CAMELLIA_256_CBC_SHA with Yahoo!. In Firefox 27 or later, Yahoo! will choose TLS_RSA_WITH_AES_128_CBC_SHA instead, because of the cipher suite order change in Firefox 27. I'm not sure what you mean with Yahoo!, they have several sites each with their own settings. Some of them set the preferred order at the server side and prefer RC4 and so we end up with RC4. I'm considering if we should also drop support for RC4 on the client side. At least IE11 on windows 8.1 doesn't do RC4, but does do 3DES. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On 2014-01-09 06:41, Kurt Roeckx wrote: I'm considering if we should also drop support for RC4 on the client side. At least IE11 on windows 8.1 doesn't do RC4, but does do 3DES. I started a scan of Alexa's top 1 million websites. It's going to take a few days to have all the results. So far, 21 out of 1396 websites scanned support neither AES or 3DES. All of these sites are high traffic: lynda.com priceline.com adultfriendfinder.com siteground.com lacaixa.es mmotraffic.com hostmonster.com elance.com vine.co cvs.com tharunaya.co.uk directv.com goal.com bluehost.com typepad.com inbox.com sprint.com squarespace.com justhost.com 123rf.com hostgator.com The (partial) results are here: http://4u.1nw.eu/top1m_ciphersuite_scan.tar I'll do more number crunching once the scan is done. The numbers show that deprecating RC4 in Firefox would have real impact on big websites. Whether we think that's a good or bad thing is up for discussion :) - Julien -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Thu, Jan 09, 2014 at 12:59:40PM -0500, Julien Vehent wrote: On 2014-01-09 06:41, Kurt Roeckx wrote: I'm considering if we should also drop support for RC4 on the client side. At least IE11 on windows 8.1 doesn't do RC4, but does do 3DES. I started a scan of Alexa's top 1 million websites. It's going to take a few days to have all the results. So far, 21 out of 1396 websites scanned support neither AES or 3DES. For all the ones I looked it, they only have RC4 enabled. So I have to wonder, do are those sites that people in general use without ssl? Or does IE11 have some fallback mechanism that it enables RC4 if it first fails to negiotate a protocol? Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On 2013-12-29 18:30, Kurt Roeckx wrote: On Sun, Dec 15, 2013 at 11:22:32AM -0500, Julien Vehent wrote: For the same reason, the server ciphersuite that we recommend at https://wiki.mozilla.org/Security/Server_Side_TLS does not drop Camellia, but lists it at the bottom of the ciphersuite. It's a safe choice, but not one that we recommend. You might also want to read: https://bettercrypto.org/ [cc-ing the cert.at mailing list that published this guide] Thanks for the link! I wasn't aware of this guide. Overall, I think this guide is great! The configuration examples are very useful. It's also good to have multiple TLS guides with different audiences, so I'm definitely glad to see more people take on the issue. I need to do a thorough read of the entire thing. I am a bit puzzled by some of the choices made around their ciphersuite B (the most realistic and practical one). Most of the ciphersuite construction sections are still empty, so it's hard to understand what exactly is intended. I did notice a few things that I, personally, find arguable: Why prefer DHE to ECDHE, when the former is 3 times slower than the later? There is a bit of a justification in 3.5: Since there is much discussion on the security of ECC, flawed settings might very well compromise the security of the entire system. I wish there was references to these discussions. My understanding of the state of the art of ECC is that P-256 is considered at least as secure as DH and RSA. They recommend AES-128 in 3.4. Keylengths, but publish a ciphersuite that prefers AES-256 (see below). This is probably just an oversight, the guide is still in Draft. The guide is not backward compatible with all clients. We, at Mozilla, must maintain backward compatibility with even the oldest, most broken, clients on the internet, and this shapes our guidelines. For example, the ciphersuite B doesn't contain 3DES or RC4, and is therefore unusable on *a lot* of PC that still run Windows XP. I wish we could just remove these two ciphers, but it's not a realistic goal in the near future. Same goes for the recommendation to use DH parameters 1024 bits. We tried using a 2048 bits parameter a few months back. We first noticed a big spike in CPU usage, caused by the largest exponentiation, but that was still acceptable. What forced the rollback is the long list of java 6 clients that broke, because they don't accept DH keys 1024 bits. Until all of these clients get fixed, DH params will be limited to 1024 bits. I *think* they want to prefer CAMELLIA to AES, judging by the published ciphersuite. But the construction must be wrong because it returns AES first. If the intent is to prefer Camellia, then I am most interesting in the rationale. ECDSA is explicitely discarded. It doesn't hurt to have it enabled, and makes the ciphersuite portable to systems that prefer ECDSA certicates (granted, it's not that many...). $ openssl ciphers -v 'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA'|column -t DHE-RSA-AES256-GCM-SHA384TLSv1.2 Kx=DHAu=RSA Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-SHA256TLSv1.2 Kx=DHAu=RSA Enc=AES(256) Mac=SHA256 ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 DHE-RSA-AES128-GCM-SHA256TLSv1.2 Kx=DHAu=RSA Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-SHA256TLSv1.2 Kx=DHAu=RSA Enc=AES(128) Mac=SHA256 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 DHE-RSA-CAMELLIA256-SHA SSLv3Kx=DHAu=RSA Enc=Camellia(256) Mac=SHA1 DHE-RSA-AES256-SHA SSLv3Kx=DHAu=RSA Enc=AES(256) Mac=SHA1 ECDHE-RSA-AES256-SHA SSLv3Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 DHE-RSA-CAMELLIA128-SHA SSLv3Kx=DHAu=RSA Enc=Camellia(128) Mac=SHA1 DHE-RSA-AES128-SHA SSLv3Kx=DHAu=RSA Enc=AES(128) Mac=SHA1 ECDHE-RSA-AES128-SHA SSLv3Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 CAMELLIA256-SHA SSLv3Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1 AES256-SHA SSLv3Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 CAMELLIA128-SHA SSLv3Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1 AES128-SHA SSLv3Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 -- Julien Vehent OpSec @ Mozilla -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Sun, Dec 15, 2013 at 11:22:32AM -0500, Julien Vehent wrote: For the same reason, the server ciphersuite that we recommend at https://wiki.mozilla.org/Security/Server_Side_TLS does not drop Camellia, but lists it at the bottom of the ciphersuite. It's a safe choice, but not one that we recommend. You might also want to read: https://bettercrypto.org/ Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Sat, Dec 14, 2013 at 05:41:55PM -0800, Brian Smith wrote: Fx26Fx27 Change Cipher Suite 0.00% 14.15% +14.15% TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (new) 0.00% 8.30% +8.30% TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (new) Are you sure you didn't switch those 2? At least your other mail with stats had them to other way around. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On 2013-12-14 19:47, Kosuke Kaizuka wrote: Camellia is widely reviewed and chosen as a recommended cipher by several independent committees. If CAMELLIA_CBC is dropped by security reason, AES_CBC should be also dropped. There is another reason to drop CAMELLIA: AES with AES-NI is 8 times faster. AES-NI is supported by the majority of server CPUs right now. Camellia is still fast in software, my laptop computes between 90 and 160 MB/s with openssl and an intel cpu. But if we want to provide the fastest response time to users, it's important to consider the server cost on the client side. - Julien -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On 2013-12-15 11:13, Kurt Roeckx wrote: On Sun, Dec 15, 2013 at 10:46:04AM -0500, Julien Vehent wrote: On 2013-12-14 19:47, Kosuke Kaizuka wrote: Camellia is widely reviewed and chosen as a recommended cipher by several independent committees. If CAMELLIA_CBC is dropped by security reason, AES_CBC should be also dropped. There is another reason to drop CAMELLIA: AES with AES-NI is 8 times faster. AES-NI is supported by the majority of server CPUs right now. Camellia is still fast in software, my laptop computes between 90 and 160 MB/s with openssl and an intel cpu. But if we want to provide the fastest response time to users, it's important to consider the server cost on the client side. It's not because it's enabled that you have to use it. The priority of Camellia is now always below AES. If the server supports AES it should pick it. Right. And by drop I really meant reduce preference of. For the same reason, the server ciphersuite that we recommend at https://wiki.mozilla.org/Security/Server_Side_TLS does not drop Camellia, but lists it at the bottom of the ciphersuite. It's a safe choice, but not one that we recommend. - Julien -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Sun, Dec 15, 2013 at 11:22:32AM -0500, Julien Vehent wrote: On 2013-12-15 11:13, Kurt Roeckx wrote: On Sun, Dec 15, 2013 at 10:46:04AM -0500, Julien Vehent wrote: On 2013-12-14 19:47, Kosuke Kaizuka wrote: Camellia is widely reviewed and chosen as a recommended cipher by several independent committees. If CAMELLIA_CBC is dropped by security reason, AES_CBC should be also dropped. There is another reason to drop CAMELLIA: AES with AES-NI is 8 times faster. AES-NI is supported by the majority of server CPUs right now. Camellia is still fast in software, my laptop computes between 90 and 160 MB/s with openssl and an intel cpu. But if we want to provide the fastest response time to users, it's important to consider the server cost on the client side. It's not because it's enabled that you have to use it. The priority of Camellia is now always below AES. If the server supports AES it should pick it. Right. And by drop I really meant reduce preference of. Which is what we already did. As Brian's stats show, the reordering has already reduced Camellia's usage to about 0.03%. But some people are also considering disabling it by default, as I think all other where talking in this thread, not just reduce the preference. For the same reason, the server ciphersuite that we recommend at https://wiki.mozilla.org/Security/Server_Side_TLS does not drop Camellia, but lists it at the bottom of the ciphersuite. It's a safe choice, but not one that we recommend. As far as I know the reasons for not recommending it are: - It's slower - It probably doesn't have much constant-time implementations. So as I understand it, the reason for not recommending it don't have anything to do with the security of Camellia itself. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Sun, Dec 15, 2013 at 8:46 AM, Kurt Roeckx k...@roeckx.be wrote: But some people are also considering disabling it by default, as I think all other where talking in this thread, not just reduce the preference. For the same reason, the server ciphersuite that we recommend at https://wiki.mozilla.org/Security/Server_Side_TLS does not drop Camellia, but lists it at the bottom of the ciphersuite. It's a safe choice, but not one that we recommend. As far as I know the reasons for not recommending it are: - It's slower - It probably doesn't have much constant-time implementations. So as I understand it, the reason for not recommending it don't have anything to do with the security of Camellia itself. Because of unfortunate design choices, Camellia is (along with AES) difficult to implement in constant time with high performance. That *is* a serious fault in the algorithm. AES-NI is a workaround for AES, but no such workaround exists for Camellia. In addition, Firefox supporting Camellia while other browsers don't is bad for interoperability. Finally, other browsers have demonstrated that Camellia isn't needed for web compatibility, so removing support for Camellia means we can avoid maintaining Camellia. Like I've said before, for any cipher that we support TLS_RSA_* for, we should be supporting some TLS_ECDHE_* variants, so that we don't make servers choose between the cipher they need/want to use and ephemeral key exchange. So, to keep Camellia support, we'd need to implement and enable the TLS_ECDHE_* variants. But, it doesn't seem worth the effort when it doesn't seem to improve interoperability, performance, or security. I think instead we are better off spending resources on making AES-GCM constant-time(-ish) and on adding support for ChaCha20+Poly1304. Google already has constant-time (I think) ChaCha20+Poly1304 patches for NSS and there's also been progress on constant-time(-ish) GHASH implementations for NSS. Note that ChaCha20+Poly1304, by design, is straightforward to implement in a high-speed, constant-time fashion. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Fri, Dec 13, 2013 at 10:48 PM, marlene.pr...@hushmail.com wrote: I present a proposal to remove some vulnerable/deprecated/legacy TLS ciphersuits from Firefox. I am not proposing addition of any new ciphersuits, changing of priority order, protocol removal, or any other changes in functionality. Hi, Thank you for suggesting these changes, and thank you for posting your message on the public mailing list. (I also appreciate the private email you sent me on the subject.) I will comment on your proposal again later. However, I want to share with you some usage data from Firefox 28 Beta, that I think we will find helpful in understanding what servers do. These numbers represent the cipher suite chosen by the server for 4,011,451 real-life full handshakes in Firefox 28 beta. First, here are the figures, sorted according to the order we offer the cipher suite in the ClientHello: Cipher Suite Count % -- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 567,486 14.15% TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 332,786 8.30% TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 10,952 0.27% TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA 0 0.00% TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 19,472 0.49% TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA 0 0.00% TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA 0 0.00% TLS_ECDHE_RSA_WITH_RC4_128_SHA 19,117 0.48% TLS_ECDHE_ECDSA_WITH_RC4_128_SHA 4,601 0.11% TLS_DHE_RSA_WITH_AES_128_CBC_SHA226,177 5.64% TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA44 0.00% TLS_DHE_RSA_WITH_AES_256_CBC_SHA 23,319 0.58% TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA 1,088 0.03% TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA 557 0.01% TLS_DHE_DSS_WITH_AES_128_CBC_SHA 9 0.00% TLS_DHE_DSS_WITH_AES_256_CBC_SHA 0 0.00% TLS_RSA_WITH_AES_128_CBC_SHA 1,053,521 26.26% TLS_RSA_WITH_CAMELLIA_128_CBC_SHA18 0.00% TLS_RSA_WITH_AES_256_CBC_SHA 36,203 0.90% TLS_RSA_WITH_CAMELLIA_256_CBC_SHA 0 0.00% TLS_RSA_WITH_3DES_EDE_CBC_SHA 7,065 0.18% TLS_RSA_WITH_RC4_128_SHA 1,507,191 37.57% TLS_RSA_WITH_RC4_128_MD5201,845 5.03% Below are the same figures, sorted by frequency (most popular first). The final column is an indication, of the cipher suites you suggest to remove, whether I think this data offers strong evidence for the removal; Remove- means the data seems to contradict your recommendation, Remove? means more study is needed, and Remove+ means that the data supports your conclusion. Cipher Suite Count % -- TLS_RSA_WITH_RC4_128_SHA 1,507,191 37.57% Remove- TLS_RSA_WITH_AES_128_CBC_SHA 1,053,521 26.26% Remove- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 567,486 14.15% TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256332,786 8.30% TLS_DHE_RSA_WITH_AES_128_CBC_SHA 226,177 5.64% TLS_RSA_WITH_RC4_128_MD5 201,845 5.03% TLS_RSA_WITH_AES_256_CBC_SHA36,203 0.90% TLS_DHE_RSA_WITH_AES_256_CBC_SHA23,319 0.58% TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 19,472 0.49% TLS_ECDHE_RSA_WITH_RC4_128_SHA 19,117 0.48% Remove? TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 10,952 0.27% TLS_RSA_WITH_3DES_EDE_CBC_SHA7,065 0.18% Remove- TLS_ECDHE_ECDSA_WITH_RC4_128_SHA 4,601 0.11% Remove? TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA1,088 0.03% Remove? TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA 557 0.01% Remove? TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA 44 0.00% Remove? TLS_RSA_WITH_CAMELLIA_128_CBC_SHA 18 0.00% Remove? TLS_DHE_DSS_WITH_AES_128_CBC_SHA 9 0.00% Remove? TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA 0 0.00% TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA 0 0.00% TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA 0 0.00% Remove+ TLS_DHE_DSS_WITH_AES_256_CBC_SHA 0 0.00% Remove+ TLS_RSA_WITH_CAMELLIA_256_CBC_SHA0 0.00% Remove+ Your idea of offering a subset of cipher suites during the initial handshake, and then falling back to another handshake later, requires more discussion and more measurements to be done. I would like to do something similar to what you suggest. Note that my Remove+/?/- comments should not be taken as an acceptance or rejection of your suggestions. I just want you to know my initial impression, based on a quick look of the data. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
