On Mon, Jun 5, 2017 at 6:21 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> If you read the paper, it contains a proposal for the CAs to countersign > the computed super-crl to confirm that all entries for that CA match the > actual revocations and non-revocations recorded by that CA. This is not > currently deployed, but is an example of something that CAs could safely > do using their private key, provided sufficient design competence by the > central super-crl team. > I did read the paper - and provide feedback on it. And that presumption that you're making here is exactly the reason why you need a whitelist, not a blacklist. "provided sufficient design competence" does not come for free - it comes with thoughtful peer review and community feedback. Which can be provided in the aspect of policy. > Another good example could be signing a "certificate white-list" > containing all issued but not revoked serial numbers. Again someone > not a random CA) should provided a well thought out data format > specification that cannot be maliciously confused with any of the > current data types. > Or a bad example. And that's the point - you want sufficient technical review (e.g. an SDO ideally, but minimally m.d.s.p review). Look, you could easily come up with a dozen examples of improved validation methods - but just because they exist doesn't mean keeping the "any other method" is good. And, for what it's worth, of those that did shake out of the discussions, many of them _were_ insecure at first, and evolved through community discussion. > In this case, it would presume that technical competence exists at high > end crypto research / specification teams defining such items, not at > any CA or vendor. For example any such a format could come from the > IETF, ITU-T, NIST, IEEE, ICAO, or any of the big crypto research centers > inside/outside the US (too many to enumerate in a policy). > And so could new signature algorithms. But that doesn't mean there shouldn't be a policy on signature algorithms. > Here's one item no-one listed so far (just to demonstrate our collective > lack of imagination): > This doesn't need imagination - it needs solid review. No one is disagreeing with you that there can't be improvements. But let's start with the actual concrete matters at hand, appropriately reviewed by the Mozilla-using community that serves a purpose consistent with the mission, or doesn't pose risks to users. > However the failure mode for "signing additional CA operational items" > would be a lot less risky and a lot less reliant on CA competency. That is demonstrably not true. Just look at the CAs who have had issues with their signing ceremonies. Or the signatures they've produced. > It is restrictions for restrictions sake, which is always bad policy > making. > No it's not. You would have to reach very hard to find a single security engineer would argue that a blacklist is better than a whitelist for security. It's not - you validate your inputs, you don't just reject the badness you can identify. Unless you're an AV vendor, which would explain why so few security engineers work at AV vendors. > If necessary, one could define a short list of technical characteristics > that would make a signed item non-confusable with a certificate. For > example, it could be a PKCS#7 structure, or any DER structure whose > first element is a published specification OID nested in one or more > layers of SEQUENCE or SET tags, perhaps more safe alternatives could be > added to this. > You could try to construct such a definition - but that's a needless technical complexity with considerable ambiguity for a hypothetical situation that you are the only one advocating for, and using an approach that has repeatedly lead to misinterpretations and security failures. > An incorrect CRL is an incorrect CRL and falls under the CRL policy > requirements. > > An incorrect OCSP response is an incorrect OCSP response and falls under > the OCSP policy requirements. This is an unnecessary ontology split, because it leaves it ambiguous where something that 'ends up in the middle' is. Which is very much the risk from these things (e.g. SHA-1 signing of OCSP responses, even if the certificates signed are SHA-256) > Those whitelists have already proven problematic, banning (for example) > any serious test deployment of well-reviewed algorithms such as non-NIST > curves, SHA-3, non-NIST hashes, quantum-resistant algorithms, perhaps > even RSA-PSS (RFC3447, I haven't worked through the exact wordings to > check for inclusion of this one). I suspect this is the core of our disagreement. It has prevented a number of insecure deployments or incompatible deployments that would pose security or compatibility risk to the Web Platform. Crypto is not about "everything and the kitchen sink" - which you're advocating both here and overall - it's about having a few, well reviewed, well-oiled joints. The unnecessary complexity harms the overall security of the ecosystem through its complexity and harms interoperability - both key values in Mozilla's mission statement. Rather than arguing for the sake of the hypothetical, what some CA "might" want to do, it's far more productive to have the actual use cases with actual interest in deployment (of which none of those things are) come forward to have the public discussion. Otherwise, we're just navel gazing, and it's unproductive :) _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
