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

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/
>
>
>