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-xxxx/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.
> A Suite B TLS client configured at a minimum level of security of 128
>
> We do not have a minimum level of 128. As you say yourself, 112 bit is >
> enough.
>
The standards say 112 bit is sufficient for most uses. Some uses may require
128 or 192 bit (now). So most users will want to stay away from suites with big
keys and hashes if they can. A configuration switch would be nice to pick
between 112 and higher levels and it would not be all that much work to change
the set of cipher suites and the Hash and Signature algorithm. Firefox doesn't
have to provide this - but it would be handy in some environments. Prehaps even
give you something to brag about relative to your competition.
>
> > 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 if the
> > preference list.
>
>
>
> 3DES, RC4 and MD5 are actually at the bottom of the list.
Putting them at the bottom is going to result in these being used on some sites.
You may need this for legacy perhaps, but it violates NIST 800-131a compliance.
Folks that need compliance are going to want them out 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.
>
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 AES-256.
HMAC with SHA-1 is good with AES-128. GMC with SHA-256 is good with AES-128.
> > 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).
> > 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.
>
Well again it comes back to legacy use. Yes 4346 is obsolete, but the fact that
you are failing back to TLS 1.1 says that you are still using 4346 for legacy
reasons. If folks followed 4346 when they implemented their TLS 1.1 server, you
could count on all TLS 1.1 servers supporting that cipher suite. If not one is
using it and the performance is bad - yes maybe you can just drop it.
Technically - a TLS 1.2 client should be able to offer TLS 1.2 to a TLS 1.1
server and have the server respond with a serverhello that selects a cipher
suite and TLS 1.1. Whether the TLS 1.1 implementations are robust enough to
handle this I can't say. However, in this case, you need to give it a cipher
suite that it knows or it cannot do this. Supporting the mandatory TLS 1.1
cipher suite seems reasonable in this context. I don't think this is a fail
back the way firefox uses the term - this is just the server negotiating what
it knows. Actually, 3DES is not obsolete - it's still in TLS 1.2 cipher suites
(see Appendix C in 5246) - but it will become obsolete in 2030. I can
understand you're bias against it - it's not as strong as AES and it performs
worse so there's no reason to support it unless you have sites that require you
to in order to connect.
>
> > The following suite is the MANDATORY suite required by TLS 1.0 (RFC 2246).
> > 0013 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
>
> Also obsolete.
Same discussion as above in the TLS 1.0 context. However less interesting
since almost no DSA implementations.
>
>
>
> > 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.
Since EC is relatively new, it is likely any implementation that supports EC
would support AES (or you might say Camellia). And DSA has little or no support
so probably also OK to drop. I'd possibly question the DHE_RSA if there are any
legacy servers out there that would support this as their only forward perfect
secret suite. Don't have any data to indicate that but someone else might.
>
> > 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?
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.
>
>
>
> > 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.
>
The logic goes like this:
1) SHA-1 does not have 112 bit security strength (so not good after 2014)
2) The TLS protocol has the certificate owner sign something to prove it
owns the private key.
3) The authentication certificate determines the public and private key
used to sign with, but it does NOT determine the HASH used in the
protocol for
signing. The default definition for TLS (even with TLS 1.2 with no Hash
and Signature ALgorithm extension) is that the server uses SHA-1.
4) To get rid of the SHA-1 signature - you need to negotiate the hash
algorithm to be at least SHA-256.
5) So you need TLS 1.2 because that is the only level of the protocol that
provides a way to control the hash used for signing during the protocol.
So you can't get to 112 bit security strength without:
1) Negotiating TLS 1.2 for connection
2) Using an authentication certificate that has 112 bit security strength
in its trust chain (e.g. RSA-2048 with SHA-256 signature).
3) Negotiating a cipher suite with 112 bit security.
4) Negotiation a hash and signature algorithm with 112 bit security (e.g.
SHA-256)
5) You need a FIPS approved PRNG algorithm and an entropy source with at
least 112 bits of entropy.
If any of these is missing - you are not there yet.
I understand there are a lot of sites that don't meet the above criteria. I
believe it should at least be the browsers job to allow a site that does meet
these criteria to achieve 112 bit security strength. For sites that do not meet
the criteria - it should be more obvious to the user that the do not and that
should facilitate the complaining necessary to drive sites to update. And for
users with compliance requirements, there should be a switch to say do not
connect unless you can get 112 bit security (and FIPS approved algorithms).
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?
Rick
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
