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. > Sure, but part of the benefit of shutting off SHA-1 issuance is to remove > SHA-1 code from the overall software pipeline altogether, and to remove > the > opportunity for bugs and mistakes from having outsized impacts on critical > infrastructure. This argument doesn't really hold any water for the case of enterprise CAs, nor does it (in a practical sense) hold water for SHA-1. For that matter, even MD5 as an implementation isn't removed from most cryptographic libraries - including OpenSSL, BoringSSL, and CryptoAPI - because of its use in other constructs (e.g. HMAC-MD5 or the MD5+SHA1 concatenation in TLS < 1.2) >From an issuance standpoint, it really doesn't reduce code, and from the validation standpoint, the need for SHA-1 in the PKI products will remain for some time (e.g. AKI/SKI synthetic construction, or the use in OCSP) > I would put browser certificate validation code in a similar category of > critical software infrastructure as CA issuance code. Removing SHA-1 > validation code from browsers altogether is a much stronger guarantee than > depending on logic which distinguishes between publicly trusted and > locally > trusted roots, which, as discussed on this thread already, is quite > tricky. Again, not really. > 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. My point is that the over-reliance on metrics underestimates (on orders of magnitude) the impact to enterprises, which is why IF a user agent wishes to support enterprises (and it's a complex question of business and product direction), more nuance is needed. I think the benefits to restricting SHA-1 in PTCs is both obvious and uncontroversial, and offers positive security steps - more than doing nothing. I can understand the desire of those *not* impacted by such changes to wish to push the industry towards changes - I know, I've been there myself. 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". 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. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
