Re: ezflate: proposal to reinstitute deflate header compression

Hi,

On Tue, Jun 03, 2014 at 07:48:50AM +0000, K.Morgan@iaea.org wrote:
> Hi Willy,
> 
> On 02 June 2014 21:45, w@1wt.eu wrote:
> 
> > On Mon, Jun 02, 2014 at 07:23:05PM +0000, K.Morgan@iaea.org wrote:
> >> + Interoperability is easy; any inflate library (e.g. zlib) will decompress ezflate streams
> >
> > Which makes me fear that it's as prone to DoS attacks as gzip (eg: send
> > 1 Mbps of headers which are decompressed as 1 Gbps or headers), and as
> > slow (a 40 Gbps capable server will basically scale down to less than
> > 1 Gbps due to the cost of the compression).
> >
> 
> No matter the header scheme, plain-text, hpack, ezflate ... you shouldn't be
> accepting 1 Gb of headers.

Huh ? 1 Gbps of headers is not much, it's only 125000 requests per second
with 1kB of headers each. A number of products achieve this in plain text
right now with HTTP/1.1. We must certainly not slow down HTTP/2 to the
point where it cannot upgrade existing servers, proxies, load balancers,
etc.

> The h2 spec may not limit the size of headers,
> but any good implmentation will.

I'm not speaking about the size but the parsing speed and emission
speed.

> > Don't forget that CRIME is not the only weakness of gzip here, it was
> > the absolute showstopper, but the other issues remain :-/
> >
> 
> What other issues?  Please elaborate.

The ones I mentionned above :-)

In short :
  - attack amplification (up to 1000 times the bandwidth with gzip/deflate)
  - processing cost on the send side for servers and intermediaries.

I appreciate that gzip/deflate is a good general purpose compressor which was
well suited for the last 30 years to compress various data and particularly
file archives, but it comes with a heavy weight to compress small strings,
and we cannot blame it for that, it was clearly not its primary purpose when
it was designed. Hpack may or may not have some issues (I have not implemented
it yet so I would not pronounce myself on it), but at least it has the merit
of having been designed for the exact purpose it will be used for. My only
concern with it is how we could disable it when its gains are not considered
worth its costs, or when an issue is faced later and we need to disable it.

Willy

Received on Tuesday, 3 June 2014 08:19:13 UTC