On Mon, Jan 27, 2014 at 10:49 AM,  <ripber...@aol.com> wrote:
> 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:
>
> 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.

NIST is one input into the IETF process, and NIST and IETF are both
inputs into our decision making. We also help IETF and NIST to update
their proposed standards. There is currently work going on at the IETF
to define best practices for TLS, including recommended cipher suites,
recommended TLS versions to support, and recommended features to
support. However, I suspect that those recommendations will written
such that they define the minimum set of functionality that a good
implementation should support. I suspect they won't fully define what
an application like Firefox has to do to be simultaneously secure and
backward-compatible. The good news, though, is that things are getting
better all around, AFAICT.

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

You should look at the SP800-52 draft, which more clearly specifies
how NIST recommends that TLS applications work.
http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-52-Rev.%201.

> 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 will send my feedback regarding the NIST SP800-52 draft to this
mailing list in a separate thread.

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

IETF is currently working on BCP documents to define best practices
for the use of TLS in applications, including web browsers and web
servers. I recommend that you subscribe to the IETF UTA and TLS
working group mailing lists:

https://tools.ietf.org/wg/uta/
https://www.ietf.org/mailman/listinfo/uta
https://tools.ietf.org/wg/tls/
https://www.ietf.org/mailman/listinfo/tls

Also, the HTTP working group at IETF has added some improved minimum
requirements for the use of TLS by HTTP/2 clients and servers, based
on feedback from Mozilla, Google, and others. See
http://http2.github.io/http2-spec/index.html#TLSUsage

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

Agreed. You may be interested in
https://bugzilla.mozilla.org/show_bug.cgi?id=942515 which is about a
way for transitioning away from SHA-1 without breaking backward
compatibility.

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

It would be great if you could write this up. Please start a new
thread with your initial submission. I think one issue you may run
into is that Firefox's current version of NSS isn't FIPS-140
validated. You may find the following useful:
http://kb.mozillazine.org/Security.tls.version.*
https://developer.mozilla.org/en/docs/NSS/FIPS_Mode_-_an_explanation

Note that the "FIPS Mode - an explanation" and the support.mozilla.org
article it links to are somewhat outdated.

Also, I recommend that you write your document for Firefox 27 and
later, because Firefox 27 makes substantial changes to the default TLS
configuration of Firefox, including enabling TLS 1.2 and AES-GCM by
default.

Thanks!

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

Reply via email to