Re: Subresource Integrity strawman.

Hey all. First off, I wouldn't qualify myself as a "security" person, so
pardon my ignorance... A few high-level questions:

Authors must trust that the resource their content delivery network
> delivers is in fact the same resource they expect. If an attacker can trick
> a user into downloading content from a different server (via DNS
> poisioning, or other such means), the author has no recourse. Likewise, an
> attacker who can replace the file on the CDN server has the ability to
> inject arbitrary content.


Isn't this redundant with HTTPS + HSTS? MITM aside, the transport layer
guarantees data integrity and (pinned) authentication. In light of that,
does this spec provide anything extra? It seems like it would be much
simpler to simply recommend using HTTPS + HSTS.

Provide authors with a mechanism of reducing the ambient authority of a
> host (e.g. a content delivery network, or a social network that provides
> widgets) from whom they wish to include JavaScript. Authors should be able
> to grant authority to load a script, not any script, and compromise of the
> third-party service should not automatically mean compromise of every site
> which includes its scripts.


Ok, to answer my own question: the extra bit of security is that you're
effectively freezing a hash and if your pinned host is compromised and file
is replaced, then UA will bail on execution - right? At which point, if you
absolutely must have control over the target script, why not just freeze it
on a local server? Some sites do that exactly that when deploying third
party widgets / analytics / etc... some for security reasons, others for
performance.

Further, it seems like in practice the proposed example wouldn't actually
fly:
*<script src="https://analytics-r-us.com/include.js
<https://analytics-r-us.com/include.js>"*
*        integrity="ni:///sha-256;SDfwewFAE...wefjijfE"></script>*

The whole point of providing a generic "ga.js" or "include.js" is that it
can be revved by a third party - e.g. updates and security fix deploys...
If I add an integrity tag on these resources, I effectively guarantee that
my site is broken next time analytics-r-us.com revs their JavaScript. Once
again, it seems like if you must have this control, you're better off
freezing a local copy on your server, auditing it, and being responsible
for updating it manually.

Long story short, it seems like this is an unnecessary layer if we assume
HTTPS is place? Or, am I missing something obvious here? If we assume
non-HTTPS world, then yeah we're talking about adding an integrity layer,
but it seems rather clunky/complicated. I'd rather just push people to
adopt HTTPS?

ig