Re: security of a client-side JS API?

In addition to Ryan's comments, few thoughts of my own.

On 10/30/12 2:43 PM, "Arthur D. Edelstein" <arthuredelstein@gmail.com<mailto:arthuredelstein@gmail.com>> wrote:

Hi Everyone,

I've read through the WG and public comments list archives, and I am
concerned that an objection partially raised in the WG mailing list
("Is our deliverable doomed ?", 18 September) hasn't really been
clearly addressed.

The API is supposed to be used inside a web app's client-side JS
runtime. But the problem with client-side JS is that it is under the
full control of neither the user nor the web app provider. The app
provider (though she trusts her own web app JS code) doesn't know if
the WebCrypto API is running correctly and honestly on a particular
user agent instance, and the user (though he may trust the user agent)
can't know if the client-side web app is using the API correctly and
honestly. So in practice, neither side can have confidence in these
utility functions.
I think this is where it should be made clear how there was never an automatic trust between a client and a server in any crypto protocol. Even considering native application clients, the server they are communicating with cannot automatically tell that the client is their native application. So, the server always has to use established (by their individual designs) protocols to prove the identity of the client or user using the client. This API just lets a client implementation (running in a browser) to participate in such a protocol with minimal coding. The question then becomes how a JS is given access to keys on the client side – in my mind it is a combination of CSP (as Ryan mentioned) and user training. Today, there is already an expectation on the users to be vigilant (check the URL, check green bar, heed browser warnings, etc.) - this API is not intended to relieve the user of such vigilance. If you think about it, users are already performing so many sensitive operations using the browser – entering their username/password, checking their bank accounts, applying for mortgages, and so on. If all the web sites waited for a truly trusted client, we will not have the web of today.

Numerous cryptographic solutions exist for the server side already, so
it seems to me that responsible web app providers are going to prefer
to do their cryptographic operations on the server, in an environment
they control, rather than use this API. Worse, people who do use this
API may have misplaced confidence in its security.

So I think it would be useful, in the specification, to clearly state
what security guarantees can and cannot be delivered by this API, and
when it is better (for web app developers) to use server-side crypto
libraries. Thanks in advance for considering my comment.

Sincerely,
Arthur Edelstein
UC San Francisco