Re: Dictionary Compression for HTTP (at Facebook)

On Mon, Sep 3, 2018 at 4:56 AM Kenji Baheux <kenjibaheux@chromium.org>
wrote:

> Is the assumption that Servers / Server operators, unless vertically
> integrated (e.g. FB and other big players), will probably get it wrong
> because they lack the application knowledge to dissociate public vs.
> private sources?
>
> One option that was discussed in a side chat at IETF 101 was to expose
> this to JS (Fetch / Streams / ...) where the knowledge about public vs.
> private exists. But that implies a different, and most likely harder,
> adoption story.
>
> The scale benefits of Servers / Server Operator is definitely appealing.
> So, I'm wondering if we have exhausted all the reasonable options. Is there
> nothing that would at least cover a significant subset of the use cases?
>
> Some naive questions / thoughts:
>
>    - Would it still be valuable to enable shared dictionary compression
>    by Servers for responses that are completely free of private data?
>
> To expand on that, when I was thinking about attack scenarios and
mitigations for HTTP compression dictionaries
<https://tools.ietf.org/html/draft-vkrasnov-h2-compression-dictionaries-03#section-4.1>,
one possible mitigation was for browsers to only allow it for responses for
non-credentialed requests, as well as limiting compression context sharing
to same-origin.

Any thoughts on the effectiveness of that as a mitigation?

>
>    -
>    - Can a Server / Server operator infer that response isn't tainted by
>    private sources, i.e. only contains "public" data? From the absence of
>    specific (existing) headers?
>    - If not, what if Servers had to assume "mixed" unless the response
>    was augmented with a new(?) header. I imagine that a server configuration
>    scheme / header would be simpler in terms of adoption than requiring web
>    developers to do all the work in JS land.
>
>
>
>
> On Sun, Sep 2, 2018 at 4:57 AM Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
>
>>
>>
>> On Sat, Sep 1, 2018 at 1:23 AM Jyrki Alakuijala <jyrki@google.com
>> <jyrki@google..com>> wrote:
>>
>>> On Fri, Aug 31, 2018 at 4:58 PM, Ryan Sleevi <ryan-ietf@sleevi.com>
>>> wrote:
>>>>
>>>> Of course, this is all after the security concerns are mitigated ;)
>>>>
>>>
>>> We involved Thai Duong in the security analysis and we have a limited
>>> scope solution that allows much of the benefits without these security
>>> concerns. One main mitigation there is to never compress data mixed from
>>> public and private sources.
>>>
>>
>> Yes. That’s been well understood and well discussed as the bare minimum -
>> but that requires servers understanding what constitutes public and private
>> sources, or the interaction between data that may need to remain private
>> through timing leaks.
>>
>> I don’t think it’s fair to say without the security concerns - there’s a
>> considerably high bar to demonstrate that, both in theory and in practice.
>> A compression scheme that requires serves dramatically rework their serving
>> infrastructure in order to tag such is, generally speaking, an insecure
>> solution. The adoption of a given method is highly correlated to its lack
>> of footguns, and tagged annotations of public v private are a giant footgun
>> for server operators and not worth the risk to users, or the implicit trust
>> that servers and server operators can and will get it right.
>>
>>>