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