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

On Wed, Feb 10, 2016 at 7:47 AM Frederik Braun <fbraun@mozilla.com> wrote:

> On 09.02.2016 19:35, Craig Francis wrote:
> > I'm forgetting the discussion a bit, but CSP already gives us:
> >
> > block-all-mixed-content
> > upgrade-insecure-requests
> >
> > Maybe we could keep it as just one directive:
> >
> > block-non-sri-resources
> >
> > Or am I missing the more advanced cases like saying SRI is required for
> > all JavaScript files, but not on CSS (doubt that is useful, as you might
> > as well do both)... or maybe in the future SRI could be added to images,
> > video, etc?
>
> We'd need to think about compatibility assuming SRI will expand to other
> tags.
>
> I would be surprised if nobody wanted a report-mode and a block-mode and
> a way to specify which subresources/elements should be subject to the
> policy. (The list of elements could be abbreviated with a short-hand
> form, e.g., "sri-v1" meaning scripts & styles.)
>
> I guess this level of complexity (and Mark Nottingham's comment about
> HPACK and entropy) warrants its own header?
>
>
I'm curious where the line should be drawn between extending CSP and adding
a new header? Not having been involved with CSP from day one, maybe this
has already been discussed. But, I feel like CSP is a natural place to
centralize on browser based security policies (like x-frame-options
migrating to frame-ancestors). Adding a new header for each and every new
good idea for browser security doesn't seem to scale. As has been mentioned
in this thread prior, it feels like we are starting to bump up against
practical size consideration issues. Whether the CSP header itself grows
too large or we end up adding 50 headers to each HTTP response, there is an
issue of bloat. It would be a shame to place some artificial cap on good
ideas based on concerns for adding too many new headers and/or stretching
the size of the CSP header. I personally feel like moving toward a
centralized policy/manifest/resource sounds like the best way to handle
this, but I think most of that discussion is best had over in the "header
size and policy delivery" thread. I just wanted to bring it up here since I
think the "where do we put it" discussion should be deferred until later,
since it seems like this is a general concern for almost anything new that
is proposed.