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

["Paterson, Kenny" <[e-mail]>]

Comments inline 

> On 26 Mar 2014, at 20:56, "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.

Really? I assume you know about CRIME??

> 
> First of all, the problem is nowhere specific to TLS, and affects
> compression anywhere within the software protocol stack.

This much is true. But we can at least remove the problem at one layer, where it's particularly easy to exploit. 

> 
> 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.

But sometimes an attacker can arrange exactly this to be the case - as in CRIME. 

> 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.  

What would you choose for that size? The max fragment size could end up being very wasteful in many application scenarios; the MAC overhead would be unacceptable in other use cases if the size was small. 

> 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. 

CRIME can also be applied to CBC mode cipher suites, with some care. 

> 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.
> 
> 

Again, the CRIME case is instructive. Merely having malicious JavaScript that can connect to a remote https site can lead to cookies being recovered. There, you can't stop attacker supplied data (http GET requests) being interleaved with sensitive data (secure cookies). I don't think i would characterise this as being "extraordinarily stupid". 

> 
> 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.

I believe that random amounts of padding plus compression can still be broken by CRIME-like attacks, using only slightly more sophisticated statistical methods. 

Cheers

Kenny

> 
> 
> -Martin
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>