Re: [CSP] "sri" source expression to enforce SRI

So, this thread seems to have gone a bit stale. It seems like the primary
argument against the idea was "CSP bloat". Another thread was opened up to
discuss that specific issue in more detail (definitely worth discussing, as
it would be a shame to artificially limit the potential of CSP simply
because we run out of room) . In general I think a mandatory SRI directive
makes a lot of sense. I generically view CSP as a set of rules I can look
at and, without even looking at the associated HTML, make some declarations
about how the HTML/JS/CSS/etc on the page will behave. I think it would be
quite a natural extension of SRI to have a CSP directive that let you be
assured that that no resource on the page will be loaded without some
integrity protection validation done. And, as I mentioned above, this is a
really nice belt and suspenders check. In most cases, when an app converts
over to using SRI, the intention is to use it everywhere. But, it is
relatively easy for people to miss a handful of one-off resources given the
"fail open" nature of having no integrity attribute. Having a CSP directive
would provide a great way for apps to "fail closed" and will surface any
latent resources that are missing the attribute.

On Sat, Jan 9, 2016 at 5:41 AM Eduardo Robles Elvira <edulix@agoravoting.com>
wrote:

> I like Patrick's idea, so let me try to explore a couple (wild?)
> possibilities:
>
> Idea #1
>
> Would you commit to having the page the resources hashed for a period of
> time? If so, we could have something like "HSTS for subresouces integrity".
> A header that says "[this page|all the pages of this domain|all the pages
> of this domain and subdomains] will be hashed for at least the next X
> days".
>
> This would allow an user agent to check that all resources are checked
> even if for some reason you "forget" to send the "hash everything" header
> that Patrick is proposing. This would effective to a deployment
> configuration error in a server/subdomain or to specific servers being
> compromised.
>
>
> Idea #2
>
> Let me emphathise something Patrick mentioned:
>
> "we vendor everything to ensure what is in *version control* is what is
> used in production"
>
> Looks like this header is useful for version control. This can be done
> inside the organization as Patrick is doing at github, and each
> organization might do it in their own way. But what if we did it in a
> generic way? If we knew (thanks to idea #1) that a specific page is going
> to be in version control, we could have web crawlers (Google, Bing, any)
> record the integrity hashes of web pages in a public log, something similar
> to Certificate Transparency/CT, let's call it "Integrity Transparency".
>
> You could even have a header similar to the one in #1 that says "we assure
> that we will always reconrd in the public integrity log the hashes of our
> pages before we put them in production/or within X hours", then any user
> agent vising the page could check that the page is in the integrity log,
> and check that the integrity has not been tampered with.
>
> Integrity Transparency is substantially different from CT because instead
> of being sure that "you are getting the same TLS certificate as everyone",
> it would allow you to make sure that "you are getting the same web page as
> everyone". Or in other words, it could be basically version control for the
> web.
>
> Of course there are practical issues with that, like registering the
> hashes of websites that have thousands or millions of web pages, but looks
> as viable as CT for single-page webs and specific pages. Even registering
> only the index page could prove useful.
>
>
> --
> Director Técnico              CTO                 Agora Voting
> Eduardo Robles Elvira     @edulix            @agoravoting
> +34 634 571 634 <http://agoravoting.org>             skype: edulix2
> http://agoravoting.org
>
> On Wed, Jan 6, 2016 at 7:27 AM, Joel Weinberger <jww@chromium.org> wrote:
>
>> I think this thread has officially been forked/hijacked :-) May I suggest
>> starting a new thread to discuss header size and policy delivery so this
>> can remain a thread about SRI policy?
>>
>> On Tue, Jan 5, 2016, 5:12 AM Mike O'Neill <michael.oneill@baycloud.com>
>> wrote:
>>
>>> A manifest file definition would be very useful, especially if it was
>>> extensible. Has that been defined for ordinary web sites, e.g. not only
>>> hosted web apps? Are any sites using them?
>>>
>>>
>>>
>>> I have a use for it I am working on, not for headers though yet.
>>>
>>>
>>>
>>> *From:* Jonathan Kingston [mailto:jonathan@jooped.co.uk]
>>> *Sent:* 05 January 2016 11:53
>>> *To:* Mike O'Neill <michael.oneill@baycloud.com>; Nottingham, Mark <
>>> mnotting@akamai.com>; Chris Palmer <palmer@google.com>
>>> *Cc:* Brad Hill <hillbrad@gmail.com>; Joel Weinberger <jww@chromium.org>;
>>> Patrick Toomey <patrick.toomey@github.com>; Richard Barnes <
>>> rbarnes@mozilla.com>; WebAppSec WG <public-webappsec@w3.org>
>>>
>>>
>>> *Subject:* Re: [CSP] "sri" source expression to enforce SRI
>>>
>>>
>>>
>>> Yup Mike I had suggested the use of SRI in the header and pointing to
>>> some form of manfest file.
>>>
>>>
>>>
>>> I think this addresses some of Marks concerns about header size however
>>> creates other issues such as cache management and extra round trips.
>>>
>>>
>>>
>>> The advantage of the manifest also would allow separation of concerns
>>> between CSP and SRI within the policy.
>>>
>>>
>>>
>>> On Tue, 5 Jan 2016 11:29 Mike O'Neill <michael.oneill@baycloud.com>
>>> wrote:
>>>
>>> I don’t know if this has already been talked about, but maybe long
>>> headers
>>> like CSP can be could be put in a well-known resource. It would cost
>>> another
>>> roundtrip but save bandwidth in the end  because the resource would be
>>> cached. The CSP header would only need to contain a hash of the resource
>>> to
>>> confirm
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Nottingham, Mark [mailto:mnotting@akamai.com]
>>> Sent: 05 January 2016 01:59
>>> To: Chris Palmer <palmer@google.com>
>>> Cc: Jonathan Kingston <jonathan@jooped.co.uk>; Brad Hill
>>> <hillbrad@gmail.com>; Joel Weinberger <jww@chromium.org>; Richard Barnes
>>> <rbarnes@mozilla.com>; Patrick Toomey <patrick.toomey@github.com>;
>>> WebAppSec
>>> WG <public-webappsec@w3.org>
>>> Subject: Re: [CSP] "sri" source expression to enforce SRI
>>>
>>> Catching up after holidays -- I've been wanting to talk about this.
>>>
>>> In HTTP/2, the default of SETTINGS_HEADER_TABLE_SIZE is 4k.
>>>
>>> >From what I've seen, Chrome and Firefox both stick with the default.
>>>
>>> While 4k of header compression context can help performance considerably,
>>> it's important to understand that HPACK's compression scheme is
>>> coarse-grained, so when the encoder is faced with a large header, it has
>>> to
>>> choose between putting it into the dynamic table -- thereby denying use
>>> of
>>> that space to other headers -- or repeatedly putting it out onto the
>>> wire.
>>>
>>> For example, Twitter's response headers already get close to this limit,
>>> mostly thanks to CSP:
>>> https://redbot.org/?id=w5yLyD
>>>
>>> Their server has to choose between putting that ~3K CSP header into the
>>> dynamic table, leaving them only about 1k to play with for other headers
>>> per
>>> connection, or leave it out, and send it verbatim on EVERY response.
>>> They'll
>>> get small benefit from static Huffman coding (which reduces the numbers
>>> above a bit), but that's it.
>>>
>>> If a single header value exceeds SETTINGS_HEADER_TABLE_SIZE, it can't be
>>> encoded by reference, and the sender has no choice but to emit it on
>>> every
>>> message.
>>>
>>> Things get even nastier if there are several large versions of CSP on a
>>> single connection.
>>>
>>> Clients could start advertising a larger SETTINGS_HEADER_TABLE_SIZE, but
>>> that means a larger state commitment (both client-side and server-side,
>>> where it can hurt a lot more, offers more DoS exposure, etc.).
>>>
>>> Given that we're already seeing popular sites brush up against this,
>>> PLEASE
>>> don't assume that HTTP/2 == free compression, and that we can continue to
>>> merrily add headers.
>>>
>>> Also - when a header is both large and monolithic like CSP (i.e., it
>>> doesn't
>>> allow multiple values to be combined into a comma-separated value), it
>>> makes
>>> it much harder to optimise for compression, because of HPACK's
>>> granularity
>>> (again). I realise that there are security motivations behind this for
>>> CSP,
>>> but I wonder if the cost is justified (because once somebody can append
>>> headers, there's a lot of other damage they can do).
>>>
>>> Cheers,
>>>
>>>
>>> > On 23 Dec 2015, at 1:38 pm, Chris Palmer <palmer@google.com> wrote:
>>> >
>>> > HTTP/2 should do a lot to address header bloat, just as it addresses
>>> other
>>> performance problems.
>>> >
>>> > And, as usual, import content_layer_heaviest from stdarg. :)
>>> >
>>> > On Tue, Dec 22, 2015 at 6:13 PM, Jonathan Kingston <
>>> jonathan@jooped.co.uk>
>>> wrote:
>>> > Perhaps the bloat is something that actually needs to be addressed?
>>> Creating many headers doesn't really solve the bloat issue.
>>> > I agree that it doesn't need to be the core CSP spec especially as we
>>> have
>>> UI Security separate etc.
>>> > But yes when we discussed this last certainly one directive isn't
>>> flexible
>>> enough for example when SRI expands to images having all assets on the
>>> page
>>> requiring SRI would probably be too inflexible.
>>> >
>>> > On Tue, Dec 22, 2015 at 7:40 PM Brad Hill <hillbrad@gmail.com> wrote:
>>> > I'm open to either possibility. In the past we've talked about things
>>> like
>>> fallback policy (e.g. if CDN content from untrusted host X fails the hash
>>> check, try to load from a trusted canonical https source, host Y) that
>>> would
>>> be tricky to shoehorn into the CSP directive parsing logic, and policy
>>> combination is another area where it is good not to overcomplicate CSP.
>>> >
>>> > On Tue, Dec 22, 2015 at 11:29 AM Joel Weinberger <jww@chromium.org>
>>> wrote:
>>> > FWIW, I think either approach is fine. I know that, in general, we've
>>> been
>>> concerned about CSP bloat, so for that reason alone it might be worth
>>> moving
>>> it to its own header. But I don't really care at all either way.
>>> >
>>> > On Tue, Dec 22, 2015 at 2:28 PM Richard Barnes <rbarnes@mozilla.com>
>>> wrote:
>>> > I'm not sure I agree with that, Brad :)  CSP is where we place
>>> restrictions on loading things, and "must have SRI" is a restriction on
>>> loading things.
>>> >
>>> > On Tue, Dec 22, 2015 at 2:26 PM, Brad Hill <hillbrad@gmail.com> wrote:
>>> > Yeah, we'd discussed a SRI policy header / meta tag to express a
>>> number of
>>> things like this, it just got dropped from v1 to get it out the door.
>>> Not
>>> sure shoehorning it into CSP is the right choice, especially since the
>>> reporting mechanism is already being factored out into its own, reusable,
>>> feature.  Might be simpler to define a standalone header.
>>> >
>>> > On Tue, Dec 22, 2015 at 11:24 AM Richard Barnes <rbarnes@mozilla.com>
>>> wrote:
>>> > Some sort of "must-sri" directive is something we had considered inside
>>> Mozilla for some of our properties, so this does seem like a productive
>>> thing to look at.  I don't have any personal biases about how exactly to
>>> express it.
>>> >
>>> >
>>> > On Tue, Dec 22, 2015 at 12:07 PM, Patrick Toomey
>>> <patrick.toomey@github.com> wrote:
>>> > Yeah, a separate directive probably makes sense. I was originally
>>> thinking
>>> it fit into the "locations that are safe" pattern since we are stating
>>> that
>>> a location is only safe if it has a known hash (using SRI) from that
>>> location. But, I realize that is a stretch. And, you have a good point
>>> about
>>> being able to put other SRI related things in if we have a separate
>>> directive. So, yeah, that is probably the cleaner way to go. Thanks for
>>> opening the tracking issue.
>>> > On Tue, Dec 22, 2015 at 9:32 AM Joel Weinberger <jww@chromium.org>
>>> wrote:
>>> > That's a good point about SRI in general; it's hard to know if you've
>>> forgotten to SRI anything. I'm not sure source-expression is the right
>>> place
>>> to put it in CSP, though, as that's meant to be "locations that are
>>> safe,"
>>> and that's not exactly what you're requesting. It probably makes sense to
>>> have an 'sri-options' directive, though, since we'll probably want SRI
>>> 'report-only' eventually anyway.
>>> >
>>> > I've filed this as a feature request in GitHub, too:
>>> https://github.com/w3c/webappsec-subresource-integrity/issues/23
>>> > --Joel
>>> >
>>> >
>>> > On Tue, Dec 22, 2015 at 2:50 AM Patrick Toomey <
>>> patrick.toomey@github.com>
>>> wrote:
>>> > We recently deployed subresource integrity across GitHub.com:
>>> https://github.com/blog/2058-github-implements-subresource-integrity.
>>> However, a few days after deployment we determined that one of our JS
>>> scripts did not have an "integrity" attribute assigned to it. It was our
>>> intent to add the integrity attribute to all subresources on GitHub.com.
>>> We
>>> statically vendor in all CSS/JS and use Sprockets (SRI support was added
>>> in
>>> https://github.com/sstephenson/sprockets/pull/645) to package these
>>> assets
>>> for production deployments. There happened to be one JS file that had not
>>> been vendored, and hence was not being packaged by Sprockets. This
>>> violated
>>> two of our goals:
>>> >
>>> > * Not allowing any dynamically sourced JS (we vendor everything to
>>> ensure
>>> what is in version control is what is used in production)
>>> > * Enforcing SRI on all supported subresources on GitHub.com
>>> >
>>> > Reflecting back on this situation, it would have been nice to have
>>> support
>>> in CSP for a source expression such as
>>> "sri"/"sri-only"/"sri-naming-things-is-hard" to ensure SRI is being used
>>> everywhere. In the above scenario, the related JS would have failed to
>>> load
>>> and we would have identified both of the issues listed above in testing.
>>> >
>>> >
>>> >
>>>
>>> --
>>> Mark Nottingham    mnot@akamai.com   https://www.mnot.net/
>>>
>>>
>>>
>