W3C home > Mailing lists > Public > public-webappsec@w3.org > September 2014

Fwd: Verified Javascript for WebAppSec re-chartering?

From: Harry Halpin <hhalpin@w3.org>
Date: Wed, 24 Sep 2014 14:05:14 +0200
Message-ID: <5422B37A.60801@w3.org>
To: public-webappsec@w3.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1




- -------- Forwarded Message --------
Subject: Verified Javascript for WebAppSec re-chartering?
Resent-Date: Wed, 24 Sep 2014 12:02:09 +0000
Resent-From: public-web-security@w3.org
Date: Wed, 24 Sep 2014 14:01:54 +0200
From: Harry Halpin <hhalpin@w3.org>
To:  public-web-security@w3.org,
benl@google.com

[cross posting to Web Security IG, cc'ing Ben Laurie]

An interesting use-case has come up in the Last Call for the Web
Cryptography API which the Web Crypto API cannot fulfil without
further changes in the Web Security Model [1]. I'll illustrate the
use-case, although I may not do it justice so I recommend that people
read the full discussion on Bugzilla [1].

Currently, the Web Cryptography API allows keys to be either
extractable or not. The commenters have request that extractable keys
be disabled by default and activated only with some "Trusted UI"
interaction, since it seems that it would violate a user's expectation
that their private key material be sent back to the server, although
there are of course protocols that do this.

It was also pointed out that since the server at the origin can change
the JS at any time, they could change the JS so that it generated a
new extractable key and used that key for whatever cryptographic
operation was desired at anytime. In other words, the main problem is
the user has no assurance or attestation that their Javascript code in
general and their key material in particular is being used in the
manner they were hoping it would.

However, it is unclear how to do this today.  In general, from a
cryptographic standpoint, on the Web if one is trying to do any form
of trusted end-to-end communication between two users (say Alice and
Bob), the web server that mediates their communication is always
completely trusted (Trent).

This would seem to disable an entire class of applications are then
not really suitable for the Web, i.e. those applications where the
server may not be trusted. In that case, it seems that having some
third party verification of Javascript code would be useful. This may
also be useful for Web applications where the server is trusted but
may be insecure. It seems Sub-resource integrity is headed in this
direction, but we can also imagine other ways this may be tackled that
involve some third party verification of Javascript.

I believe Ben Laurie noted that in his STRINT submission some
CertTrans-like mechanism could even be used [2]. Without this, we see
developments like Chrome's e2e email extension as browser extension
rather than being done natively in the browser.

It seems that future development on the Web will require some level of
third-party attestation and assurances of both Javascript code (as
done in package managers today) as well as more secure key storage (as
falls within the remit of the Web Cryptography API re-chartering).

Thus, to respond to Tom Lowenthal and Elijah Sparrow, I'd like the
Bugzilla comment on the Web Cryptography API to fall within the scope
of possible future work items for the new charters of the Web
Application Security and Web Cryptography API.

[1]https://www.w3.org/Bugs/Public/show_bug.cgi?id=25721
[2]https://www.w3.org/2014/strint/papers/15.pdf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJUIrN6AAoJEPgwUoSfMzqcnfEQAJOpQLXyiKgzk+YVowbISWLr
ZZFXSntHbbrW8zmBt8IjtUXg5x7pYoYwC0mIPVzovxyRusE/JsuAUjk+iLNWWbC/
j+MOAVcA4URhop7vQfxaI0btC1kH0tg/hF407fPcK3SfOJu6bqMCDc5XANcqEelG
MA9GRbdwf+yNjEBE4GIkgQVdV0QpvHAFBMe2XyiWCsLEbhevn/Ppu5civ5vjYn1d
rZ+ubCYyiU6FAPxFiw80XCETusN5VVuLzRr5WA+fh74eIg1aIbUexGxiFimeS6NF
KCYt0aRMxx+3aShEQKU2rJ1HQriYZ+mD+JDaNA8fejv5h8nBOP6OW7vrEV5O2KmF
hfMe4JloTsmhUywq+yPv4bA1fKKOTZYJZdlwkQQT4SzRxFllIMWND6hsTuZRIqLL
ZUGF5IyI2EGeGFpOgEk6V+4PlaCxqYF6Hoc2hRScLI5SfRQjEZP9v3snCxztKPkf
YdX5iBuk65gFf+lvuFmoUAe8aBwZHbAAzcPoHDAOSvraYqixrmPL8p3+/dAMEg8A
eEpT3sZrrzpBqCCx4ls7q9Q/N9dqpRfBTF8d1MPaArwroHKlX+gZ9bPrtqqVRlgk
M+EuIUrjOyy+e4RFQ2XfVQ/uzdOqaRF7WYT1R7bP5NzUVqi0DZRo3r1SA9Elz4T5
g+yv6NLPuczTgtgoiRS2
=L5oD
-----END PGP SIGNATURE-----
Received on Wednesday, 24 September 2014 12:05:22 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:06 UTC