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

From: takamichi saito <[email-masked]>
Date: Fri, 2 Oct 2015 22:08:12 +0900

> 
> Do we know how many protocols currently suffer from CRIME?
> 
> 
> Maybe a best practice could be suggested by UTA for the implementation of TLS in software, to disable compression if vulnerable.  And for the others, to implement a way to enable/disable compression in case one day a vulnerability is found.

I agree.

Again,

1) We know CRIME threat, but it can not be risk for everyone.
e.g., CVSS v2 Base Score: 2.6 (LOW)

2) If we need to have comp/decomp in an application layer, 
 clients such like browser need their own comp/decomp codes.

3) If there is no comp in tls1.3, some people may continue to use tls1.2. 
Which one is safer, "tls1.2" v.s. "tls1.3 with comp/decomp" ?

That's why we explore the way to keep compression in TLSv1.3.
How about making an option only in server-side?
The spec has the compression but default is off, and also provides the suggestion.

> 
> -- 
> Julien ÉLIE
> 
> « La vraie valeur d'un homme se mesure lorsqu'il a tout perdu. »
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

;; takamixhi saito
c2xhYWlidHNvcw

---

From: Roland Zink <[email-masked]>
Date: Fri, 2 Oct 2015 15:59:04 +0200

Browsers are not a concern as they already have their own comp/decomp 
codes. HTTP/1 can compress content (Content-encoding and 
transfer-encoding) and HTTP2 has additional header compression.

Regards,
Roland

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 2 Oct 2015 15:24:10 +0000

> e.g., CVSS v2 Base Score: 2.6 (LOW)

CVSS isn't always appropriate; CVSS2 called Heartbleed a 5; CVS v3 called it 7.5

> Which one is safer, "tls1.2" v.s. "tls1.3 with comp/decomp" ?

They are equivalent.  If you use AES-GCM and ECDHE, and you don't need 0RTT, then there is no compelling reason to use TLS 1.3.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 2 Oct 2015 08:42:47 -0700

On Fri, Oct 2, 2015 at 8:24 AM, Salz, Rich <[email-masked]> wrote:

> They are equivalent.  If you use AES-GCM and ECDHE, and you don't need
> 0RTT, then there is no compelling reason to use TLS 1.3.

I don't want to take a position on what's compelling or not, but there are
a number of
other reasons to use TLS 1.3, including support for real padding, encrypted
content types,
privacy for client authentication, etc.

-Ekr

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 02 Oct 2015 11:46:16 -0400

> They are equivalent.  If you use AES-GCM and ECDHE, and you don't need 0RTT, then there is no compelling reason to use TLS 1.3.

...and you use session-hash, and you either don't do renegotiation or
require secure renegotiation, and you don't use TLS-Unique, and you're
ok with fully-cleartext handshakes, and (maybe something(s) else i'm
forgetting) ...

I don't think we should be claiming that TLS 1.2 is equivalent to TLS
1.3 without many more caveats.   :)

          --dkg

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 2 Oct 2015 15:50:21 +0000

> 1.3 without many more caveats.   :)

Fair enough.

---

From: [email-masked] (Martin Rex)
Date: Fri, 2 Oct 2015 18:24:24 +0200 (CEST)

Eric Rescorla wrote:
> a number of other reasons to use TLS 1.3, including support for
>   real padding,
>   encrypted content types

privacy for client authentication is the only real benefit on this list of 3.

The value of real padding is highly dependent of whether and how it
will actually get used, and is far from automatic.
Btw. retrofitting real padding as "compression alg" into TLSv1.0-TLSv1.2
would be trivial, and work fine with TLSv1.2 AEAD.

encrypted content types looks like lame duck with zero value to me.

"Is not readily distinguishable by existing deep packet inspection (DPI)
filter types" is pretty much the only thing--and adjusting DPI will be
far from rocket science.

Trying to make a single bit of information stick out less prominently
will only create a false sense of security whenever that bit of information
can be trivially detected from the traffic pattern.

But the collateral damage is that you break stuff that feeds on the
outer record layer structure and state, which can easily push adoption
of TLSv1.3 from the 5-years-spec-to-usage for TLSv1.2 to the
15-years-spec-to-marginal-use marginal use seen with IPv6.

-Martin

---

From: Yoav Nir <[email-masked]>
Date: Fri, 2 Oct 2015 22:43:55 +0300

> On Oct 2, 2015, at 6:42 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Fri, Oct 2, 2015 at 8:24 AM, Salz, Rich <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I don't want to take a position on what's compelling or not, but there are a number of
> other reasons to use TLS 1.3, including support for real padding, encrypted content types,

And client certificate authentication in HTTP/2

(This assumes that HTTP/2 is required)

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 03 Oct 2015 12:02:38 -0400

> will actually get used, and is far from automatic.

Sure, but we have no existing mechanism to do that in TLS 1.2 or
earlier.  We need the mechanism before anyone can establish sensible
policy.  Understanding what policy is sensible is likely to be
endpoint-specific, and is definitely something that needs research.  But
we can't implement any policy at all without having the mechanism in
place.

> would be trivial, and work fine with TLSv1.2 AEAD.

"would be trivial" is not "has been specified".  It also requires
negotiation, whereas hopefully in 1.3, we will not need to negotiate
padding.  Furthermore, If you treat padding as a "compression alg" in
1.2, then the folks who started this thread who want 1.2 because of its
support for compression would not be able to use padding in conjunction
with compression (if someone has a use case for such a combination,
which seems counterintuitive at first glance).  So this proposal doesn't
really address the original reason for the suggestion of "stay on 1.2".

> filter types" is pretty much the only thing--and adjusting DPI will be

I beg to differ -- if there is any interleaving of application_data and
other content types, and if records can be arbitrarily-sized, it's not
clear to me how a DPI can distinguish one from the other.  Can you be
more specific?

> can be trivially detected from the traffic pattern.

We need to be looking at things the other way around: if there's a
sensible way to leak less metadata, we should be leaking less metadata,
even if there are other ways that the same information can be recovered
by a similar adversary.  "don't fix X because Y has the same problem" is
a great symmetric recipe for not getting anything done.  We should be
saying "we need to fix both X and Y" instead.

> 15-years-spec-to-marginal-use marginal use seen with IPv6.

Can you enumerate the stuff you expect to break from encrypted content
type that will cause a decade-long delay in adoption?  It would be great
to have a list of those things so we can evaluate them.

   --dkg

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 3 Oct 2015 20:55:13 +0300

> to have a list of those things so we can evaluate them.

I personally would expect that anything that would be broken by content
type encryption is already broken by fixing the handshake (it has number
of known flaws).

That version number field that has absolutely no use in encrypted records
is still there... For compatiblity.

Also, new user protocols (like TLS) are much much easier to deploy than
new addressing protocols (like IPv6).

And the stuff that breaks... Probably some badly done "middleware" in
"enterprise" environment.

-Ilari

---

From: takamichi saito <[email-masked]>
Date: Sun, 4 Oct 2015 07:36:22 +0900

On 2015/10/02, at 22:59, Roland Zink wrote:

> Browsers are not a concern as they already have their own comp/decomp codes. HTTP/1 can compress content (Content-encoding and transfer-encoding) and HTTP2 has additional header compression.
> 
> Regards,
> Roland
> 

I see,
but contrary,
tls is only for browser?

And more,
if you kick out comp/decomp from tls,
can we be safer when we use tls?
If you know the paper, please teach me.

Or, rfc or good teacher should notify us,
"When you use TLSv1.3, you never use compression, sorry!"
I know it may be out scope,
but we have to estimate the risk.

regards,

;; takamixhi saito

---

From: takamichi saito <[email-masked]>
Date: Sun, 4 Oct 2015 07:44:21 +0900

> CVSS isn't always appropriate; CVSS2 called Heartbleed a 5; CVS v3 called it 7.5

We know it, but one of indicators.
How can you say the dangerous or risk instead of it? 
My point is, CRIME is risk for every case? even when we have option  in tls1.3, in case that default is off. 

> They are equivalent.  If you use AES-GCM and ECDHE, and you don't need 0RTT, then there is no compelling reason to use TLS 1.3.

If so, some people can skip tls1.3.

;; takamixhi saito

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 3 Oct 2015 15:55:47 -0700

On Sat, Oct 3, 2015 at 3:36 PM, takamichi saito <[email-masked]>
wrote:

> codes. HTTP/1 can compress content (Content-encoding and transfer-encoding)
> and HTTP2 has additional header compression.
> >
> > Regards,
> > Roland
> >
>
> I see,
> but contrary,
> tls is only for browser?
>
> And more,

That is what the document says:
"Versions of TLS before 1.3 supported compression and the list of
compression methods was supplied in this field. For any TLS 1.3
ClientHello, this field MUST contain only the “null” compression method
with the code point of 0. If a TLS 1.3 ClientHello is received with any
other value in this field, the server MUST generate a fatal
“illegal_parameter” alert. Note that TLS 1.3 servers may receive TLS 1.2 or
prior ClientHellos which contain other compression methods and MUST follow
the procedures for the appropriate prior version of TLS."

-Ekr

> >>> Maybe a best practice could be suggested by UTA for the implementation
> of TLS in software, to disable compression if vulnerable.  And for the
> others, to implement a way to enable/disable compression in case one day a
> vulnerability is found.
> >> I agree.
> >>
> >> Again,
> >>

---

From: Yoav Nir <[email-masked]>
Date: Sun, 4 Oct 2015 02:54:26 +0300

> On Oct 4, 2015, at 1:44 AM, takamichi saito <[email-masked]> wrote:
> 
> 
> My point is, CRIME is risk for every case?  

I don’t know. Probably not. 

But consider that we had been using HTTP with TLS for over 15 years before we found out about CRIME. It’s a subtle attack that relies on specific structures in HTTP and the peculiar way that browsers allow a script from one site to issue requests on behalf of another site. But still, it took researches all these years to find it. 

There are many lessons to be learned from this: that a bearer token that is repeated many times is not a good idea; that the trust model in the web is not great; but also that blindly compressing content with no regard to its structure and sources is dangerous and reveals information about the cleartext.  A security protocol should not do that. 

An even more executive-level lesson might be that security layers should not provide non-security services, but that is not really convincing because if there was a separate compression layer that you could compose with the security layer in TLS, CRIME would still be possible. To compress HTTP without the danger of CRIME you need to either not compress header fields with sensitive information, not compress header fields that might be controlled by an attacker, or at least delegate those to a separate compression state. That is not something that any transport layer shim can provide.

Yoav

---

From: Tony Arcieri <[email-masked]>
Date: Sun, 4 Oct 2015 10:49:53 -0700

On Sat, Oct 3, 2015 at 4:54 PM, Yoav Nir <[email-masked]> wrote:

> An even more executive-level lesson might be that security layers should
> not provide non-security services, but that is not really convincing
> because if there was a separate compression layer that you could compose
> with the security layer in TLS, CRIME would still be possible. To compress
> HTTP without the danger of CRIME you need to either not compress header
> fields with sensitive information, not compress header fields that might be
> controlled by an attacker, or at least delegate those to a separate
> compression state.

The attack you're describing (or one fairly close to it) already happened,
and it's called BREACH. It impacts HTTP compression, and allows attackers
to recover things like CSRF tokens in page bodies.

The takeaway for me is you can't mix compression, any fixed value an
attacker wishes to learn, and attacker-controlled data, or there will be a
compression side-channel.

-- 
Tony Arcieri

---

From: Jeffrey Walton <[email-masked]>
Date: Sun, 4 Oct 2015 13:58:09 -0400

>> not provide non-security services, but that is not really convincing because
>> if there was a separate compression layer that you could compose with the
>> security layer in TLS, CRIME would still be possible. To compress HTTP
>> without the danger of CRIME you need to either not compress header fields
>> with sensitive information, not compress header fields that might be
> and it's called BREACH. It impacts HTTP compression, and allows attackers to
> recover things like CSRF tokens in page bodies.
>

Is that necessarily true?

Deflate violates semantic security by allowing the attacker to gain
information across messages (even though any single message is
secure). So perhaps its the mode of compression ot the way compression
was implemented, and not compression itself.

Jeff

---

From: Tony Arcieri <[email-masked]>
Date: Sun, 4 Oct 2015 11:09:49 -0700

> was implemented, and not compression itself.

The only property of compression that this class of side-channel attack
relies on is that the compression algorithm produces a smaller output for
message a || a than a || b (where a and b are of identical length), so
really it would seem to be a conceptual problem with mixing compression and
encryption.

If someone has produced a secure system for "compression side-channel
resistant encryption", I haven't seen it.

-- 
Tony Arcieri

---

From: Dave Garrett <[email-masked]>
Date: Sun, 4 Oct 2015 14:32:35 -0400

> Is that necessarily true?

It should be apparent by now that the dominant opinion is that compression in TLS is not worth the risk and not worth the time to attempt to deal with here. Whether or not a generic compression algorithm could theoretically be made safe is irrelevant at this point. It's a known-dangerous attack surface that we don't want the risk of.

Dave

---

From: Jeffrey Walton <[email-masked]>
Date: Sun, 4 Oct 2015 14:48:19 -0400

> It should be apparent by now that the dominant opinion is that compression in TLS is not worth the risk and not worth the time to attempt to deal with here. Whether or not a generic compression alg…

If I am reading things correctly: the group has effectively
encountered a security problem, deemed it to be too hard for them, and
then pushed it into another layer where folks are even less equipped
to deal with it. Is that correct?

I might be missing something, but I don't believe the "problems
created by compression" have gone away. Rather, they have been moved
around so the risk remains. The underlying problem still exists
because the group responsible for providing those security services
have not addressed them.

Jeff

---

From: Dave Garrett <[email-masked]>
Date: Sun, 4 Oct 2015 14:50:24 -0400

> resistant encryption", I haven't seen it.

I can think of a way to do this, but the people who want compression badly probably won't like it due to the need to pad heavily.

1) Pick a fixed bandwidth
2) Compress & encrypt the stream
3) Send the compressed stream at a rate blocked to the cap
4) Whenever below the cap, pad the stream to the cap

Maintain a fixed transmission of data per unit time and there's no way to tell the size of anything (even if delivery doesn't match the rate). However, this relies on being able to pick a usable fixed bandwidth (in each direction). The bandwidth cap size and length of transmission times still gives quite a bit of info, e.g. 1GB vs 1KB total is quite telling, but that's true without compression.

With a good compression algorithm, the above could probably produce an overall more efficient stream rather easily for many things. If your idea of compression is to keep using DEFLATE forever, however, you should probably just reevaluate what you're doing.

Dave

---

From: Dave Garrett <[email-masked]>
Date: Sun, 4 Oct 2015 14:55:23 -0400

> because the group responsible for providing those security services

TLS & SPDY + HTTP compression was broken due to CRIME. The fix was to disable it, and then HTTP/2 introduced HPACK to compress headers safely. Yes, the security issue has been moved around, but to a place that can actually fix it properly. There is nothing TLS could do to implement a fix like HPACK here. I don't claim this is the only way to fix this problem, but it is a straightforward one and the one that is being done.

Dave

---

From: Tony Arcieri <[email-masked]>
Date: Sun, 4 Oct 2015 12:00:33 -0700

On Sun, Oct 4, 2015 at 11:50 AM, Dave Garrett <[email-masked]>
wrote:

> I can think of a way to do this, but the people who want compression badly
> probably won't like it due to the need to pad heavily.
>
> Maintain a fixed transmission of data per unit time and there's no way to
> tell the size of anything (even if delivery doesn't match the rate).

This sounds like Constant Bitrate (CBR) compression, which works for
encrypted media (e.g. encrypted voice and video), but probably isn't
particularly useful outside the realm of realtime media. It was a solution
that seems to work for attacks that could e.g. transcribe encrypted phone
calls by studying patterns in Variable Bitrate (VBR) compression on speech.

Typically compression is used to lower the overall size of data, working on
a wide class of inputs. In the perceptual coding case the class of inputs
is constrained, and the goal is to keep the data rate constant, not
optimally small.

-- 
Tony Arcieri

---

From: Dave Garrett <[email-masked]>
Date: Sun, 4 Oct 2015 15:27:04 -0400

> is constrained, and the goal is to keep the data rate constant, not

Yep. You could do this in bursts with different caps each time to get it to work with bursty things like HTTP & other general data transfer protocols. Without a really good modern compression algorithm, though, it isn't that appealing. Once these caveats and tweaks start getting added to the simple concept, it starts treading into the territory that is better handled by the application protocol that actually *knows what it's sending*. This seems to be the logical wall we keep hitting, which is why TLS doesn't seem like the place to do this.

Maybe some new transport protocol could be fed information to tell it how to handle compression safely, but TLS is not a transport protocol nor a young one that can be fundamentally changed to accommodate everything.

Dave

---

From: Jeffrey Walton <[email-masked]>
Date: Sun, 4 Oct 2015 16:01:14 -0400

> Yep. You could do this in bursts with different caps each time to get it to work with bursty things like HTTP & other general data transfer protocols. Without a really good modern compression algor…
I think two concepts are blending into one.... You appear to be
arguing for efficiency, and I'm more concerned with safely/securely.

I'm fairly certain the internet community at large would benefit from
"compression done safely/securely", even if its not the most
efficient. If the application layer wants to provide a more efficient
implementations, then that's fine too.

I think this I where things now stand (if I am surveying correctly):
(1) TLS WG did not fix the problem (bad); (2) users don't have a
choice (bad); (3) applications will have to provide their own
compression when desired, which will likely increase overall risk for
users (bad). For (3) keep in mind browsers are not the only user
agents or consumers of web services.

All-in-all, I think its a win for NSA, GCHQ and other miscreants; and
an overall loss for user.

Jeff

---

From: Watson Ladd <[email-masked]>
Date: Sun, 4 Oct 2015 16:10:48 -0400

> an overall loss for user.

As we've tried to explain to you, TLS is a channel encryption
abstraction, and does not know which parts of the stream of bytes it
is being asked to send are controlled by who. Absent this information,
there is no way to know what can be compressed how. By contrast
applications know this information, and can design the compression
scheme accordingly. How does this increase risk over TLS providing an
inappropriate scheme which isn't secure?

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Tony Arcieri <[email-masked]>
Date: Sun, 4 Oct 2015 13:16:08 -0700

On Sun, Oct 4, 2015 at 1:01 PM, Jeffrey Walton <[email-masked]> wrote:

> > Yep. You could do this in bursts with different caps each time to get it
> to work with bursty things like HTTP & other general data transfer
> protocols. Without a really good modern compression algorithm, though, it
> isn't that appealing. Once these caveats and tweaks start getting added to
> the simple concept, it starts treading into the territory that is better
> handled by the application protocol that actually *knows what it's
> sending*. This seems to be the logical wall we keep hitting, which is why
> TLS doesn't seem like the place to do this.
> >

No, you're just not following the conversation or understanding the
concepts.

> implementations, then that's fine too.

Doing compression safely/securely is an application-specific problem.

Using constant bitrate perceptual coding allows us to compress audio/video
streams in such a way that there is no compression side-channel, because
the data rate is kept constant per unit time.

If we were to try to use TLS compression instead, not only would it fail to
compress as well, but it would have a compression side-channel an attacker
could use to potentially recover a transcript of an encrypted conversation
(such attacks against against VBR audio compression).

TLS is the wrong layer at which to solve the problem of compression.

-- 
Tony Arcieri

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 4 Oct 2015 13:17:35 -0700

> agents or consumers of web services.

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.

-Ekr

[0] Specifically, that the attacker can confirm specific guesses about the
contents
of a header field.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 5 Oct 2015 01:28:01 +0000

> There are many lessons to be learned from this: that a bearer token that is
> repeated many times is not a good idea; that the trust model in the web is
> not great; but also that blindly compressing content with no regard to its
> structure and sources is dangerous and reveals information about the
> cleartext.  A security protocol should not do that.

This is a great note, and excellent explanation.

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Jeffrey Walton <[email-masked]>
Date: Sun, 4 Oct 2015 22:19:16 -0400

> This is a great note, and excellent explanation.

I'm not sure about some of it (I'm not trying to be argumentative).

If compression leaks information from a structured message, then
surely an uncompressed message leaks the same information. As Kurt
eloquently put it, only the density of the information changed.
Naively, that means the encryption services are defective, and not
compression.

Or maybe I should back pedal and ask: when is it safe to use TLS with
a structured message? Is it safe to use with HTTP? How about SMTP? If
HTTP always sends the cookie in the same position in unique messages,
then wouldn't that mean its not safe to use with HTTP over TLS?

Perhaps I'm missing something obvious....

Jeff

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 4 Oct 2015 19:26:11 -0700

On Sun, Oct 4, 2015 at 7:19 PM, Jeffrey Walton <[email-masked]> wrote:

> surely an uncompressed message leaks the same information.

No, not when they are encrypted.

Consider the trivial case of ASCII text. Each character takes up the
same amount of room, but if you compress (as an intuition pump,
think of a simple Huffman code), then more common characters
take up less room than less common characters.

For a more complicated case, see:
http://www.cs.unc.edu/~fabian/papers/foniks-oak11.pdf

-Ekr

> As Kurt

---

From: Martin Thomson <[email-masked]>
Date: Sun, 4 Oct 2015 21:01:18 -0700

> take up less room than less common characters.

This is right, but it's also not the case that revealing information
like that is necessarily bad.  Perhaps it isn't that interesting to an
adversary that they can learn that there is (for example) English text
being exchanged.  That wouldn't be particularly relevant in helping
them distinguish between ciphertext that contains interesting text
from ciphertext containing uninteresting text.

HPACK for instance compresses base64-encoded data unevenly.  But the
study that was run in 2013 determined that it wasn't especially
interesting. [32] shows ~2 bits regained from a 30 character word.  Of
course, you should examine the conditions on that claim; such a result
is not generally applicable.  Mixing attacker-controlled data with
secrets has shown to make protecting those secrets extremely
difficult.

[32] http://pdl.cmu.edu/PDL-FTP/associated/CMU-PDL-13-106.pdf

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 4 Oct 2015 21:06:11 -0700

On Sun, Oct 4, 2015 at 9:01 PM, Martin Thomson <[email-masked]>
wrote:

> like that is necessarily bad.

I didn't say it was. But it's also leaking information that the encryption
didn't, which is intended as a simple counterexample to Jeffrey's claim.

> secrets has shown to make protecting those secrets extremely

Yes, if the attacker can provide their own data, it makes matters worse,
but as the reference I provided indicated, there are potential security
issues even if the attacker is not able to do so, provided that the data
is sufficiently redundant.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Sun, 4 Oct 2015 21:11:59 -0700

> is sufficiently redundant.

Sometimes, it's OK.  Sometimes, not.  Agreed.

---

From: Douglas Stebila <[email-masked]>
Date: Tue, 6 Oct 2015 05:26:49 +0000

On Oct 5, 2015, at 5:17 AM, Eric Rescorla <[email-masked]> wrote:
> If you have a solution to this problem, then great. But the mere fact that it's

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

---

From: [email-masked] (Martin Rex)
Date: Wed, 7 Oct 2015 21:51:57 +0200 (CEST)

Eric Rescorla wrote:
> ClientHello, this field MUST contain only the ?null? compression method
> ?illegal_parameter? alert. Note that TLS 1.3 servers may receive TLS 1.2 or

The quoted wording calls for a fatal handshake failure when ClientHello
offers

  TLSv1.2+compression  _or_  TLSv1.3

while at the same time the last requirement asserts that a ClientHello with

  TLSv1.2+compression

is perfectly OK.  To me, this looks quite odd.

If you want compression removed from TLSv1.3, how about something like this:

 "Versions of TLS before 1.3 supported compression and the list of
 compression methods was supplied in this field.
                                                  All TLS protocol
 versions require the "null" compression method MUST be included/present
 in the compression_methods list of ClientHello.  A TLSv1.3 server that
 is offered and selects/negotiates protocol version TLSv1.3, MUST select
 the "null" compression method, and MUST ignore all other compression
 methods that might appear in the compression_methods list of ClientHello.

Btw. for the last requirement, I would appreciate an additional recommendation
for a configuration option to disable compression, maybe something like

 This document does not impose restrictions on the use of compression
 with TLS protocol versions prior to TLSv1.3.  However, it is RECOMMENDED
 that implementations which support compression provide a configuration
 option allowing consumers to disable the use of compression in TLS.

-Martin

---

From: Dave Garrett <[email-masked]>
Date: Wed, 7 Oct 2015 16:01:30 -0400

On Wednesday, October 07, 2015 03:51:57 pm Martin Rex wrote:
>  However, it is RECOMMENDED

Risky features like compression should be off by default.

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 7 Oct 2015 22:43:12 +0200

> is perfectly OK.  To me, this looks quite odd.

That's not how I read this text.

Rather, I read it as:
If ClientHelloVersion >= TLS 1.3
   then the compression field must be empty
else:
   the compression field is dictated by other versions

This doesn't seem inconsistent to me. If you still think that the paragraph
reads differently, can you help me by diagramming it?

---

From: [email-masked] (Martin Rex)
Date: Wed, 7 Oct 2015 23:11:55 +0200 (CEST)

Eric Rescorla wrote:
> Martin Rex <[email-masked]> wrote:
>> Eric Rescorla wrote:
>>>
>>> ?illegal_parameter? alert. Note that TLS 1.3 servers may receive TLS 1.2
>>> or prior ClientHellos which contain other compression methods and MUST
>>> follow the procedures for the appropriate prior version of TLS."
>>

What you describe would be considerable worse that what I understood,
because it would mean that a TLSv1.3 ClientHello will be unconditionally
invalid for a TLSv1.2 server.

   https://tools.ietf.org/html/rfc5246#page-42

   compression_methods
      This is a list of the compression methods supported by the client,
      sorted by client preference.  If the session_id field is not empty
      (implying a session resumption request), it MUST include the

Dierks & Rescorla           Standards Track                    [Page 41]
 
RFC 5246                          TLS                        August 2008

*>    compression_method from that session.  This vector MUST contain,
*>    and all implementations MUST support, CompressionMethod.null.
      Thus, a client and server will always be able to agree on a
      compression method.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 7 Oct 2015 23:15:00 +0200

>       Thus, a client and server will always be able to agree on a

Sorry, I spoke carelessly. It must contain solely the null method.

-Ekr

---

From: "Short, Todd" <[email-masked]>
Date: Wed, 7 Oct 2015 21:28:29 +0000

However, for those ClientHello’s that support older versions, the compression_method field may contain other values. This means that if a TLSv1.3 client happened to support compression for TLSv1.2, it would be unable to negotiate that via a single ClientHello. There’s no way to attempt to negotiate TLSv1.2+compression and TLSv1.3+no-compression in a single ClientHello.

In effect, the document is stating that a TLSv1.3 client MUST NOT support compression, regardless of the protocol version that may be negotiated.

--
-Todd Short
// [email-masked]<mailto:[email-masked]>
// "One if by land, two if by sea, three if by the Internet."

On Oct 7, 2015, at 5:15 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Oct 7, 2015 at 11:11 PM, Martin Rex <[email-masked]<mailto:[email-masked]>> wrote:
Eric Rescorla wrote:
> Martin Rex <[email-masked]<mailto:[email-masked]>> wrote:
>> Eric Rescorla wrote:
>>>

   https://tools.ietf.org/html/rfc5246#page-42<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5246-23page-2D42&d=BQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=IxUTnzF6SN6y6C4zTXXfgQmiV1FojXWtLZ0S8hS5eGY&s=Uu3NPBs1t52N_fGVGPqXazTAStG7cPUeCfNh6eCTtkk&e=>

   compression_methods

RFC 5246                          TLS                        August 2008

-Ekr

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

---

From: Geoffrey Keating <[email-masked]>
Date: 07 Oct 2015 17:56:25 -0700

"Short, Todd" <[email-masked]> writes:

> In effect, the document is stating that a TLSv1.3 client MUST NOT
> support compression, regardless of the protocol version that may be
> negotiated.

I believe that is the intent, yes.

I support both the current wording in draft 09 (no compression for
clients or servers, reject ClientHellos that allow compression and TLS
1.3) and the intent as described above.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 8 Oct 2015 06:43:40 +0200

On Wed, Oct 7, 2015 at 11:28 PM, Short, Todd <[email-masked]> wrote:

> However, for those ClientHello’s that support older versions, the
> compression_method field may contain other values. This means that if a
> TLSv1.3 client happened to support compression for TLSv1.2, it would be
> unable to negotiate that via a single ClientHello. There’s no way to
> attempt to negotiate TLSv1.2+compression and TLSv1.3+no-compression in a
> single ClientHello.
>
> In effect, the document is stating that a TLSv1.3 client MUST NOT support
> compression, regardless of the protocol version that may be negotiated.
>

Yes, this is what I believe it says and what I believe the WG had consensus
on, the reasoning being that we really wished to just remove the feature
entirely. If the chairs declare consensus on something else, I will of
course edit
it to say something else.

-Ekr

--
> // [email-masked]
> On Oct 7, 2015, at 5:15 PM, Eric Rescorla <[email-masked]> wrote:
>
>
>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5246-23page-2D42&d=BQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=IxUTnzF6SN6y6C4zTXXfgQmiV1FojXWtLZ0S8hS5eGY&s=Uu3NPBs1t52N_fGVGPqXazTAStG7cPUeCfNh6eCTtkk&e=>
>>
>>    compression_methods

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 7 Oct 2015 21:53:14 -0700

> it to say something else.

I think it would be prudent for the chairs to give some sort of judgment on
this issue, given the high volumes of mailing list traffic created by a
small number of detractors despite what is otherwise a rough consensus

-- 
Tony Arcieri

---

From: Jeffrey Walton <[email-masked]>
Date: Thu, 8 Oct 2015 12:56:03 -0400

> small number of detractors despite what is otherwise a rough consensus

That's kind of a loaded request.

We would need to know the security goals and objectives to ensure
things are progressing as expected. As far as I know, they are not
stated anywhere.

For example, if a goal is to ensure TLS is trouble free and does not
get egg on its face, then the goal is met by removing compression
altogether. If the goal is to ensure TLS users are safe, then the
result will likely fail to meet expectation because there will be
1,000's of incorrect, 1-off solutions.

The failed goal assumes not everyone RTFM's, which I think is
reasonable given past history. I can't help but feel if RTFM was going
to work, it would have happened in the last 30 or 50 years or so.

Jeff

---

From: Watson Ladd <[email-masked]>
Date: Thu, 8 Oct 2015 14:53:43 -0400

> things are progressing as expected. As far as I know, they are not

Not true: secure channel abstractions are well understood.
> 1,000's of incorrect, 1-off solutions.

No generic solution will solve the problem. Knowledge of what applications
do is required for secure compression. Do you have a proposal that
addresses the problems we've duscussed? And please, stop using words like
"safe" and "users" and start using words like "universal composability" and
"adversarial model" if you actually want to think through these issuses.

> to work, it would have happened in the last 30 or 50 years or so.

Are you denying that the TLS compression option lead to attacks?

---

From: Jeffrey Walton <[email-masked]>
Date: Thu, 8 Oct 2015 15:24:02 -0400

> Not true: secure channel abstractions are well understood.

Oh, please forgive my ignorance. What are the IETF's security goals
and objectives? Are they listed somewhere? Can you provide a link to a
document?

Jeff

---

From: [email-masked] (Martin Rex)
Date: Thu, 8 Oct 2015 23:22:55 +0200 (CEST)

Eric Rescorla wrote:
> Short, Todd <[email-masked]> wrote:
>> 
>> However, for those ClientHello?s that support older versions, the
>> unable to negotiate that via a single ClientHello. There?s no way to

Yup, that is the problem with the current text.

> course edit it to say something else.

The current text is trying to force a specific policy in a fashion
that is in the worst conceivable violation of rfc2119 section 6 that
is possible.

A ClientHello with

    ClientHello.client_version = (3,3)
    ClientHello.compression_methods = (1,0)

will be interoperable with TLSv1.0, TLSv1.1, TLSv1.2 and TLSv1.3 servers.

    ClientHello.client_version = (3,4)
    ClientHello.compression_methods = (1,0)

will be interoperable with TLSv1.0, TLSv1.1 and TLSv1.2 servers,
but TLSv1.3 servers that follow the stupid idea will choke and
abort with an "illegal_parameter" alert.

Essentially, the current wording is calling for a newly creating what
must be called a "compression method intolerance" -- but essentially
it is indistinguishable from a "TLS version intolerance"

For a number of years, it seemed to have been consensus in the IETF TLS WG
that TLS version intolerance is an implemenattion defect and a real problem.  
It would be sad if the current TLS WG would confirm that recklessly adding
handshake failure causing new intolerances into TLSv1.3 is the new
engeneering approach.

-Martin

---

From: Tony Arcieri <[email-masked]>
Date: Thu, 8 Oct 2015 14:36:33 -0700

> things are progressing as expected. As far as I know, they are not

Jeff,

It's a request against you. You are "spamming" this list.

TLS is a security protocol, not a compression protocol.

Providing secure compression requires application-specific domain
knowledge. TLS cannot provide secure compression.

A security protocol shouldn't provide insecure compression.

TLS can only provide insecure compression, because it lacks the
application-specific domain knowledge to implement security correctly.

TLS is a security protocol.

You are asking TLS, a security protocol, to provide an insecure feature it
is conceptually incapable of providing securely.

Please stop. That is why I asked the chairs to make a ruling and end the
"spam" to the list. This is not a useful discussion.

Your argument is conceptually flawed beyond repair and you are literally
asking for insecure features to be added to a security protocol. This needs
to stop.

Please stop.

-- 
Tony Arcieri

---

From: "Short, Todd" <[email-masked]>
Date: Thu, 8 Oct 2015 21:53:14 +0000

Eric specifically clarified it:

-Ekr

So the text needs to be corrected to reflect that. This will avoid the backward compatibility issues.

IMHO, the text should also clearly state something along the lines that “A TLSv1.3 client MUST NOT support compression, regardless of the protocol version that may be negotiated.” This reinforces backwards-compatibility via the use of CipherMethod.null, makes it blatantly obvious that compression is not supported, and a TLSv1.3 client is a good citizen in avoiding CRIME-type attacks.

On Oct 8, 2015, at 5:22 PM, Martin Rex <[email-masked]<mailto:[email-masked]>> wrote:

Eric Rescorla wrote:
Short, Todd <[email-masked]<mailto:[email-masked]>> wrote:

A ClientHello with

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 9 Oct 2015 03:42:05 +0200

> Yup, that is the problem with the current text.

Thanks for clarifying this.

> support

Hmm... I'm not sure I follow this argument. We have a bunch of rules for
how TLS 1.3 clients MUST behave and TLS 1.3 servers will choke if
they don't. This doesn't create any present interop problem and only
creates a problem if in future we wish to reintroduce compression.
Is that your concern?

> handshake failure causing new intolerances into TLSv1.3 is the new

As I said, I edited the document in conformance with what I believed the
chair declaration of WG consensus was. If the WG consensus is to remove
this requirement, then I will of course do so. So, rather than going back
and
forth, I would suggest that the best way for you to proceed here is to:

1. Ask the chairs to re-state the previous consensus. If I misunderstood,
then that's
easy.
2. If you're still not happy, then you could ask the chairs to re-assess
the currnet
consensus.
3. If you're still not happy, and you believe this violates 2119, then you
can of
course appeal.

This of course also goes for people who think we should re-allow
compression.

Best,
-Ekr

---

From: Joseph Salowey <[email-masked]>
Date: Fri, 9 Oct 2015 10:20:43 -0700

The chairs have read through this thread and do not see any new information
that would cause the working group to reconsider the decision to remove
compression from TLS 1.3.   Discussions about clarifying the language and
intent of the document are OK.

Thanks,

J&S

---

From: [email-masked] (Martin Rex)
Date: Fri, 9 Oct 2015 22:14:05 +0200 (CEST)

Joseph Salowey wrote:
> compression from TLS 1.3.

I am (and I was) perfectly fine with removing compression from TLSv1.3.
(btw. our own implementation never implemented TLS compression).

>
> Discussions about clarifying the language and

But in the previous discussion only Todd Short seems to understand, why I am
objecting to one specific requirement in the current plan to achieve
removal of compression from TLSv1.3.

>>>     ClientHello.compression_methods = (DEFLATE(1),null(0))
>>>
>>>     ClientHello.compression_methods = (DEFLATE(1),null(0))
>>>

The issue is about the TLSv1.3 server response for the second case above.

If we want to have compression removed from TLSv1.3, then my suggested
wording would be sufficient, and provide proper and robust negotiation
of TLS protocol options:

                                                   All TLS protocol

The (current) text, which Eric quoted, on the other hand:

                                                    For any TLS 1.3
  ClientHello, this field MUST contain only the ?null? compression method
  with the code point of 0. If a TLS 1.3 ClientHello is received with any
  other value in this field, the server MUST generate a fatal
  'illegal_parameter' alert.

would require a TLSv1.3 server to unconditionally abort the TLS handshake
rather than to negotiate the "null" compression and continue the handshake.

The original intent of the ClientHello & ServerHello handshake messages
is negotiation of TLS protocol parameters, and choking&aborting rather
than performing selection&negotiation of the desired protocol options
is what we see in the installed base in form of "TLS version intolerance"
and "TLS extensions intolerance", and what caused browser implementors
to come up with an insecure&dangerous scheme known as "downgrade dance",
which was demonstrated to be a bad idea, because it is what made POODLE
possible in the first place.

The proposed "choke on everything but compression_method = (0)" rather
than "you MUST select the null compression method for TLSv1.3" is
particularly weird due to the statement that follows the current text:

                              Note that TLS 1.3 servers may receive TLS 1.2
  or prior ClientHellos which contain other compression methods and MUST
  follow the procedures for the appropriate prior version of TLS.

-Martin

---

From: Watson Ladd <[email-masked]>
Date: Fri, 9 Oct 2015 16:15:44 -0400

> rather than to negotiate the "null" compression and continue the handshake.

Why is it important that clients be permitted to signal support for
compression and TLS 1.3 conditionally? Remember, we also want to phase
out the use of compression in TLS 1.2.

---

From: [email-masked] (Martin Rex)
Date: Sat, 10 Oct 2015 00:18:06 +0200 (CEST)

> out the use of compression in TLS 1.2.

compression in TLS is *NOT* generally bad, and not generally a problem.

It may be a problem for usage scenarios where attacker-supplied content
and unknown content are mixed prior to compression, and in particular
where an attacker is freely given elaborate control over the behaviour
of one of the endpoints (e.g. SSL-VPNs and Web-Browsers), but there
are many more, perfectly valid usage scenarios, where TLS compression
is in current use, such as copying huge sparse files over a
TLS-protected communication channel.

-Martin

---

From: Dave Garrett <[email-masked]>
Date: Fri, 9 Oct 2015 18:40:15 -0400

> TLS-protected communication channel.

The better solution is to not do that and actually used compressed file formats optimized for their content types. That will work better than TLS compression or even application layer compression.

Dave