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

Re: padding and compression

From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 24 Feb 2014 11:39:42 -0800
Message-ID: <CABkgnnUnQOaOS16adDwBASk40OCuDCW+2aKE1KS2GkLc1RMO_w@mail.gmail.com>
To: Cory Benfield <cory@lukasa.co.uk>
Cc: Kazu Yamamoto <kazu@iij.ad.jp>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 24 February 2014 00:48, Cory Benfield <cory@lukasa.co.uk> wrote:
> 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.

Almost.  Padding is a sharp tool.

An attacker that controls part of the plaintext can still force you to
reveal information by counting the chunks.

However, here's an example that might* not leak information.  Say you
have a secret in a header field.  That secret is fixed size
originally, but consequently variably compressed (e.g., Huffman).  You
might want to allow for compression of the remaining fields, but then
pad to account for the specific effect of compression on that field.

* Never take my word for anything in this regard.  And who knows what
else you are leaking as a result.  For example, the conditionals you
execute in assembling this information result in different computation
times, providing an attacker with timing information that might reveal
something despite your best effort to avoid the leak.
Received on Monday, 24 February 2014 19:40:10 UTC

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