On Tue, May 23, 2017 at 12:33 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> I just think there's no need to concern themselves if someone quite clever > (whatever that means) decides to ASN.1 encode a Trollface GIF and roll that > into an EE cert subordinate to their corporate TCSC. No need to report > that as a BR violation. No need for the sponsoring public CA to be > concerned if they discover that upon audit, because I think there's no need > for said audit. Because anything that audit could have found could have > been discovered by browser validation code, with the judgement rendered > instantly and with proportionate consequence: (i.e. this is garbage, not a > certificate, I'm going with the untrusted interstitial error). I think it may be that you're looking at this issue from a per-site matter, rather than an ecosystem issue. I agree that, in theory, the most 'damage' you could do is to a single site (although there are TCSCs with dozens or hundreds of domains). But from an ecosystem perspective, it's incredibly damaging - the ability to reject trollface GIFs used to exploit users, for example, is now no longer a matter of contacting CAs / updating the BRs, but a coordinated change across the entire ecosystem, and where turning off support can easily break sites (and thus cause users more pain) Even if we start with a maximally strict model in clients (which, for what it's worth, RFC 5280 specifically advises against - and thankfully so, otherwise something like CT could never have been deployed), as we change the ecosystem, we'll need to deprecate things. Consider this: There is nothing stopping a CA from making a "TCSC in a box". I am quite certain that, as proposed, it would be far more economical for CAs to spin up a TCSC for every one of their customers, and then allow complete and total issuance from it. This is already on the border of possibility in today's world, due a loophole in intermediate key generation ceremony text. By posting it here, I'm sure some enterprising CA will realize this new opportunity :) The mitigation, however, has been that it's not "wild west" of PKI (the very thing the BRs set out to stop), and instead a constrained profile. Setting aside even the 'damage' aspect, consider the ecosystem impact. Assume a wildwest - we would not have been able to effectively curtail and sunset SHA-1. We would not have been able to deploy and require Certificate Transparency. We would not have been able to raise the minimum RSA key size. That's because all of these things, at the time the efforts began, were at significantly high rates to cause breakages. Even with the Baseline Requirements, even with ample communications and PR blitzes, these changes still were razor thin in terms of the breakages vendors would be willing to tolerate. Microsoft and Apple, for example, weren't able to tolerate the initial SHA-1 pain, and relied on Chrome and Firefox to push the ecosystem forward in that respect. It's in this holistic picture we should be mindful of the risk of these changes - the ability to make meaningful change, in a timely fashion, while minimizing breakage. And while it's easy to say that "Oh, the site's wrong, interstitial" - that just acculturates users to errors, inducing warning fatigue and undermining the value of having errors at all. It also undermines the security assurances of HTTPS itself - because now it's harder to ensure it meets whatever minimum bar deemed necessary to ensure users confidentiality, privacy, and integrity. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
