Re: CRL for the node Identities

Mike Hearn

Hi Vipin,

The arguments against CRLs in the TLS environment presented by Adam Langley pivot on the sizes of CRL
He talks about that in the last essay, as that's the current issue with scaling CRLSets. CRLSets are a Google/Chrome specific protocol that replaces CRLs/OCSP to try and address the problems discussed in his first two essays, but as Adam notes, there are some issues. Additionally CRLSets are a somewhat controversial system:

Of note, the Google CRLSet doesn't include all revoked certs and Chrome ignores revocation of certs not included by Google. So whether your cert gets revoked or not is hard to predict in advance; it depends a lot on software and processes you have no visibility into.

The CA Security Council isn't really happy about Chrome's path here:

Revocation is a very complex issue, with lots of room for debate. Reasonable people can disagree on the effectiveness of using OCSP. The CASC agrees that OCSP Stapling, and putting OCSP Must-Staple extensions in certificates, is one of the best solutions to address many issues with revocation at this time. But until that happens, we oppose browsers removing (non-stapled) OCSP checks.
The issue is a lot more complex than just scalability. The killer issue is discussed in AGL's first two essays: revocation servers can be used in two modes, neither of which is acceptable:

Mode 1, hard fail - if the revocation status of a cert can't be determined because connections to the CA revocation servers fails, treat the cert as invalid and refuse to connect. Outage of the CA servers causes an outage of every part of the internet that uses that CA. This is unacceptable, partly because it makes these servers attractive targets for DoS attackers engaging in extortion schemes, or re-enacting Fight Club.

Mode 2, soft fail - if the revocation status of a cert can't be determined, assume it's unrevoked and continue. Avoids outages so it's what every browser does. Useless because the whole point of cryptography is to handle man-in-the-middle attackers who can intercept your traffic. If the attacker is close to you (the client), they can cause a perceived outage of the CA revocation server by dropping your connection attempts. You'll then proceed to accept the bad/revoked cert anyway and the attacker wins. Alternatively if the attacker is close to the server they can just MITM the ID verification checks between the CA and the server and get a legit unrevoked cert, so again, the attacker wins.

The above analysis is true for the web PKI. It changes in subtle ways when applied to the Corda PKI. But you get the picture - it's not just a scaling problem. The CRL and OCSP protocols on the web aren't useful without very modern and complex extensions, and thus nobody uses it. As a consequence revocation software stacks are rusty and barely work ... we have a big pile of work to do in Corda as a result because currently the CRL servers are SPOFs and the default Java behaviour is to hammer them with traffic. We also need to plumb revocation checks through the Corda Firewall from the node and many other things. It's quite unfortunate we have to do all this work, given the dubious nature of the benefits :(

Join to automatically receive all group messages.