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

Re: padding and compression

From: Cory Benfield <cory@lukasa.co.uk>
Date: Mon, 24 Feb 2014 08:48:05 +0000
Message-ID: <CAH_hAJG_gZ_+7PCzRAcSG66YCrhNKULhsD2gXhnVfHHUAGqbEQ@mail.gmail.com>
To: Kazu Yamamoto <kazu@iij.ad.jp>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 24 February 2014 02:53, Kazu Yamamoto <kazu@iij.ad.jp> wrote:
> So, the compression ratio is offset by the padding. Do I understand
> correctly? Or am I missing something?

My understanding is that you pad any HEADERS or CONTINUATION frame out
to some implementation-defined size, preventing an attacker from
telling how large the compressed header block actually is. For
instance, if I chose 100 bytes, I would take any compressed header
block and split it into 100 byte chunks, and then pad the last frame
out to 100 bytes.

Of course, the padding is more flexible than that allowing you to do
other things with it. For instance, you could add padding of random
size [0, 16kB) to each frame if you wanted to, ensuring that frames
vary in size and making it very difficult to determine what exactly is
going on.

Or, if you want implementation simplicity, you can simply not pad at
all. AFAIK the spec only currently mandates that you can _receive_
padded frames: it makes no requirement of you that you _send_ padded
frames.
Received on Monday, 24 February 2014 08:48:32 UTC

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