RE: [liberationtech] W3C WebCrypto Last Call for Comments *today*

Hi all,
Could we keep here a positive and constructive mindset. Just saying...
Virginie

-----Original Message-----
From: carlo von lynX [mailto:lynX@time.to.get.psyced.org]
Sent: samedi 24 mai 2014 09:31
To: Ryan Sleevi
Cc: public-webcrypto-comments@w3.org; liberationtech
Subject: Re: [liberationtech] W3C WebCrypto Last Call for Comments *today*

Oh, a Google employee. I know what to expect.

On Tue, May 20, 2014 at 07:39:04AM -0700, Ryan Sleevi wrote:
> > I would kindly ask you to mention in the opening words that such an
> > API can only be used in an "opportunistic"
> > fashion as the JS code intended to use this API itself somehow has
> > to be delivered to the browser, which is an as yet unsolved problem
> > considering the failures of certification authorities in the past.
>
> This is not an accurate limitation of the API, given the existence of
> SysApps (aka Extensions/Apps), which as noted in the W3C SysApps
> charter, include different security models such as signed code.

I know, but I am saying the API documentation should make that clear. Signed code operates on X.509 or some other broken "trust an authority" model. There exists no reasonable security model, it is a false promise that has been delivered too long.
Time's up for promising to somehow fix the core problem later.

> This is also not a cryptographically accurate use of the term
> opportunistic encryption, though it has become quite an in vogue term.

Strawman. I didn't mention opportunistic encryption.
I used the word opportunistic for what it actually means.

> > There is a fundamental flaw in the security architecture of the web
> > and this new API does not address that.
> >
> Our charter makes this clear.

Is the charter in the introducing chapter of the specification?
Probably not. The charter is a great place to share hippie thoughts with IETF folks, but it has no effect on the output of the WG.
It's a fig leaf.

> > Please make that clear, or you may stir false hopes and become
> > responsible for potential consequences. People may be developing
> > sensitive applications with this, not being aware that any
> > certification authority of any country on earth can insert malicious
> > code.
>
> Luckily, this is also not true.
>
> Certificate pinning is one such way to mitigate this threat.

Whoops wrong person. I am the author of Certificate Patrol, the main certificate pinning implementation for Firefox. Some thousand people and me are protected from your average government MITM attack, but billions aren't.

And the main cause is Google. It's because Google uses certificates inconsistently, multiple certificates for identical domains, not even signed by the same authority. Google makes it impossible to successfully implement a certificate pinning security scheme with a reasonable end-user UX, and considering the interwoven interests of your government I have a hard time believing this will change anytime soon - even if all the employees were for it.

> Regardless, its unreasonable to suggest we are responsible for
> developers who chose to use eval on untrusted code, who choose not to
> use CSP, those who introduce XSS, and likewise, those who fail to use
> pinning. These are all complimentary tools in the developer's toolbox.

These are all symptoms of an architecture held together by band-aids, and web crypto is inviting people to build edifices of high hopes in security on top of a house of cards. Unless of course you are Google, then the world is currently quite perfect.



This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus

Received on Saturday, 24 May 2014 08:31:57 UTC