SRI: Fine grained "require integrity" option

[devd]

A simple use case that I can't figure out how to implement with the current spec is: "require integrity for all script loads"

I am beginning to think that instead of a new "integrity-policy" directive, we should just have new keywords for the existing CSP directives like script-src. OR some other way to declare integrity requirements for each type of sub-resource.

I am just creating a placeholder issue for now. I am traveling and don't have the time/connectivity required to start and participate in a thread on public-webappsec.

[devd]

I am bubbling this back up for comments from @fmarier @metromoxie @mozfreddyb . If I were to implement this at Dropbox, it is extremely unlikely that I would implement require-for-all for all styles; only for scripts more likely.

And, thinking about this further , require-for-all seems brittle. Lets say next we add support for object tags. Then, someone who had support for links and scripts suddenly finds that the object tag stops working because browsers upgraded. And this will be a recurring pain for every type of resource.

[mozfreddyb]

We had a "integrity policy" section that I ripped out for v1, but yes your comment holds true against it:

We'll have to enumerate attributes, I guess – like in CSP?

[fmarier]

Should set this to the newly created V2 milestone?

[mozfreddyb]

I created a milestone called SRI-next (so we don't have discuss if it should be 1.1 or 2 ;))

[devd]

I am fine with moving it out to SRI-next, but in that case, should we remove require-for-all from v1 (because of the compat concerns I bought up above)? The only CSP policy for SRIv1 can be block or report.

[mozfreddyb]

(for the record, #201 removed the require-for-all)

[joelweinberger]

For the record, this seems reasonable to me. It seems like there's a lot of nuance to figure out still, so I'd rather not hoist an imperfect directive on users.

[dveditz]

There's basically two ways this could fit into CSP: A. add a keyword to existing -src directives: script-src 'self' https://othersite.com 'require-integrity'; B. add a new directive, with a bunch of optional resource types:

[dveditz]

B continued: integrity (integrity-required?) 'script' 'style'; Of the two options I prefer A, adding a keyword to existing directives. (don't care about the keyword name, could be 'integrity', 'integrity-required', 'require-integrity' or maybe someone can come up with a better option).

[jonathanKingston]

Does having just 'always on'/'potentially on' states capture the use case here?

Having the ability to enable SRI just on JavaScript CDN URLs to me seems most useful to not break other scripts.

However I perhaps might want to force nonces on all other scripts.

Something like sri-require-exempt-src however that would move away from restrictive only directives but only based on the restrictive directive you mention.

On Fri, 23 Oct 2015 19:16 Daniel Veditz notifications@github.com wrote:

B continued: integrity (integrity-required?) 'script' 'style'; Of the two options I prefer A, adding a keyword to existing directives. (don't care about the keyword name, could be 'integrity', 'integrity-required', 'require-integrity' or maybe someone can come up with a better option).

— Reply to this email directly or view it on GitHub https://github.com/w3c/webappsec/issues/16#issuecomment-150652679.

[devd]

If we version the CSP header, we could just do sri- as a new source expression and then include that in the script-src? something like script-src sri-sha256-abcdef.. ?