Re: W3C Web Crypto WG - Is our deliverable doomed ?

On 9/18/12 3:29 PM, "Ryan Sleevi" <sleevi@google.com<mailto:sleevi@google.com>> wrote:

On Tue, Sep 18, 2012 at 2:00 PM, Seetharama Rao Durbha
<S.Durbha@cablelabs.com<mailto:S.Durbha@cablelabs.com>> wrote:
Well, I guess then we need to bullet list those 'some'. My suspicion is that
most of them are (browser) implementation specific and carry no impact to
the API itself. As you pointed out earlier, JS has no way of verifying the
environment in which it is running, and thus cannot judge the (browser)
implementation. So, the application developers themselves will have no
additional benefits beyond the API.

Which I did highlight and bullet point.

Quoting from an earlier email.


 *   This work
    *   Our API so far provides secure RNG and functions with known-timing characteristics, along with a secure keystore. Yes, we don't offer a secure erase, nor do we offer a generic secure memory comparison, and perhaps those are things we can look at in the future. But I'd suggest that, given the general framework of what is brought by the API, it's not as c
==>Security is an implementation detail, not an API guarantee. Users may trust Chrome, Firefox, Safari and Opera to be secure implementors of this API, but that is outside of this API.


 *   Content Security Policy
    *   Can address the malleability problem and the prevalence of content-controlled code
==>Content security policy is yet to be discussed by us.  But it still gives no way for the client (and sever) sides to verify that the API is not changed. It is an implicit trust obtained through the user using the right browser that implements content security policy correctly.


 *   Web Intents
    *   Can address the malleability problem and the prevalence of content-controlled code
==>Same note as above


 *   The view-source transparency is illusory
    *   The W3C has, through various efforts, looked at offline [1][2] and system applications [3] that can provide stable source over time.
    *   Several popular user agents implement support for forms of signing or organizational validity that is equivalent to native code.
    *   Given many auto-updating systems today, the same argument can be made of native applications.
==>All points seem extraneous to this API


 *   If you have SSL, just use SSL
    *   As demonstrated by our use cases, SSL is not in and of itself suitable or equivalent to what is being requested.
 *   An exploit server side can compromise tens or hundreds of thousands of users
    *   As demonstrated by the Flame attacks, this is equally true for native applications.
    *   As the mobile web continues to take off, it's not uncommon to see study after study looking at mobile permissions or implementation details that show mobile, "native" applications are just as susceptible  Yes, this is a valid attack class, but it's increasingly becoming no different than 'native' code.
==>Again, nothing specific to this API.