Header size and policy delivery

Creating a new tread for discussion of a solution to header bloat size if
at all possible.

Also relevant is:
https://lists.w3.org/Archives/Public/public-webappsec/2015Mar/0148.html

Taken out from the discussion in: [CSP] "sri" source expression to enforce
SRI

On Tue, Jan 5, 2016 at 1:59 AM Nottingham, Mark <mnotting@akamai.com> wrote:

> 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 Tue, Jan 5, 2016 at 11:29 AM 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
>
>
On Tue, Jan 5, 2016 at 11:52 AM Jonathan Kingston <jonathan@jooped.co.uk>
wrote:

> 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.
>
>
Kind regards
Jonathan