Re: padding and compression

I'd rather see user agent fingerprinting than have padding used poorly,
especially given that other behaviors (e.g. flow control) are likely to
allow for that per browser anyway, unfortunately :/

It is close to impossible to have every implementation use something like
padding the same way (even if just based upon the timing of how a browser
parses and lays out the DOM), and actively a bad idea if it is used in a
wrong fashion.

-=R
On Feb 24, 2014 1:48 PM, "Martin Nilsson" <nilsson@opera.com> wrote:

>  On Mon, 24 Feb 2014 20:53:38 +0100, Roberto Peon <grmocg@gmail.com>
> wrote:
>
> 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
>
>
> If padding strategy isn't coordinated though, it becomes a means for
> fingerprinting implementations.
>
> /Martin Nilssons
>
>
>
>
>
> 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.
>>
>>
>
>
>
> --
> Using Opera's revolutionary email client: http://www.opera.com/mail/
>