Re: "Subresource Integrity" spec up for review.

On Tue, Jan 14, 2014 at 7:55 AM, Brad Hill <hillbrad@gmail.com> wrote:

>
>
> On Mon, Jan 13, 2014 at 12:46 PM, Ryan Sleevi <rsleevi@chromium.org>wrote:
>>
>>  ...
>>>
>> I think it's a bit of a stretch to suggest that because traffic analysis
>> exists as a possibility that HTTPS provides limited-to-no-privacy,  ...
>>
>>
> That's a much stronger claim than I'm making. I'm only suggesting that
> some resource loads aren't very privacy-sensitive to begin with, and
> probably can be observed or inferred anyway over HTTPS, so I think there is
> limited or no harm in performing them with only integrity protections.
>  Granted, of course, we can't enforce in spec language or code that only
> such resources would be used with this technology, but privacy is always a
> matter of trusting your counterparty to be responsible.
>
>
>>
>>> ...
>>>
>> As browser vendors, we have an obligation to our users to ensure that
>> their security is preserved, and, whenever both possible and reasonable,
>> that their *expectations* of security is preserved.
>>
>> Today, there is a simple duality of the web. Either you're browsing in
>> HTTP - in which there is absolutely no security whatsoever - or you're
>> browsing with HTTPS, which provides a combination of assertions about
>> identity (namely, domain ownership), privacy, and integrity.
>>
>> If a user visits https://site.example and it loads sub-resources over
>> HTTP with integrity protection - which is, at it's core, the crux of #6 -
>> what would or should the UI indicate. Is it reasonable to show the famed
>> 'lock' icon in this case - even when the traffic is visible to an
>> attacker/observer? Does that align with users expectations? I don't think
>> it does.
>>
>
> I think this is a very good question indeed.  I appreciate the effort to
> make clear security statements to the user, and the lock, while mysterious
> in its inner workings, is about all we have right now.  I agree that it is
> a bad idea to devalue it, and it could risk trust in the web overall.
>
> Along these lines, I wonder about the integrity cache idea.  What's the
> effective difference between allowing an HTTPS resource with the lock to be
> composed from pieces that might've been fetched as part of a different
> (secure or not) resource or delivered with an app, versus doing an
> immediate fetch-with-integrity over insecure channels?  What are the actual
> essential properties we're trying to communicate to the user with the lock,
> and what violates them?  Just something to think about and discuss further,
> since I like the integrity cache idea even more than I like the
> mixed-content with integrity idea.
>
>
>> You can always refer to edge-cache controlled names within your resource
>> loading URLs. If, for various reasons (eg: SOP, CORS, etc), then you can
>> always delegate a sub-domain, as many organizations are already doing.
>>
>
> Good point.
>
>>
>> If your threat model is state level attackers and/or legal compulsion,
>> you can *still* use the integrity protected sub-resources - but deliver
>> those resources over HTTPS. HTTPS avoids the mixed content, and provides
>> real and meaningful integrity protection (eg: without worrying about the
>> hash collisions implications of vastly unstructured data like JS), and then
>> this use case just fits into the #1/#2.
>>
>> I still think that the integrity attribute is useful here, even if we
> assume HTTPS, because the distributed nature of a CDN puts so many more
> entities in a position of privilege, and if you're loading script,
> importing HTML or even loading images, it's still your origin at the end of
> the day from the user's perspective.
>
+1 to Brad's point here. From my perspective, this is, in fact, probably
the most important part of the integrity spec. Without integrity,
regardless of HTTPS or not, many websites are instilling trust in CDNs that
is simple unnecessary. It provides many more attack vectors, and there
isn't a reason that should be. With the integrity check, it allows the
original server to be the authoritative source of content. CDNs are reduced
to what they originally were meant to be: content distribution only, with
no authority. This seems extraordinarily useful to me, with HTTP or HTTPS.