Re: STS and lockCA

This is an interesting proposal.  It addresses a different threat
model than the core STS proposal (because you assume the attacker has
a valid certificate for victim.com).

I think we should resist expanding the scope of the core STS proposal.
 There are many different kinds of tokens one could imagine adding to
mitigate different threat models.  Instead of adding them all in v1,
we should allow / encourage this kind of experimentation by defining a
forwards-compatible grammar for the STS header.

Adam


On Thu, Oct 1, 2009 at 9:51 AM, Gervase Markham <gerv@mozilla.org> wrote:
> Dear public-webapps,
>
> I would like to propose a small extension to the current draft specification
> for Strict Transport Security.
> http://lists.w3.org/Archives/Public/www-archive/2009Sep/att-0051/draft-hodges-strict-transport-sec-05.plain.html
>
> The Problem
> -----------
>
> At the moment, if one CA in a browser has a root compromise or other issuing
> problem, all websites are potentially at risk. Root certificates are trusted
> to issue end-entity certificates for any site. This means that a root
> compromise or other problem at RandomCA can affect people who aren't
> customers of RandomCA. As the number of CAs in each browser increases, the
> possibility of such a problem occurring increases.
>
> A good recent example was the fact that one or two CAs were found to have
> faulty issuing software which happily issued certs for
> www.evil.com\0www.paypal.com, which were then trusted by browsers as being
> valid for www.paypal.com. If paypal.com had a way of telling browsers "valid
> certs for me only come from SuperSecureCA, not any other CA" then such a
> certificate would have failed in those browsers.
>
> The Solution
> ------------
>
> We would like to allow sites to partition the CA space so that compromises
> and problems in other parts of it don't affect them.
>
> I therefore propose a simple extension to the STS standard; a single token
> to be appended to the end of the header:
>
> lockCA
>
> The effect of this token would be to get the browser to enforce, for that
> site, not only that HTTPS is required but that the CA may not change. The
> lock would be effective for as long as the forceHTTPS was in effect (i.e.
> same max-age).
>
> There are a number of ways of defining "the CA" in the above sentence, and
> that would be subject to discussion. One simple way is the O field of the
> root, but there may be other, better ways. One might also want to store and
> lock to the EV-ness of the certificate.
>
> A site may import resources from other domains. This opens up the
> possibility that an attacker can get a bogus cert for one of those instead.
> There are two workable ways of handling that. Either:
>
> 1) For full protection, the site just has to make sure that all the other
> sites also lock their CAs;
>
> 2) The lockCA system enforces a requirement that all dependent sites must
> also have CAs locked.
>
> (Saying that all the sites must have the same CA produces undesirable
> network effects in the CA market.)
>
> Clearly, this reduces flexibility for the site to change its certificate
> arrangements or vendor at short notice. If sites wanted to transition
> vendors, they would need to carefully manipulate their STS headers over time
> to create a window in which they could switch. Many sites may decide this
> trade-off in complexity is not worth it. But high-value sites such as Paypal
> or banks may decide differently.
>
> I am interested in the group's feedback on this proposal.
>
> Gerv
>
>
>

Received on Friday, 2 October 2009 17:42:22 UTC