Re: The CA system is spectacularly broken - can the TAG help?

On 2011-12-20, at 10:25 +0100, Graham Klyne wrote:

> I'm offline as I reply, so I can't offer a link (*), but it's probably worth noting that the IETF currently has a web application security activity with some strong security experts engaged.  IIRC, the group tag is "WebSec".

websec is a group that works closely with the W3C Web Application Security WG.

While things like cert pinning are plausibly in scope for websec, the CA system issue is significantly broader.

Thomas Roessler, W3C  <>  (@roessler)

> #g
> --
> (*) The following message excerpt should point a path to the right places
> [[
> List-Id: Web Application Security Minus Authentication and Transport
> 	<>
> List-Archive: <>
> List-Post: <>
> List-Help: <>
> List-Subscribe: <>,
> 	<>
> Sorry for delay, I now uploaded minutes from Taipei:
> <>
> ]]
> On 19/12/2011 23:44, Harry Halpin wrote:
>> While I understand the CA system is somewhat outside your usual remit,
>> let me add this to your pile of woes. I'm doing this because 1) the
>> system has so stunningly came apart at the seams last year that it
>> seems all parties involved in the Web (ISOC, W3C, etc.) should be
>> actively looking at this issue and 2) there are now three different
>> proposals for fixing this.
>> There's currently a giant gaping security issue on the Web, namely
>> that the it's quite easy to fake the root certificates of a CA and so
>> compromise  TLS connections - and thus most high-value transactions on
>> the Web in a way that is *very* hard to detect. For a detailed
>> explanation of the problem, Moxie of Whisper Systems has an excellent
>> video [1]. There's been a number of very high-profile compromises,
>> such as the Diginotar [2] and Comodo attacks [3]. Overall, probably
>> problem #1 for security on the Web. It undermines all financial
>> transactions on the Web - I'd bet money Paypal stays awake at night
>> thinking about this. It's also a life and death situation for human
>> rights activists in Syria, Iran, and elsewhere - who may not stay
>> awake another night if the cert for their Gmail or Facebook account is
>> faked.
>> Now, over the last weeks I've seen about 3 different proposals that
>> are quite serious:
>> 1) Google's Proposal (Ben Laurie and Adam Langsley): Basically make a
>> public audit log of registered certs, and then the client/domain
>> owners can check their certs versus that log. That probably has some
>> browser component for checking all of this [5].
>> 2) Sovereign Key proposal from EFF (Peter Eckersley): Similar to
>> Google's proposal but more complex, uses an audit log of a "Sovereign
>> Key" rather than certs [4]
>> 3) Convergence Proposal from Whisper Systems/Twitter (Moxie
>> Marlinspike): Features a more decentralized CA-like system with
>> user-based "trust agility" where users can choose which CA-like
>> "notary" to trust via browser [6]
>> At TPAC, I talked to some of the browser team folks about this,
>> everyone agreed the CA/Browser Forum is dysfunctional (i.e. a front
>> for the current broken CA system) and they would be happy to see W3C
>> or someone move in this space [6]. Google notes "We now have an
>> outline of the basic idea and will be continuing to flesh it out in
>> the coming months, hopefully in conjunction with other browser
>> vendors." [5]
>> So maybe time for W3C to move? While I understand the TAG only makes
>> "findings", I suggest that given the overlap between the Google and
>> EFF proposal, I'm pretty sure there's a solution space going on here
>> even if it's outside of the TAG's expertise, and that solution space
>> will probably involve - browsers, and interaction with the CA/Browser
>> Forum.. Sounds like it's time for W3C to make a move. I'd do an
>> analysis of the topic, but also suggest that this problem is big
>> enough to warrant getting folks together on ASAP.
>> Who: I'd suggest that we return to the idea of hosting a workshop on
>> this topic, and since it's a large topic, I suggest W3C co-host with
>> the CA/Browser forum and maybe ISOC/IAB.
>> When: Soon as possible.
>> [1]
>> [2]
>> [3]
>> [4]
>> [5]
>> [6]

Received on Tuesday, 20 December 2011 10:31:04 UTC