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
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
