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

[Douglas Stebila <[e-mail]>]

On Oct 5, 2015, at 5:17 AM, Eric Rescorla <[e-mail]> wrote:
> 
> The problem is that we don't know how to generically provide compression
> safely. To take a concrete example: HTTP2's solution to header compression,
> HPACK, is extremely limited compared to a generic compression system
> like gzip, LZ77, etc., as well as being tightly-coupled to HTTP, and yet we
> still know that there are potential security problems [0]. Doing something
> generically secure is much harder.
> 
> If you have a solution to this problem, then great. But the mere fact that it's
> desirable doesn't mean we have an answer.

A very very limited answer is that, if you use a compression method with a fixed, small dictionary and non-adaptive compression (i.e., the dictionary is not updated), then recovery of a high entropy secret from a compressed-then-encrypted value is hard, even with an adversary adaptively choosing the prefix/suffix of the plaintext.  This is a much weaker security property than the standard indistinguishability / semantic security of encryption, and would be unsuitable for general encryption purposes.  Being a non-adaptive technique, the compression rate is also quite poor, but can be better than nothing for a dictionary that's chosen well for the typical document.

Douglas