On Tue, Nov 8, 2016 at 11:24 AM, Jakob Bohm <[email protected]> wrote: > Diversity requirements are about reducing the likelihood of > simultaneous coercion, as it can never be ruled out that some powerful > organization already engaged in such things could use some of its > backhanded tactics to subvert a log operator that is entirely outside > its direct jurisdiction. > > History has taught us that such things do happen from time to time.
Having written the original diversity requirement for Chrome, I'm quite familiar with what they are intended to be used for - I'm just saying that, as a practical matter, if you work through an actual threat model, you'll find that they fail rather considerably in everything other than 'feel good'. As it specifically relates to CT, it might help if you fully articulate what you anticipate the threat is - right now, it is presumably legal coercion - and then think about how, using the existing logs, you would quantify that risk. The counter-argument against diversity requirements is that, rather than relying of policy elements around unquantifiable or, for an organization of both Mozilla and Google's side, unrealistic, data points, you can instead rely on technical measures that provide the same assurances. Such as checking inclusion proofs of STHs, checking consistency of STHs, and gossiping views. After exhausting those technical solutions, question again whether policy is correct. Similarly, once your threat model is actually articulated, evaluate the risk of an arbitrary (as it necessarily is) diversity requirement and its harm on the ecosystem or cost to Mozilla to maintain the appearances of it, against the practical and perceived risks of being more liberal. Trust is a spectrum, and the calculus can be quite difficult, but again - as the example of WoSign/StartCom/Qihoo showed - it can be incredibly expensive and unrealistic to think it will be enforced solely through goodwill. It took nearly 8 months for Mozilla to obtain sufficient evidence of the relationship between those organizations. And if you think that's unacceptably long, then perhaps the policy isn't the right answer, because that's a bit of an optimistic look at how things go, with multiple people dedicating significant amounts of time to understand the issues. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
