Re: Application Hash exchange between client and server

A further extension to SRI could solve this somewhat (without the client
exposure). By signing the hashes with the servers private key.

On Thu, 30 Jul 2015 at 19:08 Brad Hill <hillbrad@gmail.com> wrote:

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