Re: Verified Javascript for WebAppSec re-chartering?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 09/24/2014 04:08 PM, Mike West wrote:
> Thanks, Harry.
> 
> On Wed, Sep 24, 2014 at 3:41 PM, Ben Laurie <benl@google.com> 
> wrote:
> 
>>> 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.
>> 
> 
> SRI verifies that the code sent by a server is the code that the 
> document into which that code is loaded expected to receive. It 
> doesn't do anything to ensure that those expectations match the 
> users'.
> 
> I think there's probably some value to a code-signing extension to 
> SRI (that is, verification of a signature's providence rather than 
> verification of a file's contents), but it's not clear to me how 
> that would address the threat model posited here. If you don't 
> trust the server, and you don't trust the author, what good does
> it do you to know that the code you received is the code the
> author intended you to receive?

I think its a case where you trust the author but you are worried
server may have at some point become malicious or have been subverted,
so you want to verify the code.

Again, this would apply to certain high-value WebApps.

> 
> Could you point me to a more detailed description of the actual 
> proposal?

It's in the Bugzilla:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25721

This is our interpretation of the use-case put forward by Tom.

> 
>> 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.
>> 
> 
> I totally agree with the benefit of a CT-like mechanism for 
> extensions, and I guess I could get behind a CT-like mechanism for 
> particular code snippets (though there's a huge difference in
> scope between compiling a list of all the certs ever vs all the
> code snippets ever).

+1 CT-like mechanism here.

Hehe - all code snippets over would be a nightmare. I'd say probably
"particular code snippets for particular operations" is what Tom wants.

> 
> -mike
> 
> -- Mike West <mkwst@google.com> Google+: https://mkw.st/+,
> Twitter: @mikewest, Cell: +49 162 10 255 91
> 
> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany 
> Registergericht und -nummer: Hamburg, HRB 86891 Sitz der 
> Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine 
> Elizabeth Flores (Sorry; I'm legally required to add this exciting 
> detail to emails. Bleh.)
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJUItLsAAoJEPgwUoSfMzqc5JYP/2xL35X/GNI/PblA4rbawdis
etIWjGDoQIf/W92JsqaW7rD3blijXJBU5oCPTodxxglmgiXiwWMZLncWL2cyoknW
evA72MbfLMfgNrbxtYjLXabYYj8VcxmE7xDDEi/xVKgTeuusZf2t4wG6t7vyTO+U
caEbCzqAHbe3ZKLPL3HTcKilVKOWjVUdIpd+miYGJbSXAzB83wOfRxFH2II0mj8l
ZY9VPRWAy03j1CwqkyWNO/qhnN5OkOqxE+WlbCAWe9i5hInve6XSRJdD3/D/2ZyC
UL4Zvatf8/vBa9UUBZ2KIasqcgQ4e8aAfMMmo5xZ4qkwUlYPdRlWYJJRQLkv2eLl
wc86c9SNyxn5L/5D7gR5PUFWNzn6XZBwehDna5BXZuZv1FXMIcRs05Q81awe+Vjd
iikxD9J5T+qBxd7yF6NDQ+J5BeGbe7kBEDoHJ19u6gInas7hhy7v1jH378fb2T+p
tZtEc+c+vjmvmihFgyQk4iCAW+TaSG49wq4lBpuDu8Pbymte4mNLwXeqYIAsu9ZC
4n62sT7/k4qPgQDWLfLMTHbhGgozW5Smo+TeipaKMM4Ibb6AGbAsufYg2z68Mxm+
EORLp4ycsPDXQXCf8uERnjTvHMep0xV9NBnl63JDJfI6rqpYras3cv8xNNLfhVJf
85mDL8JRCYXd1GbCxBfK
=vxOn
-----END PGP SIGNATURE-----

Received on Wednesday, 24 September 2014 14:19:33 UTC