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

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 26 Mar 2014 18:42:51 +0000

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.

Thanks,

Joe
[Speaking for the TLS chairs]

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 26 Mar 2014 21:40:45 +0200

I think this would be a mistake. I would recommend instead to say that 
compression SHOULD be disabled by default. But leave the option in the 
protocol for applications that need compression and are able to mitigate 
the vulnerability. This does NOT include normal Web traffic.

The reason is that we have compression at the HTTP layer too, it is 
widely used, and is subject to similar vulnerabilities when run over 
TLS. AFAIK, no-one is proposing to ban HTTP compression [1]. So we're 
just moving the problem to a different protocol layer, one that may be 
less security conscious.

And in general, an encrypted transport should provide compression as one 
of its services. Architecturally this is the right level, which is why 
it was put there in the first place.

Thanks,
	Yaron

[1] http://http2.github.io/http2-spec/index.html#rfc.section.10.6

On 03/26/2014 08:42 PM, Joseph Salowey (jsalowey) wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 26 Mar 2014 12:57:14 -0700

On 26 March 2014 12:40, Yaron Sheffer <[email-masked]> wrote:
> The reason is that we have compression at the HTTP layer too, it is widely
> used, and is subject to similar vulnerabilities when run over TLS. AFAIK,
> no-one is proposing to ban HTTP compression [1]. So we're just moving the
> problem to a different protocol layer, one that may be less security
> conscious.

I think that this is perhaps the wrong interpretation.  I wouldn't
want to assume that TLS has a monopoly on communications security.
HTTPbis is acutely aware of the risks that compression comes with.

Compression is critical to the performance of HTTP/2.  HTTP/2 has
mandated support for compression, despite the risks, because the
performance gains are considered worth pursuing anyway.

The general trend I've observed in these discussions is to move the
decision to compress closer to the application.  This means that the
decision can be informed better by context.  Generically applied
compression is necessarily less aware of constraints on its use.

For that reason, I support the decision here.  Application protocols
will be more aware of hazards.  TLS will be easier to build without
this baggage.

---

From: [email-masked] (Martin Rex)
Date: Wed, 26 Mar 2014 21:56:18 +0100 (CET)

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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 26 Mar 2014 17:10:38 -0400

> 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

---

From: "Paterson, Kenny" <[email-masked]>
Date: Wed, 26 Mar 2014 21:19:37 +0000

Comments inline 

> On 26 Mar 2014, at 20:56, "Martin Rex" <[email-masked]> wrote:
> 

Really? I assume you know about CRIME??

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

> size difference will make the difference.

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

> 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

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

>   properties TLS does and does not provide and cannot safely rely on

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

> 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

---

From: [email-masked] (Martin Rex)
Date: Wed, 26 Mar 2014 23:02:00 +0100 (CET)

> Really? I assume you know about CRIME??

Yes, I do.  Similar to BEAST, it is *NOT* an attack.
It is a pretty boring demonstration of the principle of operation
of querying an encryption oracle (BEAST) or compression oracle (CRIME).

None of the alleged "fixes" against BEAST and CRIME addresses the
real vulnerability.  Even with compression disabled and TLSv1.1+ or
AEAD cipher suites, the vulnerability is WIDE OPEN.  The attackers
code could, rather than performing a demonstration of a boring
principle, submit any attacker-desired nefarious request to the
server, the Browser will blissfully insert the authentication-credentials
into that nefarious request, and the server will blissfully execute
the request.  No matter what fancy stuff the TLS WG puts into TLSv1.3,
the attack will continue to work as long as the browser keeps doing
the stupid stuff: volutarily and blissfully inserting authentication
credentials into requests that the browser performs on the attackers
behalf.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 26 Mar 2014 18:14:25 -0400

> On Mar 26, 2014, at 18:02, [email-masked] (Martin Rex) wrote:
> 
> Paterson, Kenny wrote:
>> 
> the request.  

This is more an http issue than a tls issue but we pretty much have to go with the Web we have which includes (restricted) cross origin requests subject to the same origin policy.

EKR

> No matter what fancy stuff the TLS WG puts into TLSv1.3,

---

From: Watson Ladd <[email-masked]>
Date: Wed, 26 Mar 2014 18:21:47 -0400

> credentials into requests that the browser performs on the attackers

This is called a CSRF, and has been known for a long time. The
solution is to use capability-like URLs, with unguessable content.

BEAST goes further: it exposes to the adversary credentials, rather
than letting the adversary use some of them through controllable
means. Sometimes you need to take advantage of this browser behavior:
OAuth I believe relies on being able to make cross-site requests with
the user credentials, as does single-sign-on.

Furthermore, BEAST also affects VPNs built on TLS, where you don't
have an option but to pass possibly adversarially influenced traffic.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: [email-masked] (Martin Rex)
Date: Thu, 27 Mar 2014 01:04:31 +0100 (CET)

Eric Rescorla wrote:
> 
> This is more an http issue than a tls issue but we pretty much have
> to go with the Web we have which includes (restricted) cross origin
> requests subject to the same origin policy.

Eric, in principle I'm with you.  The TLS WG needs to take into account
real world usage scenarios or it will cease to be a useful technology.

But we are having a real problem that folks a looking at TLS to be
"magic pixie dust", and the perception that any apps or protocol design,
no matter what design flaws it has, will automatically become secure
by adding TLS to it.

I don't see a solution for the disclosing authentication (=passwords)
at the human<->machine interface, not even on the horizon.

But the disclosing authentication on pure machine<->machine interfaces
(including "SSL Cookies") provides ample opportunity for new security
problems, and I'm seeing that TLS channel encryption is (ab)used to
excuse the continued use of disclosing authentication on what is
pure machine<->machine interfaces, and that train is heading in
the wrong direction.

-Martin

---

From: Joachim Strömbergson <[email-masked]>
Date: Thu, 27 Mar 2014 09:30:45 +0100

Aloha!

> compression is necessarily less aware of constraints on its use.

Yes, good point. And imho compression is not something you add to get
security. It might alleviate overhead caused by a secure tunneling
mechanism. But it is not really a required feature. Separation of duty.

If one really want compression, use one of the available compression
protocols and tunnel the result through TLS for the security. Or better
yet, as Martin says, put it as close to the application layer as possible.

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
 Joachim Strömbergson          Secworks AB          [email-masked]
========================================================================

---

From: Alyssa Rowan <[email-masked]>
Date: Thu, 27 Mar 2014 12:37:29 +0000

On 26 March 2014 18:42:51 GMT+00:00, "Joseph Salowey (jsalowey)" <[email-masked]> wrote:
>The consensus in the room at IETF-89 was to remove compression from TLS 1.3
>to remove this attack vector.

+1 Remove compression.

Compression is usually best performed as "high" as possible; transport layer is blind to what's being compressed, which is (as we now know) was definitely too low and was in retrospect a mistake.

Any application layer protocol needs to know - if compression is supported - to separate compression contexts for attacker-chosen plaintext and attacker-sought unknown secrets. (As others have stated, HTTPbis covers this.)

Any encrypted (or unencrypted) protocol could potentially have a size oracle where compression dictionaries were mixed in that case. That's an issue for the security of the underlying protocol, although I think we should draw strong attention to it and remind implementers that we cannot protect from that (and make no attempt to protect from size oracles in TLS in general).

- --
/akr

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Fri, 28 Mar 2014 07:48:59 +0100

> Compression is usually best performed as "high" as possible; transport layer is blind to what's being compressed, which is (as we now know) was definitely too low and was in retrospect a mistake.

I agree.

In particular, note that TLS 1.2 compression is performed on a per-fragment basis, and hence it leaks even more fine-grained information about the plaintext than if the compression were performed for the whole stream in the application. 

For example, we implemented a traffic-analayzer for fingerprinting equal-length files over TLS-with-compression [1]. Each file resulted in about 150 fragments, and our goal was to identify the file by its compressed length.
With TLS compression, we could fingerprint the file within the first three fragments.With application-level compression we would have needed to calculate the length of the whole stream.

1: http://www.mitls.org/downloads/miTLS-report.pdf, Section 4.1

---

From: Richard Hartmann <[email-masked]>
Date: Sun, 30 Mar 2014 00:11:12 +0100

+1 for removal.

Richard

Sent by mobile; excuse my brevity.