On Tue, Jan 19, 2016 at 4:15 AM, Ryan Sleevi < [email protected]> wrote:
> On Mon, January 18, 2016 9:05 pm, Eric Mill wrote: > > Really? Given your last few years of experience, if you could time > travel > > back to 2012, you would tell Past Ryan Sleevi to make a different > decision > > at that time about adding a flag for MD5 support in the enterprise? > > Yes. > > > Was there significant observed negative fallout of that decision? > > Yes. > What was the nature of that fallout? I don't know how to incorporate that into my worldview without details. > That's a great point, but Peter's data was from website logs, and > > detecting > > middleboxes in that data is about comparing TLS "fingerprints" to sent > > user > > agents. That's not something enterprises have to opt-in to. So, large > > website operators could be providing valuable (appropriately aggregated, > > etc.) data in this regard. > > Only to an extent. You're again presuming the enterprise MITM box, which > may show for sites like Amazon (of course, it would not show at all for > enterprise MITM boxes that blocked it). This would not, however, show up > at all for the case of using UAs to access internal enterprise resources, > which is a far greater (by volume of users, though necessarily not volume > of certificates) use case. > That is a great point. But do we throw up our hands and say we can just never know how enterprises use browsers? It doesn't seem practical from a product management standpoint either -- it'd be foolhardy to have no data that tells you how it's being used. The general public uses browsers which also serve the enterprise without substantial modification, so data on how enterprises use browsers is relevant to decisions that affect the general public. I encourage your team to find a way to publicly contribute some version of the data you're using to drive your decisions. But I certainly am more aware of the impact these decisions > have, and of the real tradeoffs involved for these users, and thus the > need for a softer touch. > > Arguing that enterprise users should be thrown under the bus is not a new > argument, nor is it one without grounding. We've certainly seen the > energetically emotional appeals in cases like HPKP, where some corners > have argued for making it harder and harder for enterprises to accomplish > their goals because they're seen as disagreeable. And while I certainly > don't agree with many of the reasons why such organizations see the need > to MITM, I'm quite aware of the lengths that MITM vendors will go to, and > of the lengths businesses will go to to support their needs. The same can > be said for SHA-1 here. > > To me, the root of the issue here is education - how do we educate > enterprises that SHA-1 issuance is risky (to their organization, not to > the Internet at large), such that they lean on their vendors, such that > they have the economic incentives to switch vendors or, in many cases, pay > the exorbitant fees the vendors demand in order to support better > security. It's certainly one strategy to "hold users hostage" (via > interstitials), but that's one that doesn't seem to pay off well. Even > holding users hostage via lock icons is one that, as it played out, was > significantly less effective than desired. Nor is it a good game - for > users or for browser vendors - to get in the habit of hostage taking "for > the greater good". I didn't think Chrome regretted using the lock icon to raise awareness among site owners about SHA-1. It may not have been as effective as you were hoping it would be, but I think plenty of people, myself included, observed that it generated real action by site owners across the public and enterprise spheres. We don't have the alternate universe where Chrome didn't do that to compare it to, but if it felt like less than desired, there's another conclusion you could draw: that if Firefox and IE and Safari were in the habit of trying the same thing, the effect it did have would been amplified. Another strategy is "pure outreach", although that's > unlikely to have the economies of scale necessary to get the industry to > move, and is the one previously attempted with MD5. So there's likely > somewhere in the middle ground - and that's something I hope Mozilla will > consider, in taking the necessary steps to secure PTCs, and working to > employ all appropriate means for ETCs. > I can understand and agree with your larger point, and the idea that browser influence is much more limited and specific than it may seem to the outside community. I just don't like the feeling of making decisions without any data, and I don't like the idea that browsers should default to using kid gloves with enterprises. We're willing to break connections to significant fractions of the world's general population over the next few years as the SHA-1 issuance deadline has its intended effect -- but we're not willing to even show warnings in enterprise environments? I get what you're saying, but it still sounds like a classic browser collective action problem: no single browser is willing to increase the friction out of fear that the enterprise will marginalize that browser in favor of others. If your experience with MD5 supports the notion that removing support for it in the enterprise hurt user security in some other way, such as causing enterprises to lock their users to older versions of Chrome for a long period of time, please give more qualitative or quantitative detail to support that. Otherwise, I have to assume a more traditional and typical competitive dynamic that doesn't generally work in the public's interest. -- Eric -- konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
