On Fri, Mar 6, 2015 at 8:39 PM, Ryan Sleevi <ryan-mozdevsecpol...@sleevi.com> wrote: > > On Fri, March 6, 2015 4:26 pm, Richard Barnes wrote: > > Hey all, > > > > I've been doing some research on the potential benefits of adding name > > constraints into the Mozilla root program. I've drafted an initial > > proposal and put it on a wiki page: > > > > https://wiki.mozilla.org/CA:NameConstraints > > > > Questions and comments are very welcome. There's a lot of details to work > > out here, but I think there's some significant benefit to be realized. > > This seems unfortunate, especially given ICANN's efforts to extend the set > of gTLDs. > > While it might seem simple to argue from a security benefit, the reality > is that it further ensures "too big to fail", by reducing the number of > CAs that can issue for a given name.
That comes down to how this program is implemented. The intent seems pretty clearly to identify the space CAs are already issuing in. Perhaps newer gTLDs merit some unrestrained time in the wild before they're constrained in this way -- or perhaps it's simpler to make the gradiations more black and white (e.g. "unrestricted" vs "niche" CAs, and avoiding "somewhat unrestricted" or "nearly unrestricted"). For CAs whose business model is designed for a specific subset of the web, a name constraint program could clear a path to entry without endangering domains who are not designed to be served by that CA. > If a CA wishes to extend beyond the assigned scope, it would now have a 1 > month waiting period, although there will inevitably be a queue, and then > have to wait for a 12-18 month upgrade period for projects that have used > the name constrained roots. > > We've already seen the negative effects this can have on roots wishing to > migrate to stronger algorithms (ECC, SHA-2), in which they have to wait a > long time in the queue. This is a great point, and suggests that name constraint updates should either a) have a clear and defined update path, or b) only be implemented when the chances of updates are low. I would argue that a name constraint program could accomplish a couple things beyond just limiting raw attack surface area: * Add friction to applicants that claim in their initial application to serve a specific subset of the web, and then wish to expand their issuance surface area after their inclusion. * Reduce the friction for niche CAs to be included in the first place. For tightly constrained CAs, it's plausible to imagine that the operational complexity they need to demonstrate can be reduced. > Given that sites in consideration already have multiple existing ways to > mitigate these threats (among them, Certificate Transparency, Public Key > Pinning, and CAA), and that there are further proposed solutions to > mitigate the risks (such as OCSP Must Staple), I'm curious what are the > specific benefits you see versus the real costs for users and CAs. CT, CAA, and PKP are all great advances for securing the web, and none of them is complete. They each extend the web's defenses in different ways. Name constraints address a different problem, and only augment these extensions. * CT only detects misissuance after the fact. * CAA constrains what CAs can issue for a particular domain, not what domains a CA is allowed to issue for. Domain owners must individually opt-in to CAA. * PKP is similar to CAA, and also requires domain owners to opt-in. It can also be dangerous (crypto.cat finally got un-pin-blocked in Chrome 41). By contrast, name constraints protect *everyone*, even if the domain owner has never heard of them, or heard of CT, CAA, or PKP. > While the CA costs are both obvious and somewhat mentioned above, consider > the user costs. If there's a site that operates in multiple gTLDs (say, > for sake of example, Google), the set of CAs they can now use are the set > of CAs that are authorized to issue for the union of those domains, or > they must issue and manage multiple certificates for multiple domains and > manage them, their policies, and their expirations separately. As we know, > many users of certificates complain the operational costs are a > significant burden, and while ACME hopes to address some of them, it's > also hopefully evident that it will fail to do so for some time. > > What would you imagine the name restrictions for the major CAs to be? Or > for Let's Encrypt's nascent CA? Presumably unrestricted, correct? Constraining the current major unrestricted CAs seems thorny. But the clearest example to me of the benefit of name constraints is the US government's FPKI application: https://bugzilla.mozilla.org/show_bug.cgi?id=478418 https://bug478418.bugzilla.mozilla.org/attachment.cgi?id=8561777 While this is not finalized, and the specific constrained domains in the application are not accurate (.gov.us is not a public suffix, or in use at all), name constraints seem to be a highly practical way of bringing government CAs into the trusted root program. Ensuring that a US government CA can only issue for .gov and .mil reduces the amount of trust the root program (and thus, the web) needs to place in the US government, and lessens the burden of work the CA needs to do to protect against mis-issuance. As importantly, this will not constrain what CAs that .gov and .mil domains can use -- they can still go out to the private sector, as they currently do, to protect their domains. However, this means they will have options, and probably cheaper ones at that. While the US government is unique in owning their own TLDs, there are other government CAs already in the program, and pending application, that could benefit from constraints. I know an animating motivation for the constraint program is the compromise of a French government intermediate certificate.[1] I understand that if the name constraint program gets too fancy, it could add unwanted complexity to the trusted root program and alter the CA market in undesired ways. However, if properly implemented, I think it can very much protect website owners the world over from attack, without making the CA market more of an oligopoly than it already is. In the best case, it leads to a wider marketplace whose business functions are more accurately described and enforced. -- Eric [1] https://blog.mozilla.org/security/2013/12/09/revoking-trust-in-one-anssi-certificate/ > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy -- konklone.com | @konklone _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
