W3C home > Mailing lists > Public > public-webcrypto@w3.org > May 2014

[Bug 25721] extractable keys should be disabled by default

From: <bugzilla@jessica.w3.org>
Date: Thu, 15 May 2014 06:21:26 +0000
To: public-webcrypto@w3.org
Message-ID: <bug-25721-7213-kC9RtJEa09@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25721

Ryan Sleevi <sleevi@google.com> changed:

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

--- Comment #3 from Ryan Sleevi <sleevi@google.com> ---
(In reply to elijah from comment #2)
> > I'm afraid you've misunderstood this specification. Keys created with this API are not like location, are not sensitive, and do not require UI confirmation. That's because the keys exposed by this API (as opposed to, say, Key Discovery, which is not part of this specification) are created at the request of the origin.
> 
> Yes, obviously, I understand perfectly well. Everyone on the internet is
> concerned with privacy, and this means NOT trusting the origin for
> everything. The origin should be able to request that keys are created, and
> use those keys, but should not have the raw key unless the user wants them
> to.

This is not a valid security model.

> 
> > Every operation permitted or exposed by this API is an operation that could be implemented within Javascript today - with greater risk (to the site operator, not the user), but possible.
> 
> Exactly the point! Allowing key extraction makes the key handling basically
> no better than what we have today, with the added false sense of security.

This is not a valid threat model.

This is explicitly out of scope of the WG, as discussed in the security
considerations.

The WebCrypto API *requires* that you trust the source of the code you're
running. Period, full-stop, there is no middle ground. This is by design, and
is intrinsic to the provisioning of a low-level API.

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.

WebCrypto provides a defense against limitations of the language - such as the
inability to implement reliable constant-time algorithms and the significant
difficulty of implementing these algorithms correctly. It does not and can not
defend against threats to privacy.

Consider the Decrypt case - there is zero added privacy by requiring the user
to be *prompted* to make the key extractable, as the origin has full access to
all plaintext that results after the ciphertext. There are zero assurances
provided to the end user about the 'security' of the site, as the origin can
always decide to use Javascript implementations - as they inevitably would if
this were needlessly gated behind added UI. This is the same way that sites can
create phishing pages - it's a BY DESIGN product of how the Web works.

You either trust the source of the code - which is the origin (or, if used in a
SysApp/Extension, the SysApp/Extension), or you do not use WebCrypto. The same
as it is with every other API.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Thursday, 15 May 2014 06:21:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:22 UTC