Re: [TLS] Confirmation of Consensus on Removing Compression from TLS 1.3

[Eric Rescorla <[e-mail]>]

On Wed, Mar 26, 2014 at 4:56 PM, Martin Rex <[e-mail]> wrote:

> Joseph Salowey (jsalowey) wrote:
> >
> > The use of compression within TLS has resulted in vulnerabilities
> > that can be exploited to disclose TLS encrypted application data.
> > The consensus in the room at IETF-89 was to remove compression from
> > TLS 1.3 to remove this attack vector.  If you have concerns about
> > this decision please respond on the TLS list by April 11, 2014.
>
> This characterization about the use of compression in TLS is
> sufficiently misleading that it is wrong.
>
> First of all, the problem is nowhere specific to TLS, and affects
> compression anywhere within the software protocol stack.
>
> Besides, compression only aggravates the problem when either the entropy
> of all data within a TLS record is so extremely low, that the TLS record
> size difference will make the difference.
>
> As I previously noted on this list, the way it is specified, the TLS
> compression function could be used to provide a random padding of TLS
> records, so that all TLS records come out in equal size, essentially
> a form of anti-compression.  And that could be applied to all existing
> cipher suites, including Stream ciphers and AEAD -- both of which
> do not allow any padding at all so far and therefor leak much more
> about the protected traffic than cipher suites that use the
> GenericBlockCipher PDU.
>
>
> The only situation where compression in general at the TLS-level
> aggravate the problem in any meaningful fashion is when either one
> or both of the endpoints do extraordinarily stupid things, like
> multiplexing attacker-supplied data with data that the attacker is not
> supposed to know into the same compression function (i.e. protect it
> with the very same TLS connection state rather than through seperate
> TLS connection states (i.e. with independent traffic protection keys),
> which is a clear an obvious fallacy, in clear abuse of the TLS protocol:
>

Hmm... SSL/TLS was originally designed to protect Web traffic and this
design of mixing attacker-supplied and sensitive information is a basic
part of the Web, so I'm not sure I would really call it an "abuse" of TLS.

In any case, it's a fairly common modality, so it seems like we need
to provide TLS modes that are secure under this use case. This isn't
to say that *all* TLS modes necessarily need to be so (though obviously
it would be simpler that way) but if we don't supply a version of TLS
that is safe for the Web, I don't think we've done our job.

-Ekr