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

[[e-mail] (Martin Rex)]

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:


   http://tools.ietf.org/html/rfc5246#page-16

   Any protocol designed for use over TLS must be carefully designed to
   deal with all possible attacks against it.  As a practical matter,
   this means that the protocol designer must be aware of what security
   properties TLS does and does not provide and cannot safely rely on
   the latter.



Our implementation does not implement support for compression so far,
but if anyone wanted to have support for random padding in Stream and
AEAD ciphers within TLS (v1.0-v1.2) I would really prefer to see that
being done through an (anti-)compression scheme rather than changing
all of the 2/3 Encryption PDUs seperately.

For TLSv1.3, support for random (sized) padding could be added by
appropriate definition of the respective PDUs and their processing,
but that will reduce the code sharing further and further.

 
-Martin