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

Just for clarity, there are two kinds of bloat: space-in-header-bloat and
spec-bloat. When we talk about CSP bloat in this case, I believe we're
generally talking about the later. That kind of bloat makes it difficult to
update the spec, iterate, etc.

On Tue, Dec 22, 2015 at 6: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.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>