On Wed, Feb 28, 2018 at 11:54 AM, Tom Ritter via dev-security-policy < [email protected]> wrote: > > Of the examples I gave (Cert Patrol, Perspectives, Convergence, DANE, > DNSSEC-Stapling) - every single one of them would not actually allow > experimenting with Server Authentication modes if all they could do is > reject certificates and not accept them.
Yup. And I think it's a policy/product question whether experimenting with such methods is the right thing. Would extensions be given control over sandboxing (i.e. when something runs sandboxed and what it can/can't do)? If not, the arguments that apply there apply here. If so, then there's no limit to what extensions can do, so it's a moot point. Similarly, would there be extension APIs for manipulation of the trust store? If so, then such an extension can always add a global 'dummy' CA with a shared key (that is, the "Convergence CA" or the "DANE CA"). This model would be such that any domain that wanted to experiment with protocol 'foo' - e.g. DANE - could sign a certificate using this root, causing it to be accepted by Firefox - and then use the 'negative' API to implement whatever protocol changes they want. Thus, the ability for extensions to modify trust anchors is fundamentally equivalent to the ability to positively grant trust. However, I think the argument for these protocols is further weakened by asking whether extensions should be able to control/add TLS extensions, as some of these protocols may require (think TACK - http://tack.io/draft.html#anchor5 ). If not, then such an API doesn't "really" allow experimentation with the trust ecosystem. If not, then the argument that it can be used to experiment with alternative PKI trust models doesn't really hold - or, at least, it holds that some trust models are better than other. I do not think it's good for the ecosystem and interoperability to support these sorts of experimentation in the Web Platform. The risks to users are significant, the ability to make an informed decision is extremely scarce, and the benefits of these experiments only work if they're done at scale - which inherently means fragmenting the trust model of the ecosystem, introducing more errors (which may further desensitize users), or weakening baseline security assurances that sites and users have to to rely on. It's very much Firefox's call, but Chrome's consistently rejected these, due to the security risks to users, the ecosystem risks to site operators, and the fundamental undermining of the web security model that such APIs would necessarily introduce. > And in many cases, it will > completely prevent any such experimentation, because you can't ask a > CA to sign a cert saying "No really, I just want you to include this > weird data under this weird not-documented/not-standardized x509 > extension". > To be fair, this is not entirely accurate. Yes, it's totally true that if it's not documented, you're SOL - but I would argue argue that if it's not documented, *no one* should be relying on it, extension APIs or not. Regarding not-standardized, that's not a requirement, per the Baseline Requirements. The relevant section is 7.1.2.4, and it does permit experimentation - within the bounds of reason, safety, and interoperability. The onus is on the CA (and, if it's the Subscriber trying to convince the CA, the Subscriber), to convince the ecosystem that it meets those criteria. If they can't do that, then it seems exactly the sort of thing that would prevent risk to Mozilla users as well. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
