Re: [TLS] TLS 1.3 - Support for compression to be removed

[Eric Rescorla <[e-mail]>]

On Sun, Oct 4, 2015 at 9:01 PM, Martin Thomson <[e-mail]>
wrote:

> On 4 October 2015 at 19:26, Eric Rescorla <[e-mail]> wrote:
> > Consider the trivial case of ASCII text. Each character takes up the
> > same amount of room, but if you compress (as an intuition pump,
> > think of a simple Huffman code), then more common characters
> > take up less room than less common characters.
>
> This is right, but it's also not the case that revealing information
> like that is necessarily bad.


I didn't say it was. But it's also leaking information that the encryption
didn't, which is intended as a simple counterexample to Jeffrey's claim.


HPACK for instance compresses base64-encoded data unevenly.  But the
> study that was run in 2013 determined that it wasn't especially
> interesting. [32] shows ~2 bits regained from a 30 character word.  Of
> course, you should examine the conditions on that claim; such a result
> is not generally applicable.  Mixing attacker-controlled data with
> secrets has shown to make protecting those secrets extremely
> difficult.
>

Yes, if the attacker can provide their own data, it makes matters worse,
but as the reference I provided indicated, there are potential security
issues even if the attacker is not able to do so, provided that the data
is sufficiently redundant.

-Ekr