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

> I care that we can continue to reason about our CSP implementations,
especially things like monotonicity of policy "strictness" in the most
general case.  I'm not sure that it's clear what that function is for SRI

Isn't the monotonicity of policy "strictness" simply SRI vs. no SRI? In
other words, by default, with no "sri-options" directive specified a script
can be sourced from any location that is allowed by "script-src" (for
example). But, the "script-src" directive makes no declaration about what
can be pulled from that that src. So, by setting the appropriate value on
the "sri-options" directive we are directly increasing the assurance of
what is fetched. And, since the directive doesn't even make sense unless
the resource is already allowed under script-src/etc, this would be an
"always increasing" policy of strictness. I agree that referrer is more
muddled in this regard, but I'm not quite sure I follow the comparison to
SRI. The above said, you all obviously have a deeper background on what
feels idiomatic for CSP.

On Wed, Dec 30, 2015 at 3:08 PM Brad Hill <hillbrad@gmail.com> wrote:

> Exactly.  I don't care where the bytes go, I care that we can continue to
> reason about our CSP implementations, especially things like monotonicity
> of policy "strictness" in the most general case.  I'm not sure that it's
> clear what that function is for SRI, just as it was not clear for referrer
> policy (which is why it's moving to another header).  I'm also not
> convinced that even if we could come up with a definition that makes SRI
> policy monotonic, it would be the right long term choice vs. a more rich
> and useful policy language that doesn't need to meet the same policy
> combination requirements as CSP.
>
> On Mon, Dec 28, 2015 at 11:17 AM Joel Weinberger <jww@chromium.org> wrote:
>
>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>