[Bug 25721] extractable keys should be disabled by default

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25721

Ryan Sleevi <sleevi@google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |INVALID

--- Comment #5 from Ryan Sleevi <sleevi@google.com> ---
The API forces the caller to choose extractability. This is a sufficient
mitigation for all the threats you're now enumerating.

The user interaction point is entirely without merit, as has already been
explained.

(In reply to elijah from comment #4)
> > As noted in the security considerations, ANY code executing in the context
> > of the origin can fully compromise WebCrypto, as they can compromise any
> > other Javascript. I can appreciate your sensitivity towards privacy, but
> > this is not how Javascript works.
> 
> This statement is entirely misleading for two reasons:
> 
> (1) There is HUGE DIFFERENCE between modifying javascript to capture the
> cleartext result of an encryption process and being able to capture the
> keys, which gives an attacker access to all prior and future communication
> that used that key. The attack surface of the former is a narrow window of
> time, requiring targeted injection of malicious javascript, where as the
> attack surface of the latter is as big as a freaking planet.

And the application author - NOT the user - is capable of making this tradeoff.
There is zero value in presenting to the user, which is why this is INVALID.

An application author can still leave the attack surface the size of a planet
through plenty of other means - eg: delivering over HTTP, storing messages in
IndexedDB, etc.

Our charter is quite clear on this, which is why the bug is invalid.

> 
> (2) the "way javascript works" is in flux. There are many interesting
> projects to separate the javascript app from data storage, using CORS or
> PostMessage, and also to verify the integrity of the js code (although this
> is less advanced). Code signing for JS will come eventually, although sadly
> not with WebCrypto.

Codesigning can be implemented (with weak CSP). However, code signing as a
first class is explicitly NOT part of our charter. That remains the realm of
WebAppSec.


Look, it remains quite simple: You either trust the source of the code you are
running, or you do not. If you do not trust it, they can lie to you a million
different ways, or access your plaintext a million different ways. There is
zero added value from forcing user interaction. If you do trust them, then user
interaction is pointless to the point of harmful.

Please read http://tonyarcieri.com/whats-wrong-with-webcrypto to understand why
the security model being argued for here is entirely broken.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Thursday, 15 May 2014 20:44:56 UTC