Hi Richard,
On Thu, Jun 04, 2015 at 02:44:00PM -0400, Richard Barnes wrote:
> The thing that was driving my earlier proposal with regard to name
> constraints was a feeling of imbalance. With every CA we add to our
> program we add risk for every site on the web. That cost is supposed to be
> offset by the benefit that a CA provides in terms of adding security for
> its subscriber sites. But when a CA exists to serve only a small slice of
> the web, this equation seems unbalanced. Small CAs are a bad risk/reward
> trade-off.
>
> One way to balance this equation better is to scope the risk to the scope
> of the CA. If a CA is only serving a small slice of the web, then they
> should only be able to harm a small slice of the web. A CA should only be
> able to harm the entire web if it's providing benefit to a significant part
> of it.
Thank you for expressing the issue, as you see it, so clearly. It has
helped me to solidify something that I have been uneasy about in previous
discussions, but haven't been able to express clearly until now.
You say that some CAs "only serv[e] a small slice of the web", and thus
"they should only be able to harm a small slice of the web". This assumes a
set of CA stakeholders that I believe is incorrect.
The set of people whom a CA serves is not the sites that they issue
certificates to. The stakeholders of a CA are the people who may be called
upon to rely upon the assertions that the CA has made in issuing a
certificate.
Since there is no meaningful way, currently, in which a certificate can only
be presented to a prior-defined subset of Internet users[1], that means that
*every* CA in existence, regardless of its "target market" (for revenue) or
any constraints on the set of names for which it can issue certificates,
serves every Internet user.
By this line of thinking, there can be no CA which "is only serving a small
slice of the web". Any proposal which contains an axiom along those lines
cannot come to an optimal conclusion, except by accident.
> I wonder if we can agree on this general point -- That it would be
> beneficial to the PKI if we could create a mechanism by which CAs could
> disclose the scope of their operations, so that relying parties could
> recognize when the CA makes a mistake or a compromise that goes outside
> that scope, and prevent harm being done.
I would certainly agree to that general point.
> I think of this as CA scope transparency. Not constraining what the CAs
> do, but asking them to be transparent about what they do. That way if they
> do something they said they don't do, we can recognize it and reject it
> proactively.
The purpose of a CPS is to provide transparency around what a CA does (or at
least says they do...). Being transparent about what a CA *actually* does,
on a fine-grained scale, is the purpose of Certificate Transparency.
> The hard problem is how to define "scope". We've taken a couple of stabs
> at using name constraints as one definition of scope. I still have some
> hope that if we can get the adaptability right, this might be viable, but
> clearly it's not going to match well for all cases. I honestly don't have
> much in the way of other ideas. Suggestions welcome.
For the simple case of name prefixes, a mechanism which is in some ways the
reciprocal of CAA records could work -- not that we have a reciprocal for
DNS, unfortunately, but that mental model works.
> It may be that there's not a technical framework that can accurately and
> flexibly capture the type of risk reduction I'm talking about here. But it
> seems worth trying to figure out what the requirements are here, and seeing
> if it's possible to meet them or not.
My immediate thoughts are that there is, certainly, a way in which a schema
for "declared constraints" could be developed. Jumping straight over that,
though, there are a number of practical deployment issues that come to mind:
* I can imagine most CAs getting some significant "pucker factor" over the
idea of providing any sort of fine-grained details on which subset(s) of
the possible customer base that they're serving. This suggests that a
more coarse-grained approach to declaring scope would be needed, however
the coarser the grain, the more gaps there are for an attacker to slip
into.
* Any automatic modification of scope will fall foul of the "DNSSEC
problem", which I define as the fact that what you're (mostly) protecting
against is compromise of the DNS host, but if you're in there you can just
change the DNSSEC records to match. The same thing applies here -- if
you manage to get "the system" to issue you a cert, that same system will
probably automatically alter the scope to permit what you're trying to do.
* If scope modification is purely manual (and good luck making the Turing
test for that stick, not to mention the idea that automated is usually
less error-prone than manual anyway) then CAs will want to again declare
scope as broadly as they can get away with, giving attackers big gaping
holes through which to drive.
Finally, what's the carrot? Why would a CA do this? Any attempt to get a
CA to constrain their operations needs a benefit (to the CA) which
outweighs the cost (to the CA, even if it is only illusory).
My take is that coming up with ways in which CAs can be constrained, or
declare their scope, or any number of different technical paths that could
be taken -- that's the *easy* bit. The hard bit is the people/political
issue. What can be offered to a CA to encourage them to participate in any
program of this kind?
I'm disregarding the stick deliberately, by the way. The only stick that a
trust store has is refusing to include a root, or delisting an existing
root. Given the disruption that delisting causes, and the fact that it is
wrong in many different ways to apply less stringent rules to roots which
happened to get in previously, there really isn't any practical benefit to
even threatening with the stick. I'll gladly change my mind on that point
when every CA whose BR audit is more than 18 months old gets chucked out.
So, those are my thoughts. They're worth what you paid for them. <grin>
- Matt
[1] Services which are only accessable to a small group of people, such as
the employees of an organisation, are not accessed by "Internet users",
to my way of thinking, but rather to users which happen to use
technologies which are also used, coincidentally, by the Internet.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
