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

Reply via email to