Re: Application Hash exchange between client and server

I think we need (and have discussed plans to work on) an overall
"explainer" doc on how all the WebAppSec specs fit together and what best
practices are.

Re: Ahmed's original question, I think he's suggesting a remote attestation
scheme, which is not nearly as simple as he implies, and pretty far out of
scope for this group's charter.  Ahmed, you might want to check out work
happening in the Trustworthy Computing Group and Global Platform.  It's not
clear that it is desirable to apply much of that work to the Web platform,
and I suspect that it would be almost impossible to get either the
consensus or IPR commitments to take on such work anywhere in the W3C.

On Thu, Jul 30, 2015 at 9:16 AM Joel Weinberger <jww@chromium.org> wrote:

> A pointer in which direction? I assume you mean from CSP to SRI (since SRI
> points to CSP)? That may happen eventually, but keep in mind that SRI isn't
> a finalized spec yet.
>
>
> -Joel
>
> On Thu, Jul 30, 2015, 7:43 AM Conrad Irwin <conrad.irwin@gmail.com> wrote:
>
>> Thanks for the pointer. I joined the list to suggest implementing
>> subresource integrity as part of the Content-Security-Policy, because it
>> seemed like an obviously missing piece.
>>
>> I don't know what the usual way of handling this is, but a pointer
>> between the two documents would have helped significantly.
>>
>> Conrad
>>
>>
>> On Wed, Jul 29, 2015 at 11:45 PM, Joel Weinberger <jww@chromium.org>
>> wrote:
>>
>>> For your suggestion of the server sending hashes to the client, a
>>> variant of this is actually under design right now. See Subresource
>>> Integrity <http://www.w3.org/TR/SRI/> (and the many discussions on this
>>> list about it).
>>>
>>> For the client to server hash, this is unlikely to be implemented, for
>>> several reasons:
>>>
>>>    - As described, the application could lie to the server, so there
>>>    would be no benefit. A "bad" browser could run Chrome, get the hash it
>>>    sends, copy that hash, and start sending it to the server as if it was its
>>>    own.
>>>    - Even if some version were to be implemented (using TPMs, for
>>>    example, or even just OS level constructs), this would almost certainly be
>>>    a violation of the Priority of Constituencies
>>>    <http://www.schemehostport.com/2011/10/priority-of-constituencies.html>.
>>>    What you've described is a form of remote attestation
>>>    <https://en.wikipedia.org/wiki/Trusted_Computing#Remote_attestation>,
>>>    which generally has been rejected on the Web (with notable exceptions
>>>    surrounding DRM). Basically, a user agent *should* be allowed to
>>>    lie. In fact, this is how in browser compatibility traditionally has
>>>    worked, and why every user agent string has the words "Mozilla" and "IE" in
>>>    it.
>>>
>>> --Joel
>>>
>>> On Wed, Jul 29, 2015 at 3:29 PM Ahmed Saleh <ahmedzs@live.ca> wrote:
>>>
>>>> Hi Sir/Madam,
>>>> It would be a nice feature if we can exchange hashes between server and
>>>> browser. a client as a browser would send clients' browser hash signature
>>>> and the server would send it's application hash signature. This way, as a
>>>> client, I would insure that I am communicating to the right version of
>>>> application I intend (in case if this application is open source) and as a
>>>> server, the server would insure that it's communicating to the right
>>>> clients' browser as intended(that for example, could protect and view my
>>>> data).
>>>> Thank you,
>>>>
>>>>
>>