[Bug 25721] extractable keys should be disabled by default

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

--- Comment #13 from Ryan Sleevi <sleevi@google.com> ---
(In reply to elijah from comment #12)
> > Let me state this as unambiguously as possible: The Web Crypto API does not,
> > and cannot, protect you from malicious servers.
> 
> Let me state this as unambiguously as possible: there is a big difference
> between a malicious server that can compromise your security moving forward
> and one that can also gain access to key material, allowing it access to all
> prior communication and/or the ability to sign anything it wants.

No, there is not.

The server is not compromising the user's security. The server is compromised.
There is a significant difference here.

However, more important things below than this misconception:

> 
> > I have tried to demonstrate the many technical reasons why the arguments
> > you're raising are flawed. Over the course of the conversation, the exact
> > requirements of what threat you're trying to solve have changed.
> 
> "It is difficult to get a man to understand something, when his salary
> depends upon his not understanding it!" -- Upton Sinclair
> 
> What I am trying to solve has not "changed", I am just further enumerating
> the reasons why extractable keys are a horrible idea. 
> 
> (1) Extractable keys open up additional attacks, particularly of prior
> communication.
> 

No more than existing cross-site scripting. This argument holds just the same -
if someone XSS's your email provider, they have access to all prior
communication.

This is not a change in the web security model, nor is our group chartered to.
In fact, we're explicitly chartered NOT to, because we are NOT the group to do
that (for that, go see WebAppSec).

> (2) Allowing the storage of keys on the server increasing the ways keys can
> be compromised.

This is at the server's discretion. It does not change the user experience for
security one bit. It is empirically shown that prompting users on this is not
going to improve security one lick.

> 
> (3) Although currently the browser must trust the origin's javascript
> entirely, this is likely to change in a future with code signing.

This is
1) Wrong
2) Out of scope.

> 
> (4) In the real world, users never have informed consent when their browser
> runs javascript and users are often required to run particular javascript as
> part of their daily business. It is not sufficient to say that the origin
> can be trusted to make the right decision regarding key extraction.

This statement does not parse.

The server is responsible for determining what policies it associates with the
keys. The keys have no special meaning imposed by the UA.

The server is responsible for determining its security policies. It alone is
responsible for ensuring things like XSS are not possible.

Your arguments are arguing for a web security model that does not exist (nor
can/should it, since it's the very nature of the current model that makes the
Web the Web).

Notions such as prompting users to "review the Javascript about to be run" are
not realistic, as any sort of obfuscated code competition can prove.

Notions such as keys having any sort of "ramifications" for users - such as
legally binding statements or the like - are demonstrably without merit,
because such things are already possible today. Further, anyone familiar with
that particular application of cryptography would know the complex requirements
that underscore such legislative granting - and how frequently it fails as
technology.

Again, this API does not change the web security model at all. Everything you
claim this API should prevent is something that is already possible on the Web
today. None of the threats or concerns you have enumerated are new, and our
charter explicitly states that changes to the web security model (beyond the
same origin policy) are explicitly out of scope - and for good reason.

I appreciate your enthusiastic concern, but it's unwarranted and, to a degree,
either misrepresenting or misunderstanding what's available via Javascript
today.

There is zero benefit - to users or site operators - by insisting a user
interaction for such operations.

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

Received on Monday, 19 May 2014 00:26:30 UTC