----- Original Message ----- > From: "Brian Smith" <br...@briansmith.org> > To: "mozilla's crypto code discussion list" > <dev-tech-crypto@lists.mozilla.org> > Sent: Tuesday, 1 July, 2014 10:58:27 PM > Subject: Re: Road to RC4-free web (the case for YouTube without RC4) > > On Sun, Jun 29, 2014 at 5:35 PM, Hubert Kario <hka...@redhat.com> wrote: > > > > > > As I noted in my bug comment [1], I think that the rhetoric of us not > > > adding any more RSA-key-exchange-based cipher suites, even the AES-GCM > > > ones, is significant. Software engineers at multiple companies referenced > > > our positions on this as part of making the business case for raising the > > > priority of ECDHE support in their products. > > > > I fail to see how changing /non default/ settings affects that. > > > > Some Linux distros may be tempted to change their default Firefox > configuration files so that a different set of cipher suites is enabled by > default. I am very opposed to that, and that's one of the biggest reasons > why particularly in PSM I discourage preferences.
One of the main reasons so many people choose Firefox over Chrome, is still the amount of extensions that are available to them to customize the behaviour of the browser. Removing options won't help us gain more users. Even if some distributions do plan to change crypto policy of all the applications[1], I don't see how this (if applied consistently against all applications) is a bad thing. > > I mean, I've been surfing with disallowed pictures for mixed content > > (security.mixed_content.block_display_content). You'd be surprised at > > amount > > of sites that break because of that. Disabled JavaScript is similar. > > Webmasters make sites and configure servers against the lowest common > > denominator: it works, then the work is done. They don't check what > > happens if > > the user is running non standard configuration. I've never seen a website > > that said to the user to modify the settings in about:config to make the > > site work as intended. > > > > If it were up to me, we wouldn't have either of the block_display_content > or disable-Javascript preferences either. Except that having such options does stop real attacks. Nearly all exploits use JavaScript in one form or another. Bugs in JPEG parsers do happen (CVE-2012-2806), so it's not really "safe" content. Some people may have requirements to have higher security. Even if only so that they can spot such errors more easily and notify webmasters. > Also, see Gavin's email here about adding such prefs in general. He > basically says, "Don't do it." Note that Gavin is the Firefox module owner: > https://groups.google.com/d/msg/mozilla.dev.platform/PL1tecuO0KA/e9BbmUAcRrwJ "As Benjamin notes, an add-on is a much better way to suggest people customize these things, and writing an add-on that sets a pref is trivial." So you'd accept code that is able to change this preference but doesn't expose it through about:config? I'm more that willing to create such patchset and extension pair. > > 20% of Internet servers negotiating suboptimal ciphers is not *really bad*? > > How much do we have to reach for that to be a problem? > > > > It would be better to have less (no) RC4 usage but I don't think it is as > urgent of a problem as you seem to. Also, I feel like it is really not a > great use of time to re-open the debate about adding support for > about-to-be-deprecated cipher suites to Firefox. deprecating a cipher/html tag/operating system doesn't make it go away > I am interested in discussing what we can do to help more server side > products get better cipher suites by default, and on deciding whether we > add support for ChaCha20-Poly1304, but otherwise I think we should table > the discussion until more server-side products and more servers have had > sufficient time to react to what we've already decided. if the rate of change in RC4-only servers is any indication, the percentage of servers that effectively negotiate RC4 will remain in double digits for next 5 years at least 1 - https://fedoraproject.org/wiki/Changes/CryptoPolicy -- Regards, Hubert Kario -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
