Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

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

carlo von lynX lynX at time.to.get.psyced.org
Sat May 24 00:30:48 PDT 2014


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.




More information about the liberationtech mailing list