Re: STS and lockCA
On Wed, Nov 11, 2009 at 7:25 AM, Bil Corry b...@corry.biz wrote: Would LockCA prevent the site from loading if it encountered a new cert from the same CA? My understanding is that it would not. Or are you talking about a site that wants to switch CAs and is using LockCA? I think Gervase means that you want some overlap so that folks that connect to your site the day after you renew your certificate are protected. How about instead there's a way to set the max-age relative to the cert expiration? So -3024000 is two weeks before the cert expiration and 3024000 is two weeks after. I'm in agreement with Devdatta that it would be easy for someone to lock out their visitors, and I think this is easier to implement. That seems overly complicated and contrary to the semantics of max-age in other HTTP headers. I'm not convinced we need to paternally second-guess site operators. Keep in mind that the site operator can supply a lower max-age in a subsequent request if they realize they screwed up and want to reduce the duration. That said, it might be worth caping the max-age at one or two years. Adam
Re: STS and lockCA
On 11/11/09 15:25, Bil Corry wrote: Would LockCA prevent the site from loading if it encountered a new cert from the same CA? No. Hence the name - lock _CA_. :-P (BTW, I'm not subscribed to public-webapps; you'll need to CC me on any conversation you want me in.) Or are you talking about a site that wants to switch CAs and is using LockCA? Exactly. If sites never wanted to switch CAs, then LockCA could be designed to never expire and no-one would care. The design difficulty is setting things up so they can easily switch with the minimum decrease in protection. How about instead there's a way to set the max-age relative to the cert expiration? So -3024000 is two weeks before the cert expiration and 3024000 is two weeks after. I'm in agreement with Devdatta that it would be easy for someone to lock out their visitors, and I think this is easier to implement. I don't think this helps much, and it certainly makes things more complicated. Musings: STS already has an expiration mechanism. However, a site like Paypal wants ForceTLS basically forever, but may at some point want to switch CAs. If we tie LockCA expiry to ForceTLS (STS) expiry, they have to weaken their ForceTLS protection to switch CAs. This is bad. On the other hand, if we don't tie them together, we have to have a different expiry mechanism, thereby having two of them. This is also bad. :-| The expiry design needs to minimise the vulnerability window. Ideally, this means that every single client would stop checking for the same CA at the same moment, and then the site could switch and re-enable the protection. We also ideally want this to work on machines with badly-set clocks, and across time zones. Therefore, I think the right answer is to say LockCA expires in X seconds, defining X in the header. A site which wants to obsessively minimise its vulnerability window can dynamically generate the value, decreasing it from X by 1 second per second until the change time. All clients will do the math independent of their clocks, and stop checking at the right moment. Sites which care a bit less can just have it normally X, then remove the header entirely X seconds before the scheduled change, and wait for all the clients to stop checking. Gerv
Re: STS and lockCA
On Tue, Nov 10, 2009 at 7:40 PM, Bil Corry b...@corry.biz wrote: Gervase Markham wrote on 10/01/2009 5:51 PM: I therefore propose a simple extension to the STS standard; a single token to be appended to the end of the header: lockCA One idea to consider, especially for lockCA, is to somehow denote that STS should expire at the same time as the cert, perhaps by omitting max-age or allowing max-age=cert, etc. This will prevent accidentally causing STS to last longer or shorter than the cert expiration, especially when it's rotated out or revoked. Why do we need a browser mechanism for that? It seems like the site can easily compute whatever max-age value it wishes to set. Adam
Re: STS and lockCA
One idea to consider, especially for lockCA, is to somehow denote that STS should expire at the same time as the cert, perhaps by omitting max-age or allowing max-age=cert, etc. This will prevent accidentally causing STS to last longer or shorter than the cert expiration, especially when it's rotated out or revoked. Why do we need a browser mechanism for that? It seems like the site can easily compute whatever max-age value it wishes to set. I am actually afraid that the website can easily miscompute that. In general, with STS , I am afraid of sites miscalculating some max-age like setting and taking themselves offline. Having browsers automatically expire STS at the same time as the cert makes sense to me. Sites that do their certs right do not lose any security properties and sites that mess up worst case fall back to old HTTP/HTTPS behaviour (and not take themselves offline). You could ofcourse argue that STS site's admin won't be stupid. While I wouldn't put my money on that, that's a assumption that the specification free to make but should be explicit about (for e.g by telling the spec reader : we are assuming you are smart, if you mess up you can easily take your site offline) Cheers Devdatta 2009/11/11 Adam Barth w...@adambarth.com: On Tue, Nov 10, 2009 at 7:40 PM, Bil Corry b...@corry.biz wrote: Gervase Markham wrote on 10/01/2009 5:51 PM: I therefore propose a simple extension to the STS standard; a single token to be appended to the end of the header: lockCA One idea to consider, especially for lockCA, is to somehow denote that STS should expire at the same time as the cert, perhaps by omitting max-age or allowing max-age=cert, etc. This will prevent accidentally causing STS to last longer or shorter than the cert expiration, especially when it's rotated out or revoked. Why do we need a browser mechanism for that? It seems like the site can easily compute whatever max-age value it wishes to set. Adam
Re: STS and lockCA
On 11/11/09 08:57, Adam Barth wrote: Why do we need a browser mechanism for that? It seems like the site can easily compute whatever max-age value it wishes to set. Not to mention the fact that you normally don't actually want the LockCA to expire at exactly the same time as the cert, because you don't normally change certs over the second they expire! One would hope to be safely on the new cert a week or two before the expiry of the old one - at which point, the seeminly-simple expire when cert expires setting comes back to bite you. Gerv
Re: STS and lockCA
Gervase Markham wrote on 11/11/2009 6:28 AM: On 11/11/09 08:57, Adam Barth wrote: Why do we need a browser mechanism for that? It seems like the site can easily compute whatever max-age value it wishes to set. Not to mention the fact that you normally don't actually want the LockCA to expire at exactly the same time as the cert, because you don't normally change certs over the second they expire! One would hope to be safely on the new cert a week or two before the expiry of the old one - at which point, the seeminly-simple expire when cert expires setting comes back to bite you. Would LockCA prevent the site from loading if it encountered a new cert from the same CA? Or are you talking about a site that wants to switch CAs and is using LockCA? How about instead there's a way to set the max-age relative to the cert expiration? So -3024000 is two weeks before the cert expiration and 3024000 is two weeks after. I'm in agreement with Devdatta that it would be easy for someone to lock out their visitors, and I think this is easier to implement. - Bil
Re: STS and lockCA
Gervase Markham wrote on 10/01/2009 5:51 PM: I therefore propose a simple extension to the STS standard; a single token to be appended to the end of the header: lockCA One idea to consider, especially for lockCA, is to somehow denote that STS should expire at the same time as the cert, perhaps by omitting max-age or allowing max-age=cert, etc. This will prevent accidentally causing STS to last longer or shorter than the cert expiration, especially when it's rotated out or revoked. - Bil
Re: STS and lockCA
On 02/10/09 23:54, Hodges, Jeff wrote: 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. Agreed, see the thread entitled more flexible ABNF for STS? That would be a great thing :-) I suggest allowing comma/space-separated key=value pairs or simple tokens, and suggesting an X- prefix for unstandardised keys or tokens. Gerv
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 g...@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
STS and lockCA
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
