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

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 22 Sep 2015 13:23:13 +0000

Also, if compression is moved from TLS to upper layer(s) - how would it mitigate compression-related attacks? Besides "now it's somebody else's problem"?

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Simon Josefsson
Sent: Tuesday, September 22, 2015 04:07
To: Julien ÉLIE
Cc: [email-masked]
Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed

Julien ÉLIE <[email-masked]> writes:

> Hi Karthik,
>
>> It may well be true that some (typically unauthenticated) application
>> protocols on top of TLS can survive TLS compression, but it is
>> unlikely.
> [...]
>> HTTP is a particularly bad case because the attacker can potentially
>> inject arbitrary data before (and after) the secret. With NNTP you
>> may escape the worst of this adversary, but you probably won’t find
>> any TLS expert willing to say that compressing the password is ok.
>
> OK, many thanks for the illustration!
>
> So in fact, to be safer, authentication commands should either be sent
> uncompressed or be more complex than they currently are (for instance
> with the insertion of random data with random length along with the
> authentication command).

I believe the general recommendation is to not send passwords in
cleartext at all, even in encrypted tunnels. I'm sure you are aware of
it, but you may SASL in NNTP as described in RFC 4643.

/Simon

---

From: Watson Ladd <[email-masked]>
Date: Tue, 22 Sep 2015 10:13:12 -0400

> Also, if compression is moved from TLS to upper layer(s) - how would it mitigate compression-related attacks? Besides "now it's somebody else's problem"?

Exactly. Upper-level layers can do the analysis to indicate when
compression contexts can be shared. TLS cannot as it doesn't have
access to the relevant information.
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

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

---

From: Thijs van Dijk <[email-masked]>
Date: Tue, 22 Sep 2015 16:14:04 +0200

Hi all,

On 22 September 2015 at 15:23, Blumenthal, Uri - 0553 - MITLL <
[email-masked]> wrote:

> Also, if compression is moved from TLS to upper layer(s) - how would it
> mitigate compression-related attacks? Besides "now it's somebody else's
> problem"?
>

It allows the authors of the layers above to cherry-pick which parts of the
connection to compress, rather than potentially leaking sensitive
information through a "blanket compression" on the entire datastream.
For instance in the case of HTTP, using a Content-Transfer-Encoding leaks
no information on the headers, as only the response body is compressed.
Furthermore, one can choose to only apply compression to static resources
such as CSS files.

-Thijs

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 22 Sep 2015 09:23:16 -0700

> mitigate compression-related attacks? Besides "now it's somebody else's

This is the wrong way of looking at it. Keeping compression in TLS endorses
unsafe usage of a feature known to introduce compression sidechannels.

Whether other protocols decide to introduce their own secondary compression
layer is their own prerogative. But an unsafe feature shouldn't be kept in
TLS just because some protocols want to do unsafe things and are too lazy
to implement their own compression.

-- 
Tony Arcieri

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 22 Sep 2015 18:35:33 +0100

On 22/09/15 17:23, Tony Arcieri wrote:
> But an unsafe feature shouldn't be kept in

Compression does have issues clearly, but it's not correct to describe
people wanting TLS to compress as lazy. They're rather looking for the
same features that TLS has offered for a couple of decades. So if there
were a way to help them, that'd be good. And if not, the onus I think
is on us in this WG to clearly explain why we're removing that feature
in TLS1.3.

That doesn't have to be text in the TLS1.3 specification but I would
guess the question may keep coming up, so documenting the answer in
some archival form (such as an RFC:-) might be a good plan.

S.

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 22 Sep 2015 14:09:01 -0400

> some archival form (such as an RFC:-) might be a good plan.

I like this idea... and it doesn't have to be compression-specific but
could rather be of the variety of "Things that we [don't think make
sense/consider harmful/are best done] if done at the TLS layer."

This won't help get 1.3 out the door sooner, but it would be very
useful to understand important points of consensus in TLS WG that are
broader design decisions that may persist past 1.3.

best, Joe

-- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
[email-masked]
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: Julien ÉLIE <[email-masked]>
Date: Tue, 22 Sep 2015 20:16:47 +0200

Hi Tony,

> Keeping compression in TLS endorses unsafe usage of a feature known
> to introduce compression sidechannels.
>
> Whether other protocols decide to introduce their own secondary
> compression layer is their own prerogative. But an unsafe feature
> shouldn't be kept in TLS just because some protocols want to do unsafe
> things and are too lazy to implement their own compression.

What for protocols that aren't subject to unsafe usage and that were 
relying on the compression facility provided by TLS?
Unconditionally removing TLS compression leads to a regression for them.

As others already mentioned in this list, even with NNTP we can use a 
safe SASL mechanism to authenticate.  No password sent in plain-text.

Regarding vulnerable protocols, clients (and/or servers) could very well 
disable compression in TLS.  And either never use compression or 
implement their own compression, according to their needs.
It is what happened with BEAST:  Firefox and Chrome disabled TLS 
compression.

-- 
Julien ÉLIE

« Tant qu'il y a des marmites, il y a de l'espoir ! » (Astérix)

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 22 Sep 2015 11:21:24 -0700

> Unconditionally removing TLS compression leads to a regression for them.

They can continue using older versions of TLS, or add their own compression
feature. They shouldn't be relying on an encryption protocol to provide
compression.

-- 
Tony Arcieri

---

From: Dave Garrett <[email-masked]>
Date: Tue, 22 Sep 2015 14:23:37 -0400

> It is what happened with BEAST:  Firefox and Chrome disabled TLS 

No sane security protocol should allow any mode which is known to be insecure under its common use-case. TLS 1.2 is technically configurable in a secure manner, but hardly anyone does so correctly. With TLS 1.3, we need to get rid of all of the insecure modes so all configurations are secure (at least to start).

Dave

---

From: Yoav Nir <[email-masked]>
Date: Tue, 22 Sep 2015 21:32:45 +0300

> On Sep 22, 2015, at 8:35 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 

Doesn’t this count?

3.3.  Compression

   In order to help prevent compression-related attacks (summarized in
   Section 2.6 of [RFC7457]), implementations and deployments SHOULD
   disable TLS-level compression (Section 6.2.2 of [RFC5246]), unless
   the application protocol in question has been shown not to be open to
   such attacks.

   Rationale: TLS compression has been subject to security attacks, such
   as the CRIME attack.

(From RFC 7525)

Sure, we could leave compression in the spec, and recommend that HTTP MUST NOT use it while NNTP MAY. 

A protocol for multiple use-cases can be either one size fits all, or else have a bunch of knobs for the different uses. I prefer the one size fits all approach.

More specific to compression: people had been using TLS (and SSL) to encrypt HTTP for over two decades before the CRIME attack. That’s how long it took to realize that it is dangerous for HTTP. Are people that sure that a similar issue doesn’t exist for the much less analyzed NNTP?

Yoav

---

From: Julien ÉLIE <[email-masked]>
Date: Tue, 22 Sep 2015 20:37:34 +0200

Hi Dave,

> No sane security protocol should allow any mode which is known to be
> insecure under its common use-case.

Then the default in TLS 1.3 could be to not activate compression.

> TLS 1.2 is technically
> configurable in a secure manner, but hardly anyone does so correctly.
> With TLS 1.3, we need to get rid of all of the insecure modes so all
> configurations are secure (at least to start).

This is compatible with keeping compression as a mode that can be 
explicitly activated.

-- 
Julien ÉLIE

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 22 Sep 2015 18:40:18 +0000

The security community thinks that compression is risky, error-prone, and that a security/auth layer is the wrong place to put it.

So far, the only counter-argument has been "if TLS 1.2 has a flaw, I want to move to TLS 1.3 without losing data compression."

Is this accurate?

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

---

From: Julien ÉLIE <[email-masked]>
Date: Tue, 22 Sep 2015 20:56:17 +0200

Hi Rich,

> The security community thinks that compression is risky, error-prone,
> and that a security/auth layer is the wrong place to put it.
>
> So far, the only counter-argument has been "if TLS 1.2 has a flaw, I
> want to move to TLS 1.3 without losing data compression."
>
> Is this accurate?

Thanks for that checkpoint in the discussion!

I think the counter-arguments given so far all fall in that sentence. 
Maybe we could say "if TLS 1.2 has a flaw or if I want to benefit of the 
new facilities provided with TLS 1.3" to be more general.

-- 
Julien ÉLIE

« – Je ne peux que vous proposer l'étable…
   – Comment s'appelle ce village ?
   – Bethléem, je crois ! » (Astérix)

---

From: Jeffrey Walton <[email-masked]>
Date: Tue, 22 Sep 2015 14:56:36 -0400

> So far, the only counter-argument has been "if TLS 1.2 has a flaw, I want to move to TLS 1.3 without losing data compression."

TLS lacks a clear list of goals and objectives, so its makes things
harder and reduces some of the arguments to the favorite color of the
bikeshed.

If compression increases entropy, then one could argue its a desired
service with security benefits.

Is all compression risky, or just DEFLATE? If compression is a benefit
and DEFLATE is risky, then maybe a new compression method needs to be
offered.

Call out the goals and objectives, and most of the speculation about
what to do with it should go away. You will either find authority, or
you will lack authority, to provide it.

Jeff

---

From: Dave Garrett <[email-masked]>
Date: Tue, 22 Sep 2015 15:20:33 -0400

> service with security benefits.

It does not. Lossless compression is just storing the same information in a more compact form, without losing anything. Whatever entropy the source has is preserved, seeing as the information of the source is fully preserved. The format of this data is not relevant to this analysis.

Dave

---

From: Watson Ladd <[email-masked]>
Date: Tue, 22 Sep 2015 15:22:25 -0400

> service with security benefits.

One could. Or one could realize that for the past ~30 years, we've
understood "security" as a question about ideal vs. real
functionality, or adversarial advantage in games, and note instantly
that compression breaks every definition in the literature of secure
encryption. One could change the security notions accordingly, but
that complicates the guaranties made to higher levels.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 22 Sep 2015 20:29:07 +0100

>> some archival form (such as an RFC:-) might be a good plan.

It does count, but doesn't cover TLS1.3. And it's when TLS1.3 hits the
shelves that we'll maybe get more and more folks waking up to the fact
that we've removed functionality. (That's not so different to what seems
to be happening with HTTP/2 and client-auth maybe.)

But yes, text along those lines is what'd be needed. Depending on the
overall scope, one might want more self-contained text and less of a
dependency on references, not sure.

S.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 22 Sep 2015 22:44:41 +0300

> On Sep 22, 2015, at 9:40 PM, Salz, Rich <[email-masked]> wrote:
> 

I think the other counter-argument is that modifying NNTP to have a compression feature is hard, whereas updating the TLS library is something that implementations are likely to do.

I have to wonder if it’s worth it. In the last decade bandwidth has increased and prices for networking have gone down much faster than CPU speeds. 10 years ago having 1 Mbps at home was  the highest-end broadband you could get. Now you routinely get 100x that. CPU has increased, but nowhere near that. This makes compression less desirable, to the point that people did not complain much when browser vendors removed compression following the CRIME attacks. True, the rise of mobile brought back limited bandwidth, but is this really an issue?

Yoav

---

From: Dave Garrett <[email-masked]>
Date: Tue, 22 Sep 2015 16:06:09 -0400

On Tuesday, September 22, 2015 03:44:41 pm Yoav Nir wrote:
> people did not complain much when browser vendors removed compression following the CRIME attacks

To be fair, they didn't remove anything that was heavily used. Mozilla never even implemented TLS compression in Firefox. Google Chrome seems to be the only browser that tried and was hit with CRIME for HTTPS. Google and Mozilla got hit with it for SPDY, but removing compression in an experimental protocol isn't that much of a loss. I don't suspect too many servers supported TLS compression either, though I don't have data for that side of things.

Dave

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 22 Sep 2015 15:08:53 -0500

> I have to wonder if it’s worth it. In the last decade bandwidth has increased and prices for networking have gone down much faster than CPU speeds. 10 years ago having 1 Mbps at home was  the highe…

Well, this just came across my browser:
http://google-opensource.blogspot.co.uk/2015/09/introducing-brotli-new-compression.html

-Ben

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 22 Sep 2015 22:59:30 +0200

> service with security benefits.

Compression does not change the total amount of entropy.  It has
the same entropy but in less bits, so you increase the density.

The security should not depend on the entropy density.  After the
encryption you should not be able to tell what the density was.

Kurt

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 23 Sep 2015 03:24:08 +0000

>http://google-opensource.blogspot.co.uk/2015/09/introducing-brotli-new-

There's a million compression algorithms [0] out there, you shouldn't have any
problem finding one to fit your needs, and you don't really need to wait for
some new one to come along, there are lots of viable candidates.

Responding to the OP's comment, the "we have all the bandwidth we need"
argument is the cousin of the endlessly-used "everyone has a quad-core 2GHz i7
with 8GB of RAM so we don't need to worry about efficient algorithms any
more".  You may have the bandwidth (and a quad-core i7), but there are lots
and lots of cases that don't, and never will.

(The majority of these use store-and-forward, so CMS (S/MIME) or PGP
compression, I can't immediately think of any that use TLS compression, but
wanted to point out that "well, it works for me" isn't really a valid
argument).

Peter.

[0] Figure exaggerated slightly for theatrical effect, actual is hundreds to
    thousands depending on how you count sub-families and variants.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 22 Sep 2015 20:32:35 -0700

I think there is a compression extension for NNTP:

http://tools.ietf.org/id/draft-murchison-nntp-compress-01.html

it doesn't seem too hard. My 2c: even if this were not the case, optimizing
NNTP in a backwards compatible way does seem like a more important goal
than making transport security as secure as possible by default.

On Tue, Sep 22, 2015 at 12:44 PM, Yoav Nir <[email-masked]> wrote:

> I think the other counter-argument is that modifying NNTP to have a
> compression feature is hard, whereas updating the TLS library is something
> that implementations are likely to do.
>
> I have to wonder if it’s worth it. In the last decade bandwidth has
> increased and prices for networking have gone down much faster than CPU
> speeds. 10 years ago having 1 Mbps at home was  the highest-end broadband
> you could get. Now you routinely get 100x that. CPU has increased, but
> nowhere near that. This makes compression less desirable, to the point that
> people did not complain much when browser vendors removed compression
> following the CRIME attacks. True, the rise of mobile brought back limited
> bandwidth, but is this really an issue?
>
> Yoav

-- 
Colm

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 22 Sep 2015 22:55:58 -0700

On Tue, Sep 22, 2015 at 8:32 PM, Colm MacCárthaigh <[email-masked]>
wrote:

> it doesn't seem too hard. My 2c: even if this were not the case,
> optimizing NNTP in a backwards compatible way does seem like a more
> important goal than making transport security as secure as possible by
> default.
>

I don't think I could be more opposed to this position. The most important
transport encryption protocol on the Internet should not have sharp edges
simply to cater to the errata of Usenet.

Nobody is forcing NNTP users to use TLS 1.3. I'm not sure the new features
of TLS 1.3 even make sense for NNTP use cases. NNTP can add its own
compression. Or worst case, if there's some existential threat to TLS <
1.3, NNTP can switch and not have compression until they can implement
their own compression feature.

If compression is so important to NNTP, they should add first-class
support. Period. They should not be relying on a poorly conceived feature
which has been repeatedly demonstrated to introduce vulnerabilities in what
is supposed to be a *security protocol* just because they don't want to
implement compression themselves.

-- 
Tony Arcieri

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 23 Sep 2015 07:09:23 -0700

I meant does *NOT* seem. We agree, sorry.

-- 
Colm

---

From: Bill Frantz <[email-masked]>
Date: Wed, 23 Sep 2015 15:50:45 -0700

>feature. They shouldn't be relying on an encryption protocol to provide

IMHO, compression adds too many security vulnerabilities to a 
general purpose secure communication protocol. I think TLS 1.3 
is right in eliminating it. It is too big a foot gun.

I do have a lot of sympathy with those who have been using 
compression in previous versions of TLS. Probably the best 
solution for them is to have a TLS like library which only does 
compression. It could be largely API compatible so switching 
between TLS and compression is a relatively easy programming 
job. I'll let the TLS implementers say just how hard such a 
library would be to produce.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | "The only thing we have to   | Periwinkle
(408)356-8506      | fear is fear itself." - FDR  | 16345 
Englewood Ave
www.pwpconsult.com | Inaugural address, 3/4/1933  | Los Gatos, 
CA 95032

---

From: Jeffrey Walton <[email-masked]>
Date: Wed, 23 Sep 2015 19:17:52 -0400

> IMHO, compression adds too many security vulnerabilities to a general
> purpose secure communication protocol. I think TLS 1.3 is right in
> eliminating it. It is too big a foot gun.

To play devil's advocate: if (1) compression increases attack surface
and (2) people use compression, then wouldn't the best place to
address it be in a protocol or security library rather than pushing it
into a higher level in the stack where it likely won't be addressed?

> I do have a lot of sympathy with those who have been using compression in
> previous versions of TLS. Probably the best solution for them is to have a
> TLS like library which only does compression. It could be largely API
> compatible so switching between TLS and compression is a relatively easy
> programming job. I'll let the TLS implementers say just how hard such a

OpenSSL currently has an configuration option to build without
compression methods (no-comp). I usually build OpenSSL without
compression, and OWASP recommends building without compression
(https://www.owasp.org/index.php/C-Based_Toolchain_Hardening).

Building without compression is my personal preference, but I would
not go so far to say others should not do it because that reduces to
bike shedding. It would be like me saying, ADH and ECADH should be
removed because they don't provide any real security. Or, me saying
PKIX should be removed because the IETF provides Public Key Pinning
with Overrides, which does not provide any real real security.

Jeff

---

From: Björn Tackmann <[email-masked]>
Date: Wed, 23 Sep 2015 16:38:22 -0700

> On Sep 23, 2015, at 4:17 PM, Jeffrey Walton <[email-masked]> wrote:
> 

No, because compression is not a good idea for the general use case of TLS. It might be a good idea for specific applications (where there may be specific reasons for which it will not violate security), but then one can (and should) resolve it specifically for those applications. Even within one application, there may be parts where the security suffers from compressing, and some where it does not. Only the application can make this decision.

Best,
Bjoern

---

From: Bill Frantz <[email-masked]>
Date: Wed, 23 Sep 2015 18:59:06 -0700

>into a higher level in the stack where it likely won't be addressed?

Well, it depends. How much security do people need. In the NNTP 
case, I can't see a strong argument for confidentiality. There 
may be a need for compression, which is why I suggested a "TLC" 
(Transport Level Compression) facility, which is, to the extent 
possible, API compatible with a TLS library.

>(https://www.owasp.org/index.php/C-Based_Toolchain_Hardening).

What we need for NNTP is a build without security, but with 
compression option.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Ham radio contesting is a    | Periwinkle
(408)356-8506      | contact sport.               | 16345 
Englewood Ave
www.pwpconsult.com |  - Ken Widelitz K6LA / VY2TT | Los Gatos, 
CA 95032

---

From: Jeffrey Walton <[email-masked]>
Date: Thu, 24 Sep 2015 00:40:16 -0400

> I have to wonder if it’s worth it. In the last decade bandwidth has increased and prices for networking have gone down much faster than CPU speeds. 10 years ago having 1 Mbps at home was  the highe…
I don't think using bandwidth as a factor is a good idea.

On other lists I still see the occasional quip about suffering a low
bandwidth connection. It used to be folks in some European countries,
but most recently I seem to recall South American. (I think we're
seeing the shift because South American countries are going places
American and Europeans have already been with respect to
infrastructure).

In the rural US, I understand low bandwidth is the norm. Those folks
can't get companies like Verizon or Comcast to service them due to
population density. Its just not profitable for the providers to
update the infrastructure. Also see
https://www.google.com/search?q=rural+us+high+speed+internet.

Ironically, Steve Marquess of the OpenSSL Foundation is one of those
affected by provider's decision based on profitability.

Jeff

---

From: Yoav Nir <[email-masked]>
Date: Thu, 24 Sep 2015 10:52:39 +0300

> On Sep 24, 2015, at 7:40 AM, Jeffrey Walton <[email-masked]> wrote:
> 

At some point the countries with the least developed infrastructure eventually go through some government-led project to improve infrastructure, and that makes them leapfrog most other countries just because all their infrastructure is suddenly new. It happened in South Korea 15 years ago, and it’s happening in many African countries now. I don’t think we should burden a security protocol with a problematic mode based on a perceived need that might evaporate in a couple of years. Deploying high bandwidth is even faster now that you can make the last mile wireless rather than running copper or fiber to individual homes.

> https://www.google.com/search?q=rural+us+high+speed+internet.

That supports my point.  To quote one of the top results from that search (the first one that was not an ad):

	"53 percent of rural Americans have no access to high-speed Internet, which he defined as capable of downloading content at 25 megabits per second.”

15 years ago, having “no access to high-speed Internet” meant having just 56Kbps dial-up modem. 10 years ago it meant not having access to 0.5 Mbps broadband. The bar is now significantly higher. And you don’t usually need 25 Mbps for NNTP, although the last time I actually used NNTP was over a 56Kbps modem. 

Yoav

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 24 Sep 2015 14:04:00 +0200

On Thu, 2015-09-24 at 10:52 +0300, Yoav Nir wrote:

> At some point the countries with the least developed infrastructure
> eventually go through some government-led project to improve
> infrastructure, and that makes them leapfrog most other countries
> just because all their infrastructure is suddenly new. It happened in
> South Korea 15 years ago, and it’s happening in many African
> countries now. I don’t think we should burden a security protocol
> with a problematic mode based on a perceived need that might
> evaporate in a couple of years. Deploying high bandwidth is even
> faster now that you can make the last mile wireless rather than
> running copper or fiber to individual homes.

That only works if you think the browser over the internet usage of
TLS. TLS as used in the "Internet of Things" applications, is going to
be deployed in many low bandwidth scenarios.

regards,
Nikos

---

From: Julien ÉLIE <[email-masked]>
Date: Thu, 24 Sep 2015 22:19:04 +0200

Hi Yoav,

> And you don’t usually need 25 Mbps for NNTP, although the last time
> I actually used NNTP was over a 56Kbps modem.

Yep, accessing text-only newsgroups is fine with a 56Kbps modem, though 
getting overview data (roughly the headers of the articles) may take 
time on the "subscription" to a new newsgroup.  Compressing it reduces 
that time significantly.
People who download binaries via NNTP will need more band-width but 
well, that's their problem.

One should not forget another use case for NNTP:  the exchange of 
articles between two news servers.  Feeding articles requires more 
band-width.  Not much for a text-only feed of course.  As for a full 
binary feed, compression will be welcome (a news server may inject 
binaries and send them to dozens of peers at the same time, which 
consumes band-width).

-- 
Julien ÉLIE

---

From: Julien ÉLIE <[email-masked]>
Date: Thu, 24 Sep 2015 22:22:15 +0200

Hi Bill,

> Well, it depends. How much security do people need. In the NNTP case, I
> can't see a strong argument for confidentiality. There may be a need for
> compression, which is why I suggested a "TLC" (Transport Level
> Compression) facility, which is, to the extent possible, API compatible
> with a TLS library.
[...]
> What we need for NNTP is a build without security, but with compression
> option.

And it is probably the case for protocols other than NNTP.
The current discussion focuses on NNTP but I bet the same question can 
arise from other protocols.

-- 
Julien ÉLIE

« On a toujours tort d'essayer d'avoir raison devant des gens qui ont
   toutes les bonnes raisons de croire qu'ils n'ont pas tort. »
   (Raymond Devos)

---

From: Jeremy Harris <[email-masked]>
Date: Fri, 25 Sep 2015 19:40:05 +0100

On 23/09/15 06:55, Tony Arcieri wrote:
>  They should not be relying on a poorly conceived feature

I see people asserting that doing compression as part of a security
layer results in bad security.  I see other people asserting that
a compression layer above a security layer is both sufficient and
the way to go.  I see existing applications who are using a
transport _service_ which used to (allegedly) provide both
security and compression.

Why is it not possible for TLS1.3 to provide that same service
combination, but implemented by design in a layered fashion?
-- 
Cheers,
  Jeremy

---

From: Dave Garrett <[email-masked]>
Date: Fri, 25 Sep 2015 16:31:23 -0400

> combination, but implemented by design in a layered fashion?

At this point, you're just going to have to accept that it's not going to happen. (a TLS WG chair could randomly decide to try to reverse course, but I don't see that happening) The WG does not want to spend the significant time and effort needed to create and test a properly secured compression layer for a protocol that is not designed to deal with this, especially given that we know from experience that the application layer can do this far more effectively and safely. (see SPDY, HTTP/2 and HPACK) One way or another, you need a new compression layer, but the general consensus seems to be that it shouldn't be in TLS, at least not directly. A TLS extension might be an option, which would also let people who want compression with application layers that lack it to use it with TLS 1.2 again. I can't say for certain that the WG would even be on-board with that. (I'm not sure _I_ am) The built-in compression, though, should be considered broken and dead.

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 25 Sep 2015 20:37:23 +0000

> combination, but implemented by design in a layered fashion?

TLS is correctly agnostic of semantic boundaries, in application
data.  For this to work, applications would need to be able to ask
TLS to enable and disable compression at any time after the handshake,
once some uncompressed or compressed data has gone by.

This requires new application protocol verbs "STARTCOMPRESSION",
"STOPCOMPRESSION", and underlying support in the TLS layer.

A suitable application I/O library that supports pushing and popping
protocol "modules" onto a raw I/O stream, would be a better vehicle
for this than forcing dynamic compression support into TLS.

-- 
	Viktor.

---

From: Yuhong Bao <[email-masked]>
Date: Fri, 25 Sep 2015 16:25:34 -0700

> "STOPCOMPRESSION", and underlying support in the TLS layer.
I wonder if it would have been possible to do this via renegotiation, though this has overhead.

Yuhong Bao

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 26 Sep 2015 00:19:17 +0000

> I wonder if it would have been possible to do this via renegotiation, though

Intriguing, but moot of course, since renegotiation is gone. :)  Interesting corner-cases to think about:  is compression restarted, or do you preserve all state to pick up where you left off (e.g., the zlib dictionary)?  Either either one probably has some security issues to think about.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 26 Sep 2015 02:17:11 +0000

On Sat, Sep 26, 2015 at 12:19:17AM +0000, Salz, Rich wrote:

> Intriguing, but moot of course, since renegotiation is gone. :)  Interesting
> corner-cases to think about:  is compression restarted, or do you preserve
> all state to pick up where you left off (e.g., the zlib dictionary)?
> Either either one probably has some security issues to think about.

It would have had to be a restart.  But of course it is not happening.

-- 
	Viktor.