[cryptography] Chrome to drop CRL checking

Marcus Brinkmann marcus.brinkmann at ruhr-uni-bochum.de
Tue Feb 7 09:05:49 EST 2012


On 02/07/2012 01:36 PM, ianG wrote:
> On 7/02/12 20:56 PM, Marcus Brinkmann wrote:
>> Hi,
>>
>> On 02/07/2012 03:52 AM, Steven Bellovin wrote:
>>> http://arstechnica.com/business/guides/2012/02/google-strips-chrome-of-ssl-revocation-checking.ars
>>>
>>>
>>
>> While I am no fan of CRLs, I think it's worth mentioning that Google's
>> primary objective here does not at all seem to be the security of
>> anything except their position in the race for the fastest browser:
>
>
> The first thing to ask is whether CRLs/OCSPs have benefit security *at
> all*.
>
> Google's suggestion is no. I would agree. Theory predicts that the
> combined weight of problems, well researched and experimentally measured
> by now, will lead to revocation being more or less ineffective.

That seems to be their argument only when it comes to maintenance 
revocations.  The argument rather seems to be that if you are 
disconnected from rest of the internet, you can only rely on two sources 
of information: the ones given by the server you want to connect to (the 
"captive portal") and the data you are carrying around on your computer. 
  So Langley wants to move the CRL to the local storage of the computer, 
delivered with automatic updates.

Implicitely, Langley seems to suggest that the only useful data you are 
allowed (or able) to carry around on your computer comes from Google 
with automatic updates.

That's a false dilemma.  You could also extract trust from your cache, 
ie your past experience with the same server (the SSH model), and/or 
from your past connections with the internet (CRL or monitoring servers 
differently from Google Chrome autoupdater).

Langley doesn't state why he is limiting the options in this way.  It is 
probably a mix of cultural bias and technical reasons (performance, etc).

In any case, the proposal still keeps an old-fashioned CRL around to check.

Later on, Langley seems to want to replace the CRL with a positive proof 
of freshness:

http://www.imperialviolet.org/2011/11/29/certtransparency.html

This is a better approach, but it remains to be seen how he intends to 
organize the whole thing.  From the description it already seems 
strictly weaker than the decentralised EFF Souvereign Key approach.

Many things coming from Google make quite a lot of sense if one is 
jumping off the cliff and considers everything that Google knows about 
oneself as "private" and everything that Google knows about everyone 
else as "the majority view" (in the sense of a P2P network).  As any 
clever lie, this is partially true.  Google is good at protecting the 
data it is collecting, and it has a wide network of servers that is hard 
to attack by enclosing.  But the risk of abuse grows with the value of 
the data and the number of people who can access it, and this should 
give pause for thought.

> (We've known this prediction since forever, 1998 is when I first heard it.)
>
> We now have a few solid data points where all vendors decided not to
> rely on CAs revocation and instead issued new software. So all vendors
> agree.
>
> So, if this is the case - revocation delivers no benefit - then rip the
> bloody stuff out and make the browser faster and more reliable:

Thanks,
Marcus



More information about the cryptography mailing list