Re: comments about draft-ietf-httpbis-header-compression

The intent was to make a compressor that was difficult to get wrong from a
security perspective, whose implementation was reasonably easy for good
programmers, and which did good-enough compression.

Your statement about zlib being 'as safe' misses the mark. zlib has more
capabilities, which include things which are known to be unsafe. More
capabilities most usually means less safe. Adding bits in the manner you
suggested doesn't work-- it requires the attacker to do more requests to
determine if what it did was right and this is linear, not exponential.
Even if that wasn't true, you're adding bits (and a fair number of them),
which defeats the purpose of compression.

Non-static entropy coding also leads to non-exponential searches of the
input space if the attacker is allowed to influence the entropy coding.
That is why HPACK doesn't do non-static entropy coding. It uses a canonical
huffman format so that it would be possible to do "non static", though I
envisioned that this would only happen before request bits were sent, e.g.
in the ALPN token.

HPACK offers a means of not doing entropy coding, so if it gets out of
date, either the dictionary gets rev'd (e.g. at startup as described
above), or one chooses to not use it. This is described in section 5.2.

-=R

On Sat, Jan 3, 2015 at 9:25 AM, Mark Nottingham <mnot@mnot.net> wrote:

> See:
>   https://github.com/http2/compression-test
>
> This is what we used to help make the initial selection; I don’t believe
> that the compressor there has been updated to exactly match the spec; e.g.,
> it doesn’t do huffman (Herve?).
>
> Cheers,
>
>
> > On 1 Jan 2015, at 10:35 am, Jyrki Alakuijala <jyrki@google.com> wrote:
> >
> > If the goal is to just make an algorithm that can work with a static
> entropy code with a static dictionary and no LZ77 outside the static
> dictionary, the current format (deflate) needs no changes. Deflate supports
> all these concepts. You only need a new encoder -- although zlib with
> setting a dictionary and running it with quality == 1 is a pretty close
> match already, only the static entropy coding is missing then.
> >
> > Was HPACK ever benchmarked against using deflate in such configuration?
> Would you accept help in setting up such an experiment?
> >
> > Note, that with a static dictionary I mean that we would generate a
> single deflate dynamic dictionary from a header corpus and always encode
> all data with that -- I don't refer to the static Huffman mode in deflate.
> >
> >
> > On Wed, Dec 31, 2014 at 7:52 PM, Dave Garrett <davemgarrett@gmail.com>
> wrote:
> > The goal of HPACK was never to produce ideal compression, just competent
> > compression not vulnerable to known issues. Some people do want to
> attempt to
> > use/create a far more efficient codec here, but it's now accepted to be
> outside of
> > the initial scope. What could be very well received is an HTTP/2
> extension to
> > allow negotiation of alternate header compression methods. This would
> allow
> > actual experimentation in an effort to find the most ideal route(s).
> >
> >
> > Dave
> >
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
>