OCSP, CRLs, crlset - Revocation Delivery and Attacks

Question

OCSP responses have a 'nextUpdate' field, which is the expected time for the new revocation update and that the current revocation can be considered valid. The revocations can be cached by the intermediate cert servers, which I have seen used in designs which provide stapled responses. I have read that revocations are delivered immediately from the root CA to the intermediate CA.

In this case, what if there was a DoS attack to the root CA server so it is prevented from delivering the revocation? This could expose a window of opportunity, using the intermediate server's cached revocation entry, that would incorrectly advise an end user's client that a website cert is valid, when may be invalid. The user's client or browser could interact with a malicious site until the DoS is stopped, a phone call is made to all the intermediate servers, etc... up to 7 days.

There have been at least three DoS attacks on root name servers lasting at least an hour long, however I'm not sure how they would affect a CA server's ability to send outbound traffic. Perhaps they have side channels of getting the revocation list out.

Does anyone have any more information on the technical aspects of this and the possibility of this type of attack occurring? Also, I'm curious if anyone knows the caching infrastructure for CRLs and timing to expect a revocation to appear at a typical intermediate CA?

Chrome uses it's own propriety method of crawling CRLs and Google pushes them to the browser in chunks, called crlset. At first glance, OCSP has a better timing advantage compared to crlset, because it contacts authorized responders directly to get the revocations status, however after finding that some providers have implemented variably defined CRL cache update periods, I'm not sure it's actually better. Google claims that's their revocation list is updated daily and this is more frequent then other solutions.

Does anyone know the tradeoffs in security between OCSP and Google's crlset method? Specifically which has better timing and reliability to get the revocation response? Is Google's claim supported by evidence?

Answer 1

I asked a question about CRL and OCSP yesterday and then read up on it and I for one came to the conclusion that there is no "perfect" solution at the moment.

In a perfect system the browser would verify the revocation status at the CA itself at least once EVERY session but for that to work every CA would need to create huge server clusters with great redundant connections spanning around the world to ensure minimal response times.

Because that's not really feasable (you can't expect every CA to create such a big infrastructure) OCSP stapling was created in the first place with the downsides you stated.

Google's crlset is basically something in between, it acts as a CRL-cache. The upside is that Google has a huge server infrastructure in place that is less prone to DoS attacks, so in theory this is a good thing. The downside is that you are reliant on Google with all the privacy concerns and other problems that come with it.

In my opinion certificates should include a "mandatory revocation check on every request" boolean field which forces the client to update the revocation status on every request. So basically critical infrastructure and high security applications like banking sites always enforce an up-to-date revocation status at the start of every session and less critical sites just don't and opt for usability instead of (higher) security. Also users should have the option to set this individually for every site (just like cookie options etc.) unless it is enforced by the server (so deactivating it when the server enforces it shouldn't be possible).

This is as much a political thing than a technical, it needs regulation to get something like this in place.

But then again, the attack vector for this scenario is pretty slim in reality if you think about it. Because basically you have to first attack the server and corrupt the certificate (which should be very unlikely for high security applications) AND simultaniously DoS the root CA with a huge attack so nothing comes through and then use that small window to perform your attack, this is very, very unlikely and can be migitated even more if the nextUpdate period was even smaller (which it should be in high security environments).

So it's also a matter of "Who is responsible for the integrity of a server?" because when someone gets hold of your server's private key, the revocation status of your certificate isn't exactly the biggest problem you have but some one having root access to your server (or even worse getting your key without root access).