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 n>224            - 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 DHE over RSA key negotiation.
> 
> For performance, prefer EC_DHE over DHE.
> 
> you seem to have done that.
> 
> 
> 
> 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.
> 
> 
> 
> 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.
> 
> 
> 
> 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 GCM - but there might be some reason to include and maybe even to 
> put first. C02B does allow you to support NSA Suite-B 128 if it is first in 
> the list. It's probably OK there but see below about other requirements for 
> Hash and Signature Algorithms.
> 
> 
> 
> So - my take after making only the above changes to remove non-FIPS 
> algorithms - the list should be in preference order:
> 
>        
> 
> 
> 
> 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
> 
> 0033  TLS_DHE_RSA_WITH_AES_128_CBC_SHA
> 
> 0032  TLS_DHE_DSS_WITH_AES_128_CBC_SHA
> 
> 0039  TLS_DHE_RSA_WITH_AES_256_CBC_SHA
> 
> 0038  TLS_DHE_DSS_WITH_AES_256_CBC_SHA
> 
> 0016  TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
> 
> 002F  TLS_RSA_WITH_AES_128_CBC_SHA
> 
> 0035  TLS_RSA_WITH_AES_256_CBC_SHA
> 
> 000A  TLS_RSA_WITH_3DES_EDE_CBC_SHA
> 
> 
> 
> A related question - I don't know if you are sending the Hash and Signature 
> Algorithm extension in the client hello, but to get to 112 bit security 
> (required by NIST 800-131a) - you have to at least offer offer TLS 1.2, offer 
> the Hash and Signature Algorithm extension and allow the server to select 
> SHA-256 - SHA-1 signatures in the TLS protocol are no longer allowed after 
> 2014 per NIST 800-131a.
> 
> 
> 
> It would be generally cool if you provided a NIST800-131a or 112 bit 
> configuration control - default to off. In this case, the client offer should 
> offer TLS 1.2, drop SHA-1 from the Hash and Signature ALgorithm extension in 
> the client hello, not allow the server to negotiate down to any TLS less than 
> 1.2, and not allow the server to sign with SHA-1. You should also ensure that 
> certificates have 112 bit strength ( see Digital Signatures, Hashes, above).
> 
> 
> 
> It would be generally cool if you supported an NSA-Suite-B-128 and 
> NSA_Suite-B-192 control for folks that want it now. Would require you force 
> TLS 1.2, limit the cipher suites as discussed above, and verify appropriate 
> certificate strengths (No RSA, ECDSA-P256 for 128 bit, ECDSA-P384 for 192 
> bit). For Suite B-192, would also remove both SHA-1 and SHA-256 from Hash and 
> Signature Algorithm extension
> 
> 
> 
> EC_DHE is probably the future direction - it provides the most security with 
> the smallest keys and has forward perfect secrecy (i.e. you can't decrypt the 
> session even if the authentication key is cracked)

-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Reply via email to