W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

RE: Choosing a header compression algorithm

From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
Date: Tue, 26 Mar 2013 09:11:44 +0000
To: Roberto Peon <grmocg@gmail.com>, "agl@google.com" <agl@google.com>
CC: Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-ID: <6C71876BDCCD01488E70A2399529D5E5163F4263@ADELE.crf.canon.fr>

Prefix matching can be disabled by using the "delta=false" option.

There are two new strategies for prefix matching. The first one is limiting which shared prefixes are used. The last character of a shared prefix must belong to a predefined set of characters. An example of predefined set of characters is "/?=, " (with a space as the last character). For example, for the following URLs:
With the default strategy for prefix matching, the shared prefix would be:
With the constraints upon the end of the shared prefix, the shared prefix is:
This prevents CRIME-like attacks from guessing a value character by character. Therefore we think that using this new strategy, prefix matching is not vulnerable to CRIME-like attacks. In fact, using this strategy, we are enabling some kind of fine-grained indexing of values, where well defined parts of a value can be referred to.

The second strategy is to limit the number of times a given header value can be used as a reference for prefix matching. This limitation can be very low: limiting this usage as a reference to 2 times is already sufficient to get most of the performances of prefix matching. We think that with this strategy, prefix matching is mostly protected from CRIME-like attack.

The first strategy can be selected using the "delta_type='/?= \coma'" option (possibly changing the prefix ending characters).
The second strategy can be selected using the "delta_type=2" option (or with another value).

I'm planning update the HeaderDiff codec to using the first strategy by default.


From: Roberto Peon [mailto:grmocg@gmail.com] 
Sent: mardi 26 mars 2013 01:23
To: RUELLAN Herve; agl@google.com
Cc: Mark Nottingham; ietf-http-wg@w3.org Group
Subject: Re: Choosing a header compression algorithm


We need an option which disables prefix matching on the HeaderDiff compressor. The strategies I see in the code still allow many headers to be attacked (if they include commas).
I believe that it is still possible to probe interesting data out of various fields of the URL, for example, or even cookies, assuming they aren't B64 encoded.


On Mon, Mar 25, 2013 at 11:38 AM, Roberto Peon <grmocg@gmail.com> wrote:
There are two obvious strategies here: What we do now, and using what SPDY does today (share connections if the certs match and DNS resolution of the new hostname overlaps with those of the current connection).


On Mon, Mar 25, 2013 at 10:21 AM, RUELLAN Herve <Herve.Ruellan@crf.canon.fr> wrote:
> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net]
> Sent: lundi 25 mars 2013 06:56
> To: RUELLAN Herve
> Cc: Roberto Peon; ietf-http-wg@w3.org Group
> Subject: Re: Choosing a header compression algorithm
> On 23/03/2013, at 5:04 AM, RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
> wrote:
> > I think it would be good to move this from the compressors to the
> streamifier. In addition, it would be interesting to look at a more realistic
> streamifier that could for example unshard hosts (expecting that HTTP/2.0
> will remove the sharding currently done by server developers).
> Right now, it combines all requests to the same TLD (according to the Public
> Suffix List) into a single "connection." Do you have a suggestion for how to do
> it better?
I think this should provide some "realistic" results as a starting point. Depending on what we want to measure, we may want to refine this a bit.


> I've just pushed a quick and dirty fix to use a new instance of each
> compressor for each connection; the results are pretty even between
> headerdiff and delta2, with a small increase in each:
> * TOTAL: 5948 req messages
>                                        size  time | ratio min   max   std
>                         http1     3,460,925  0.18 | 1.00  1.00  1.00  0.00
>   delta2 (max_byte_size=4096)       707,901 11.87 | 0.20  0.03  0.83  0.15
>      headerdiff (buffer=4096)       960,106  1.65 | 0.28  0.01  0.96  0.23
> * TOTAL: 5948 res messages
>                                        size  time | ratio min   max   std
>                         http1     2,186,162  0.28 | 1.00  1.00  1.00  0.00
>   delta2 (max_byte_size=4096)       622,837 12.86 | 0.28  0.02  1.22  0.13
>      headerdiff (buffer=4096)       596,290  3.65 | 0.27  0.02  0.92  0.18
> Cheers,
> --
> Mark Nottingham   http://www.mnot.net/
Received on Tuesday, 26 March 2013 09:12:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:10 UTC