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 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 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
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
