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

Re: Making Implicit C-E work.

From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 14 May 2014 14:58:23 -0700
Message-ID: <CABkgnnX6qpmawuGdAAf01grdD4b+9yAAXbkbQjUtRJyoNjk5cA@mail.gmail.com>
To: Johnny Graettinger <jgraettinger@chromium.org>
Cc: Roberto Peon <grmocg@gmail.com>, C.Brunhuber@iaea.org, HTTP Working Group <ietf-http-wg@w3.org>, Matthew Kerwin <matthew@kerwin.net.au>, K.Morgan@iaea.org
What Johnny said. I also note the possibility of just dropping things on
the floor, which is the ultimate end state in successful DoS attacks.

I'd be concerned if the commitment were unbounded in some way (other than
time, which is manageable), but I haven't seen any claim to that effect.
On May 14, 2014 2:43 PM, "Johnny Graettinger" <jgraettinger@chromium.org>

> > 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?
> An intermediary MUST decompress payloads, as the specification says.
> In the extreme hypothetical case of an intermediary which has lots of
> clients which don't send a-e: gzip, and which is facing DoS at current load
> levels, then passing through c-e: gzip is a non-conformant but effective
> DoS mitigation which is *in-practice* unlikely to break the majority of
> h1 clients. Yes, this breaks spec, but if decompression DoS is an actual
> concern (and with a nod to Martin's point here), it's a reasonable escape
> valve.
Received on Wednesday, 14 May 2014 21:58:51 UTC

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