Re: "Subresource Integrity" spec up for review.

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.