Re: security of a client-side JS API?

On Wed, Oct 31, 2012 at 1:31 PM, Arthur D. Edelstein
<arthuredelstein@gmail.com> wrote:
> Hi Ryan,
>
> Thanks for your very thorough and thoughtful response.
>
>
>>> Users will need to trust the web app to properly
>>
>> > secure their data, which is the status quo.
>>
>> Is this different from native apps, which requires the user trust the
>> application vendor?
>
>
> Indeed I worry this is just as bad as most native apps, and just as bad as
> the web currently is, for user data security.
>
>
>>> Web app providers are also threatened by a leaky implementation of the
>>> Crypto API in a web client (for example, a bot with a bad RNG or key
>>> generator). So providers will prefer to use server side key generators,
>>> etc.
>
>> I don't think this is necessarily true - there are a host of reasons
>> why providers are strongly incentivized not to do crypto on their end,
>> most notably legal reasons.
>>
> What sort of legal reasons do you have in mind? I think if legal protection
> for providers is the most notable motivation for providing the Crypto API,
> that should be explained in the draft, as well as any other important
> motivations.

I think you misunderstood what I meant.

If a provider is wishing to accept some form of signature as being
provided by a user (say, for document signing), then the provider is
typically legally (via appropriate government standards) prohibited
from key escrow, which is effectively what you are suggesting.

So no provider will want to, or necessarily be able to, keep the
private key that is supposed to identify the user *on the server*.

>
> But I think it's also important to mention the issue of hostile web bots --
> it's really impossible for the server to trust crypto results from the web
> client.

And that's not a goal of the API.

To put it differently, "it's really impossible for the server to trust
form results from a web client over TLS" - no matter how much client
JS validation they put in.

We're not trying to provide an API that somehow removes the web
content from being an active participant in the security conversation,
which is an entirely different set of problems. That said, it IS
possible with this API **and combined with others** to accomplish
that, but I do not think that this needs to provide a holistic
implementation of that solution (nor is it born out necessarily by the
use cases)

>
>>
>> But even more broadly, how does this at all differ from native
>> applications? They're just as dependent on the platforms cryptographic
>> stack. Servers have no control over that end.
>
>
> Yes, I agree. Which is why server-side crypto is necessary for the securing
> the provider's data. Platform vulnerabilities are a problem, but that
> doesn't excuse vulnerabilities in user agents.

I apologize, but with the context with your earlier remarks, I'm still
not entirely sure the point you were originally trying to make or
where the gap is, but would be happy to try to better understand.

>
>> Perhaps I'm mistaken, but we're not trying to necessarily provide new
>> security guarantees over existing native applications - we're
>> attempting to bring (some of) the same security model to the web -
>> which suggests improving the web security model.
>
>
> I'm arguing that you're not improving the web security model.

That is correct. We are not trying to improve the web security model
and that is not part of our charter. WebAppSec is the general W3C WG
for focusing on such security issues.

> Web browsers
> already support secure communication between a provider and a user agent (by
> TLS), but users are forced to trust the provider with their (user) data.
> This API, even with CSP, similarly requires that the web app provider be
> trusted by the user not to leak data.
>
> So all the additional cryptographics primitives, because they are untrusted
> by both users and providers, don't plug any holes that weren't already
> plugged by TLS.

This is true for some use cases, but is not true nor applicable to the
broad set of use cases already collected. My suspicion based on this
response is that you're looking at this API with a particular use case
in mind, and deeming it unable or unwilling to address that use case.
This is quite possibly true, and it would be good to understand that
use case.

However, there are use cases (both in our document and in our wiki)
that this does serve to address, and I'll be working on providing
better documentation in the future, to show how this fits in the
overall web platform so that you can use that to see what it is and is
not trying to address.

>
>> To put it differently, nothing of this API is trying to make the
>> connection *more* trustworthy - that requires much more work across
>> many different domains, and which have little-to-no reliance or need
>> for cryptography to do that.
>
>
> In my view, end-to-end encryption, implemented in the browser, would provide
> a major, important upgrade to the web security model and make communications
> (including most of the use cases presented in your draft) much more
> trustworthy. End-to-end encryption necessarily means that cryptographic
> operations would be controlled by the user, not by the web app client-side
> JS, and that the JS code would only have access to the encrypted material.
>

There are certainly use cases for that, and I'm not at all trying to
be dismissive of those, but those aren't the only use cases, nor is
the solution proposed necessary or correct to meet them.

That said, and as I mentioned earlier, you can use this, **in addition
with other APIs**, to implement exactly what you propose. For example,
using system apps/extensions/webapps/whatever your browser vendor or
standards body of choice calls them, you could implement a secure (eg:
NOT part of the target origin) application that provided input
methods, and output encrypted text. There are many ways that a relying
application could invoke such extension behaviour, such as web
intents, extension-registered scheme handling, URI redirection, etc.
These are all very much user-respecting APIs that allow them to
maintain control (as to how user-friendly such a scenario is, or how
many users actually would want such a scenario, is a different
matter).

You can already see this model in extensions like CryptoCat, to some
degree. The utility of this API, in such a scenario, is that it makes
it *easier* to develop such applications, and ideally, *more
efficient*, and does not require such extension/app authors to be
fully versed in the implementation details of how SHA-1 is
implemented, and can instead be aware that SHA-1 should be used (for
example).

> Browsers could provide a means for users to encrypt the text the wish to
> enter in a TextArea, to display decrypted text, and to encrypt and decrypt
> files, all safely outside the page's JS runtime. This enhancement would give
> users of existing web services, such as web-based email, chat and file
> storage a major security boost. PGP and OTR modes would both be useful.
>
> Is there any chance the Web Crypto WG could recommend this kind of browser
> end-to-end crypto design? I think this alternative offers huge advantages
> over the proposed API for addressing the use cases you describe in the
> draft.

I'll be speaking tomorrow at our face to face meeting at the W3C TPAC
tomorrow, and hopefully providing more details on our wiki following
that. Nothing in this API is antagonistic towards such solutions, and
since the beginning, we've discussed such solutions. The current draft
makes it **easier**, when combined with other appropriate web
technologies, to allow developers to implement such solutions, rather
than requiring the browser vendors to do so themselves.

>
> Thanks again for so patiently hearing me out!

And thank you for your feedback! It's provided an excellent
opportunity to provide a better explanation of what we're (currently)
trying to do, and hopefully provides some context as to where this
fits in the overall web platform. Hopefully we'll be able to provide
more high-level details (eg: not directly in the spec) that may help
better demonstrate where the current spec sits, and where the overall
work in the WG fits within the web platform. I think you'll find that
we're actually working towards the same thing, just at different
levels and with the understanding and assumption that some of the
problems you raised are either already addressed or being addressed
elsewhere within the W3C and the web community.

>
> Best regards,
> Arthur
>

Received on Wednesday, 31 October 2012 20:53:58 UTC