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 n>224 - 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 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.
GCM is an authenticated mode and doesn't use an HMAC. As a result the
collision resistance is more important and you need 256 bits in the hash
to have the 128 bit security level.
Subject of a separate question to be answered - 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 the
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.
So it's saying you should only use TLS 1.2. Only about 25% of the
servers support that.
Kurt
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
