Re: Verified Javascript for WebAppSec re-chartering?

On 24 September 2014 13:01, Harry Halpin <hhalpin@w3.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> [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.

It seems to me that whether this is possible depends on what else goes
on with the key - for example, if the user or others are aware of the
fingerprint of the key, generating a new one without noticeable
consequence would not be feasible.

In any case, most software gets updated these days, so any threats
that involve code changes are applicable to ... everything and not
just JS on the Web.

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

Extensions are also updated automatically, so I don't see how this
helps, particularly.

That said, a CT-like mechanism could help with all of these cases.

> 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)
>
> iQIcBAEBAgAGBQJUIrKyAAoJEPgwUoSfMzqc+BgP/0dWqFJHnEs8C4vUPq7J8dhN
> 1IYSH+eTwnZ/ClqE1IQPFk93cja+psIvx182YdZbAmonZPLFTMhOs1Sl4p74E8JU
> taR2i2ycQaPShzPNAOTsuAn1pqvUpiu48knsZEfo6Wh7M25QJ0m04wBjCvpmwL/b
> gcliK6RHqKWhez+D54KDBl2PCuCBXFQ/d2bYm+cYa/PznNWpUxiCUfGktCusby/L
> 37uydu28AU3RW+GEeWx6hJLnv6YlBCd3Ojl2wDzcLf8LXZ6X+oNem6yFApfRSvUC
> xM44WPmRg47RJxbCSqKNV+pnage5CVgkKHAYTBGwMZ87vH/d9IsM9SJ6b8IVd/CR
> Rem6VTy6sRQD8pCts+C664izBby2Mn0ll/oK9czqirDmZuiHakhH2PEot47GaaL+
> u5+eWyhvY15YoxqgkkQUEJU8pousbauD1BOf6aF8fFDResyfY1isP+F9skczqVLE
> EYJvS8q5N10OAGwzr/SVbFyk8WzstrPNd4lydeM4LXVwscFt3vJUV3vQmjInbdY9
> Ws6YKerL3Vtmw1rtj9IRRoWQCj9Op5WE0dXTA5czPO99arKEO33o3Y4vYxFL2bTu
> a5LSSluTLG/+/d/vcDqZZWAvorVm6zup3HQWgKAZFFVj83UN+TeMnufbaDzJd+IR
> 6JSdH28tpO4ioDGenxB3
> =VGNf
> -----END PGP SIGNATURE-----

Received on Wednesday, 24 September 2014 13:41:56 UTC