Re: padding and compression

I'm not sure how folks will want to use padding for compression yet.
Padding will never prevent loss of information, but it can increase the
amount of effort required to get that information.

In other words, padding can transform the benefit equation from 1 bit per
request to 1/1000 bit per request.

One might achieve this by ensuring that a HEADERS frame always has a length
which is a multiple of 25, for instance.
For fields 100% must absolutely leak no information (i.e. surviving a year
of 10Mbit/second isn't good enough), then thing to do is always to turn off
both huffman encoding and state for that element.
Huffman encoding alone is likely to be fairly safe much of the time with
some small amount of padding, and especially after we change the huffman
table to have no one code that has a unique length.

Anyway, security is a big and long discussion in and of itself. The
guidance here should probably be to follow recommendations set by a
different group and spec entirely :)
-=R



On Mon, Feb 24, 2014 at 11:39 AM, Martin Thomson
<martin.thomson@gmail.com>wrote:

> 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.
>
>