On Thu, Jun 4, 2015 at 9:18 PM, Chris Palmer <pal...@google.com> wrote:
> Certificate Transparency gets us what we want, I think. CT works > globally, and is safer, and significantly changes the trust equation: > > * Reduces to marginal/effectively destroys the attack value of mis-issuance > * Makes it possible for issuers to say, if under pressure to > mis-issue, that to do so would destroy the entire issuer (under some > legal regimes, I'm told this makes a difference) > * Allows us to quantify the actual extent of mis-issuance by gathering > reports of mis-issuance over time, and to name names > > CT enables us to verify that TinyCA, who promised only to issue > certificates for Tinyland, is adhering to their promise. I'm a fan of CT, but this seems like an oversimplification. CT makes all of the above _possible_, but it's fundamentally depending on meta-infrastructure that makes use of the information that CT provides. I'd argue that the implied CT meta-infrastructure is primarily human, not technical. Yeah, you can set up alerts for your domains, but this isn't exactly contracts on the blockchain or whatever -- to actually do anything about mis-issuance, humans will need to learn what happened, figure out about whether it was supposed to happen, decide how severe the situation is, decide what to do about it, and then do it. You'll also have to define what "mis-issuance" even means for a given CA, and that doesn't even look possible right now, except for subject-area experts like the kind that are on this list. If you wanted to set up any robots-only rules for detecting mis-issuance, that implies the kind of schema for a CA's intended surface area that Richard is talking about. And CT is after all about enforcement after-the-fact, and *deterring* attacks, not directly preventing attacks. Name constraints are technically enforceable matters that can directly prevent attacks ahead of time, without relying on the speculative value of deterrence. I think CT will be a pretty effective deterrent in all kinds of ways, but it's not quantifiable (at least not for some years yet) and it's not going to deter every kind of attack/er. > It's more > effective than name constraints, and it's more effective than chasing > the Golden Roots dragon. Saying CT is "more effective" than name constraints is overbroad, and demonstrably not true for some situations (like directly preventing attacks from succeeding at a technical level). I'm personally highly optimistic about CT and think it's going to make the world a more secure place. However, even in its most successful state, CT depends on expert people keeping an eye on a system that guards the general public. That's a huge help, but it's not a substitute for direct technical enforcement. Ryan's arguments against geographically bound name constraints as a contributor to balkanization are pretty compelling. And the underlying subtext I hear from him and others here, about profligate name constraints generally making the marketplace more brittle and more burdensome, seem reasonable. Dismissing the idea of there being any viable system of name constraints seems less well-supported, and describing CT as a superior solution for the goals of name constraints seems not correct. > > 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. > > It's pretty clear to me that there is simply not a technical framework > to *directly* capture a CA's intended scope. That's not clear to me at all. I've personally only seen one attempt so far, which is Richard's survey <https://docs.google.com/document/d/1nHcqeuWlgM9a1jZ6MjoOyJX7OL2p3GzAR9AJeNaxTV4/edit>, using zmap and the Google CT log, and resulting spreadsheet <https://docs.google.com/spreadsheets/d/12qtjvzpCoVk7z77LQXmjvXF7qANGpVggdbSW7BC3WRg/edit#gid=848145789> of current issuance for each root certificate. That analysis is blunt, and doesn't really separate TLDs from ccTLDs from gTLDs. For many CAs, it may be that their commercial interests are too broad, and the gTLD space too active, for there to be many safe assumptions you could bake into constraints that would not make the CA space more brittle or burdensome. It certainly seems very plausible, though, that there are some CAs in there -- or some CAs yet to come -- who could quite safely be constrained, and which would meaningfully reduce the attack surface. Even a few would make a large difference, by removing some datacenters from the world stage whose compromise would allow arbitrary issuance. > Furthermore, even the > not-very-effective means we have incur the (IMO severe) problems of > Balkanization A valid concern when the constraints are geographic in nature, which Ryan has argued persuasively. Not always the case, and potentially an outweigh-able concern even when it is the case. > and raising barriers to market entry (we're worried > about Too Big Too Fail, right? Right). This definitely seems possible with too-aggressive name constraints, and maybe Richard's proposal out-of-the-gate suggested a level of aggression that lacks consensus. Saying that any name constraint policy, beyond the occasional emergency constraint after an attack, will create a TBTF dynamic seems like a bogeyman. Finally, CT gives us the > technical lever we need to hang layer 8 policy and policy enforcement > on. Not only is that Good Enough, it's Pretty Darn Good Indeed. > That layer 8 police enforcement would benefit greatly from more information, whether it's schematized or not, about the intended issuance surface area of CAs in the trusted root program. So far, the only thing I've seen produce more of that information is investigation into name constraints. -- Eric > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > -- konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
