- From: <bugzilla@jessica.w3.org>
- Date: Mon, 19 May 2014 00:26:27 +0000
- To: public-webcrypto@w3.org
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