W3C home > Mailing lists > Public > public-web-security@w3.org > December 2009

STS and lockCA (Gerv)

From: =JeffH <Jeff.Hodges@KingsMountain.com>
Date: Tue, 08 Dec 2009 13:29:22 -0800
Message-ID: <4B1EC532.5010606@KingsMountain.com>
To: W3C Web Security Interest Group <public-web-security@w3.org>
------- Forwarded Messages

Date:    Thu, 01 Oct 2009 17:51:24 +0100
From:    Gervase Markham <gerv@mozilla.org>
To:      public-webapps@w3.org
Subject: 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-s
trict-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


------- Message 2

Date:    Fri, 02 Oct 2009 10:41:20 -0700
From:    Adam Barth <w3c@adambarth.com>
To:      Gervase Markham <gerv@mozilla.org>
cc:      public-webapps@w3.org
Subject: 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
 >
 >
 >

------- Message 3

Date:    Fri, 02 Oct 2009 15:54:50 -0600
From:    "Hodges, Jeff" <jeff.hodges@paypal.com>
To:      <public-webapps@w3.org>
Subject: RE: STS and lockCA

 > Gerv had proposed..
 > >
 > > 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



Adam Barth replies..
 >=20
 > This is an interesting proposal. =20

Agreed.


 > I think we should resist expanding the scope of the core STS proposal.

Agreed -- this is what we (PayPal) also desire.


 >  There are many different kinds of tokens one could imagine adding to
 > mitigate different threat models.=20

Yes, e.g. EVonly


 > 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?"

Since the latter presumably has more-or-less direct implications for
one's parser implementation, it'd be best to specify the ABNF + UA impl
guidance now, it'd seem.

=3DJeffH



------- Message 4

Date:    Sat, 03 Oct 2009 11:17:51 +0200
From:    Gervase Markham <gerv@mozilla.org>
To:      "Hodges, Jeff" <jeff.hodges@paypal.com>
cc:      public-webapps@w3.org
Subject: 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

------- Message 5

Date:    Tue, 10 Nov 2009 19:40:26 -0800
From:    Bil Corry <bil@corry.biz>
To:      Gervase Markham <gerv@mozilla.org>
cc:      public-webapps@w3.org
Subject: 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 shou
ld 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 revoke
d.


- - Bil


------- Message 6

Date:    Wed, 11 Nov 2009 00:57:54 -0800
From:    Adam Barth <w3c@adambarth.com>
To:      Bil Corry <bil@corry.biz>
cc:      Gervase Markham <gerv@mozilla.org>, public-webapps@w3.org
Subject: Re: STS and lockCA

On Tue, Nov 10, 2009 at 7:40 PM, Bil Corry <bil@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 ST=
S should expire at the same time as the cert, perhaps by omitting max-age o=
r allowing max-age=3Dcert, etc. =A0This will prevent accidentally causing S=
TS 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

------- Message 7

Date:    Wed, 11 Nov 2009 01:36:31 -0800
From:    Devdatta <dev.akhawe@gmail.com>
To:      Adam Barth <w3c@adambarth.com>
cc:      Bil Corry <bil@corry.biz>, Gervase Markham <gerv@mozilla.org>, public-
	  webapps@w3.org
Subject: Re: STS and lockCA

 >> One idea to consider, especially for lockCA, is to somehow denote that S=
TS should expire at the same time
 >> as the cert, perhaps by  omitting max-age or allowing max-age=3Dcert, et=
c.  This will prevent accidentally
 >> causing STS to last longer or shorter than the cert expiration, especial=
ly 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 <w3c@adambarth.com>:
 > On Tue, Nov 10, 2009 at 7:40 PM, Bil Corry <bil@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 S=
TS should expire at the same time as the cert, perhaps by omitting max-age =
or allowing max-age=3Dcert, etc. =A0This 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? =A0It seems like the site
 > can easily compute whatever max-age value it wishes to set.
 >
 > Adam
 >
 >

------- Message 8

Date:    Wed, 11 Nov 2009 14:28:42 +0000
From:    Gervase Markham <gerv@mozilla.org>
To:      Adam Barth <w3c@adambarth.com>
cc:      Bil Corry <bil@corry.biz>, public-webapps@w3.org
Subject: 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

------- Message 9

Date:    Wed, 11 Nov 2009 07:25:52 -0800
From:    Bil Corry <bil@corry.biz>
To:      Gervase Markham <gerv@mozilla.org>
cc:      Adam Barth <w3c@adambarth.com>, public-webapps@w3.org
Subject: 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 th
e same CA?  Or are you talking about a site that wants to switch CAs and is usi
ng LockCA?

How about instead there's a way to set the max-age relative to the cert expirat
ion?  So -3024000 is two weeks before the cert expiration and 3024000 is two we
eks 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


------- Message 10

Date:    Thu, 12 Nov 2009 01:08:00 -0800
From:    Adam Barth <w3c@adambarth.com>
To:      Bil Corry <bil@corry.biz>
cc:      Gervase Markham <gerv@mozilla.org>, public-webapps@w3.org
Subject: Re: STS and lockCA

On Wed, Nov 11, 2009 at 7:25 AM, Bil Corry <bil@corry.biz> wrote:
 > Would LockCA prevent the site from loading if it encountered a new cert f=
rom the same CA?

My understanding is that it would not.

 >=A0Or are you talking about a site that wants to switch CAs and is using L=
ockCA?

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 e=
xpiration? =A0So -3024000 is two weeks before the cert expiration and 30240=
00 is two weeks after. =A0I'm in agreement with Devdatta that it would be e=
asy for someone to lock out their visitors, and I think this is easier to i=
mplement.

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

------- Message 11

Date:    Thu, 12 Nov 2009 10:20:19 +0000
From:    Gervase Markham <gerv@mozilla.org>
To:      Bil Corry <bil@corry.biz>
cc:      Adam Barth <w3c@adambarth.com>, public-webapps@w3.org
Subject: 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

------- Message 12

Date:    Thu, 12 Nov 2009 10:22:45 +0000
From:    Gervase Markham <gerv@mozilla.org>
To:      Adam Barth <w3c@adambarth.com>
cc:      Bil Corry <bil@corry.biz>, public-webapps@w3.org
Subject: Re: STS and lockCA



On 12/11/09 09:08, Adam Barth wrote:
 > On Wed, Nov 11, 2009 at 7:25 AM, Bil Corry <bil@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 LockC
A?
 >
 > 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 expi
ration?  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.

Except that some clients may not come back to see the lower max-age.
Then, they make their first revisit after the lower max-age has expired
and before the higher one has expired, and the site has changed its
site, and boom.

 > That said, it might be worth caping the max-age at one
 > or two years.

A 1-year cap is probably wise.

Gerv

------- End of Forwarded Messages
Received on Tuesday, 8 December 2009 21:29:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 19 December 2010 00:16:01 GMT