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. > 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 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. > 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. This seems like a reasonable suggestion. >> >= 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. There are real compatibility issues with turning off the HMAC-MD5-based cipher suite. However, you can turn it off in about:config; search for "md5" > 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. It is a good point that we need to change what we do in the TLS handshake when we stop accepting SHA-1 signatures. It may be reasonable to implement a "don't accept SHA-1 signatures" preference similar to the one we just removed for MD5. > 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. I do think that ephemeral-static key exchange is something that we could consider. I even mentioned it in my original proposal: https://briansmith.org/browser-ciphersuites-01.html. However, there are basically zero servers that support it. > 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? We include it in TLS 1.2 client hellos and we include SHA-2 and SHA-1 algorithms in the list. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
