Re: security of a client-side JS API?

Again, Ryan, thanks for your time and effort in answering my questions.

> > 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.

Sorry about that, I did indeed.

> 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*.

I had the impression from the API spec that crypto operations would
use private keys without exposing to the web app the actual value of
those private keys. Nonetheless the user would still be exposed to
signing the wrong document. So I still think stating in the spec that
legal protections are required for this part of the API to work, is
very important.

> > 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.

Why is signature verification included in the API, then?

> 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.

Exactly.

> >> 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.

Sorry, perhaps I don't understand your point about native apps. I
agree that native apps have similar vulnerabilities, but I don't
understand why that is relevant to the question of whether this API is
useful for providing security.

> >> 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.

I'm sorry, I misunderstood your phrase "suggests improving the web
security model."

> > 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.

No, I have in mind the use cases in your draft. Here's the attacks I
see (Forgive me if I'm misunderstanding something fundamental. I think
these concrete cases really illustrate my concerns and help to clarify
what I have been attempting to express.):

2.2. Protected Document Exchange & 2.3. Cloud Storage
Attack: The web app indicates to the user that a document is being
encrypted, and requests a public encryption key, but retains an
unencrypted copy of the document.

2.4. Document Signing
Attack: The web app presents the user with a document to sign,
requests a key from the keystore for signing, and then invisibly uses
that key to sign a different document.

2.5. Data Integrity Protection
Attack: The User Agent provides a false verification of stored data.

2.6. Secure Messaging
Attack: The web app steals plaintext OTR messages after they have been
decrypted for display to the user.

2.7. Javascript Object Signing and Encryption (JOSE)
Attack: The User Agent provides a false verification, or the web app
steals decrypted user data.

Two I'm less sure about:

2.1. Multi-factor Authentication
I admit this may be secure (I'd need to study it more), but I don't
see any advantage over TLS + server-side multi-key verification.

2.8. Out-of-Band Key Provisioning
I'm not sure I understand what crypto operations the web app client
side is performing here.

So, what prevents these attacks from happening? Isn't this a serious
problem for the API design?

> That said, and as I mentioned earlier, you can use this, **in addition
> with other APIs**, to implement exactly what you propose [end-to-end encryption]. 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.

Exactly, and if the Crypto API were limited to this usage, I would
have no objection. I'm concerned about its exposure and use in web
apps.

> 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).

I agree, absolutely.

> > 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.

> 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,

Yes, I'm sure we are. I am looking forward to hearing more details at
your meeting.

> 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.

If you have any hints on who in W3C might be working on a proposal for
an end-to-end encryption standard for the browser, I'd be very
grateful! I haven't found it yet. :)

I hope your meetings go well and that you're enjoying Lyon in between
answering my emails!

Best regards,
Arthur

Received on Wednesday, 31 October 2012 23:54:32 UTC