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

Received on Thursday, 12 November 2009 10:20:59 UTC