[Bug 25721] extractable keys should be disabled by default

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

--- Comment #11 from Ryan Sleevi <sleevi@google.com> ---
(In reply to elijah from comment #9)
> > The Web Service should have access to whatever the Web Service created - the
> > same way it has access to Indexed DB, the same way it has access to cookies,
> > the same way it has access to DOM nodes it creates.
> 
> The origin web service did not create my private keys, it requested to have
> them created. This is a very important distinction. Keys are different than
> cookies or local storage, they are much more like location data. Otherwise,
> there is no point at all for any of the key stuff in WebCrypto: if keys were
> like cookies, then the keys should always just get generated on the server
> and sent to the client.

Keys are not like location data at all. They are a series of random bytes.
Servers can totally create series of random bytes. They can put them in Indexed
DB. They can put them in cookies. This is no different.

> 
> Why isn't this the model of WebCrypto? Because keys are not like cookies,
> because it would be ridiculous to write an API that just said "generate keys
> on the server". Once you make the decision to allow client-side key
> generation, these keys suddenly become something very different than
> everything else dictated by the origin, they become something that the
> client should be able to control.

Keys being generated on the client is not to protect the user from evil
servers. Nor is it to protect servers from evil users. It's to provide
plausible deniability for servers (and applications) when they state they don't
have access to the key material.

Let me state this as unambiguously as possible: The Web Crypto API does not,
and cannot, protect you from malicious servers. You are running code from a
third-party who is potentially hostile. This is how the Web works - and WHY it
works.

Prompting the user to create an extractable key does nothing for security and
is empirically unusuable.

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.

However, it's clear that you view there being a need to protect against Hostile
Servers. This is explicitly out of scope for the charter (as a change to the
web security model beyond the same-origin policy), and those in the W3C Web App
Sec WG ( http://www.w3.org/2011/webappsec/ ) can no doubt happily explain the
flaws and reasons why.

Extractable serves two purposes:
  - One, it provides servers a means to state they lack interest in a key. This
is to reduce liability or risk of disclosure. It does not prevent them from
being compelled in the future from requesting access to new keys being
generated.
  - Two, it provides a limited means for servers that have script injected (via
XSS) to not have messages compromised. However, in practice, this will
generally not be the case - you will still need to rekey, and you have no
guarantees at the time of XSS that past messages were not replayed, fraudulent
messages were generated, etc. This is for the *server*, not the *user* to deal
with.

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

Received on Friday, 16 May 2014 22:32:28 UTC