W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

RE: Making Implicit C-E work.

From: <K.Morgan@iaea.org>
Date: Wed, 14 May 2014 20:31:27 +0000
To: <jgraettinger@chromium.org>
CC: <matthew@kerwin.net.au>, <grmocg@gmail.com>, <ietf-http-wg@w3.org>, <C.Brunhuber@iaea.org>
Message-ID: <0356EBBE092D394F9291DA01E8D28EC20112D9D640@sem002pd.sg.iaea.org>
On 14 May 2014 17:52, jgraettinger@google.com wrote:
> On 14 May 2014, Keith Morgan wrote:
>> Nearly all of the problems brought up w.r.t. t-e gzip are also true for C-E
>> gzip. This one is no exception.
>> Implicit C-E gzip adds a large DoS attack surface to intermediaries.
>> An attacker simply sends requests without ‘accept-encoding: gzip’ from a HTTP/1.1.
>> origin through a 1.1<->2 gateway for a resource it knows the server will
>> implicitly C-E gzip. Then (using your own words Johnny) “the gateway is required
>> to decompress before handing off to the origin … and face the ensuing DoS attack
>> surface.”
>
>
> This is a problem which already exists today. As Roberto noted, existing h1
> intermediaries add a-e: identity on behalf of clients who didn't ask for it, and
> existing servers send c-e: gzip anyway, because the observed impact of not
> compressing is higher than the interop issues it introduces.
>
>
> The DOS mitigation which is available today, and continues to be available for
> h2/h1 gateways under implicit c-e: gzip, is to pass through what the server sent
> without decompression. There's a high likelihood the h1 client will be able to
> handle c-e: gzip  (and even prefers it), which is definitely not true if t-e: gzip
> were used instead.


The current -12 spec says "Intermediaries that perform translation from HTTP/2 to
HTTP/1.1 MUST decompress payloads unless the request includes an Accept-Encoding
value that includes 'gzip'." [1].

So implicit gzip either introduces a legitimate DoS at the HTTP/2 to HTTP/1.1 gateway
or you want gateways to ignore this requirement and introduce interop issues. Which
is it?

If it's the latter (forward compressed regardless of the A-E header), then what's the
point of Roberto's "uncompressed-*" headers for the gateways if you don't really want
the gateways to deccompress? And what's the point of this "MUST decompress payloads"
requirement?

If it's the former (decompress at the gateway), and you want to live with the DoS
attack surface, I have to ask again, what's the point of all this - just to have
compression on one or two h2 hops and then force gateways to dynamically decompress??


[1] http://http2.github.io/http2-spec/#Compression
This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.
Received on Wednesday, 14 May 2014 20:32:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC