On Monday, January 27, 2014 10:52:44 AM UTC-7, Brian Smith wrote: > 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. >
Camellia disabled by default - I'd say this is appropriate. Ability to disable RC4 and Camellia - I'd say this was sufficient. I believe that folks are using RC4 to get around the broken AES-CBC implementation in TLS 1.1. That should revert back to using AES-CBC once they are on TLS 1.2 (in an ideal world) - but in the short term - I agree - you are stuck with defaulting to enabling, hopefully at the bottom of the preference order. > > > > 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 can't speak for FF - and I've certainly read enough standards to say that there are too many standards. I do think that the IETF does listen to NIST however. And if you care about security, the security of your implementation is a function of the cryptographic algorithms used. So I'd suggest that NIST is telling FF and everyone else where they should be to be secure. That being said, the reality of rolling forward to a new security level in the real world is much more of a random walk through the park. I appreciate your consideration of my comments. > > > > 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. > That is as good as I could have hoped for Brian. I'll tell you that (for work reasons) I've had to try to decipher between all the standards what is needed for security compliance. It is much more messy than I had hoped. I have to fault the standards groups for not making it more obvious. If you understand what it is saying, NIST 800-131a is actually pretty clear on what it recommends and why; and it points to other standards that do some of the explaining. However, it would have been very helpful if they had actually bothered in an appendix to indicate all the cipher suites that are OK (for TLS and IPSEC). This might have motivated other standards groups to update other standards and perhaps help more implementors make good choices. I can't even assure you that everything I'm saying is correct - but I think I've got enough background to provide an educated opinion on some of this stuff. I will say this though. NIST's guide line is about achieving a specific security level that they feel is needed at a given period of time. This has nothing to do with what is out in the real world - it has to do with getting the real world to go where it needs to go. I would like to hear more about what you are recommending NIST do to align with default configurations (perhaps something for a separate email). I work on some server implementations and have an equivalent problem of trying to figure out if I limit the server to be NIST compliant - will it work with any existing browsers? If everyone could get on the same page about what we need to do now and what we need to do soon, we probably wouldn't be having this discussion. It would be good if the IETF wrote some standards to obsolete stuff that is not used and tell folks to get off stuff that is known to be not secure. Perhaps it is a work in progress - it's hard to keep up. Even better if they had more implementation guidelines for implementors. > > > > 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. Again - more than I could have reasonable expected you to agree with. Thanks. > > > > >> >= 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" Ability to disable MD5 - I think this is sufficient. Also - sorry about my ignorance about FF configuration controls. > > > > > 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. > So first, I'm not asking you to stop accepting SHA-1 signatures (at least not by default). I'm trying to say that if you don't at least offer the server the Hash and Signature Algorithm extension with both SHA-1 and SHA-256, then by 5246 (TLS 1.2) the server is obligated to use SHA-1 for signing. In otherwords, unless the client sends this extension - the server cannot create a NIST 800-131a compliant connection with this client. I see you answered later that you do send this on a TLS 1.2 client. That is sufficient. > > > > It may be reasonable to implement a "don't accept SHA-1 signatures" > > preference similar to the one we just removed for MD5. A control to stop accepting SHA-1 signatures would be desirable. I would say for the forseeable future, it would have to default to off - I'll give you odds that >90% of the certificates still have SHA-1. > > > > > 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. Standards describe lots of things that are not implemented in the real world. I would be the last one in the world to ask you to support something that no one is using unless it was the only way to achieve some goal that is needed. For example - no one supported TLS 1.2 orignally - but TLS 1.1 was broken so we need to move on. In think ECDHE is going to be strategic (someday). From what I'm hearing, I don't see any need for DH and ECDH in the general world unless something else is said. I would suggest ignore them until someone knocks on your door with a reason about why he has to have 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. Super - that is what is needed. So perhaps I'll try to make an offer here. I really like FF's ideology. I'd like to try to put together a set of 'guidelines' for configuring it to be NIST 800-131a compliant - e.g. describe what configuration controls are necessary. I think you've told me most of that above - though I think there were a few other things in the list to check out. I'll take that offline from this chat. It's something I could use in my environment. It might be something that would be useful to others as a reference. Thanks, Rick -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
