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

From: "Alewa, Christos" <[email-masked]>
Date: Thu, 17 Sep 2015 13:23:19 +0000

Dear Ladies and Gentlemen of the TLS Working Group,

my name is Christos Alewa and I am writing you on behalf HOB GmbH & Co KG, a software enterprise from Germany, which specialises in development of software particularly for secure remote access.
Our main product HOB RD VPN has received the Common Criteria EAL 4+ certificate by the German Federal Office for Information Security (BSI) which inadvertantly proves the level of security achieved - being the highest certificate available for commercial software.

I've been redirected to this e-mail in order to address our company's issue regarding the proposed cease of support for compression in the new TLS 1.3 protocol.
That said, i will relay our modest request to you as I have done already before:
Since we at HOB, use SSL to maintain long-running VPN connections, might it be possible to - at least - maintain the status quo of the TLS - protocol in this aspect, enabling and disabling compression if needed?

As a proposal to negate the known side-attack on the compression rate, which is in my understanding the reason support for compression is to be removed altogether, our thoughts are that a possible way to prevent this kind of side-attack might be to insert a nonce (random data with random length) to SSL records of type "application data". These need to be inserted in the beginning of the SSL record payload, rendering the monitoring of the compression rate of an attacker useless.

With regards,
Christos Alewa
Software Instructor

+499103-715-3553
HOB GmbH & Co KG
Cadolzburg,Germany

________________________________

Follow HOB:

- HOB: http://www.hob.de/redirect/hob.html
- Xing: http://www.hob.de/redirect/xing.html
- LinkedIn: http://www.hob.de/redirect/linkedin.html
- HOBLink Mobile: http://www.hob.de/redirect/hoblinkmobile.html
- Facebook: http://www.hob.de/redirect/facebook.html
- Twitter: http://www.hob.de/redirect/twitter.html
- YouTube: http://www.hob.de/redirect/youtube.html
- E-Mail: http://www.hob.de/redirect/mail.html

HOB RD VPN - einfach, sicher und flexibel auf alle Unternehmensanwendungen und -daten zugreifen

Praesentation unter: http://www.hob.de/rdvpn2/

HOB GmbH & Co. KG
Schwadermuehlstr. 3
D-90556 Cadolzburg

Geschaeftsfuehrung: Klaus Brandstaetter, Zoran Adamovic

AG Fuerth, HRA 5180
Steuer-Nr. 218/163/00107
USt-ID-Nr. DE 132747002

Komplementaerin HOB electronic Beteiligungs GmbH
AG Fuerth, HRB 3416

---

From: Julien ÉLIE <[email-masked]>
Date: Fri, 18 Sep 2015 20:29:54 +0200

Hi all,

> the proposed cease of support for compression in the new TLS 1.3 protocol
[...]
> Since we at HOB, use SSL to maintain long-running VPN connections, might
> it be possible to - at least - maintain the status quo of the TLS -
> protocol in this aspect, enabling and disabling compression if needed?

I would also be in favour of having the ability to control whether 
compression is enabled.
INN (a wide-spread news server) even permits to control that with its 
configuration file (we have a tlscompression parameter in inn.conf that 
can be set to false if needed).  Other parameters (tlsciphers, 
tlseccurve, tlspreferserverciphers and tlsprotocols) also permit to 
tweak the allowed ciphers, etc. that can be used.

Besides, as far as I know, the NNTP protocol is not vulnerable to CRIME 
attacks.

Also please note that a common use of TLS for NNTP is to enable 
compression (security is not always necessary), as RFC 4642 recalls:

    The STARTTLS command is usually used to initiate session security,
    although it can also be used for client and/or server certificate
    authentication and/or data compression.

-- 
Julien ÉLIE

« Petite annonce : Sourd rencontrerait sourde pour terrain
   d'entente. »

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 18 Sep 2015 19:47:27 +0000

Can NNTP and HOB/VPN stay on TLS 1.2 which does have the compression feature you need?  What TLS 1.3 feature is compelling here?

---

From: Julien ÉLIE <[email-masked]>
Date: Fri, 18 Sep 2015 22:25:39 +0200

Hi Rich,

> Can NNTP and HOB/VPN stay on TLS 1.2 which does have the compression
> feature you need?  What TLS 1.3 feature is compelling here?

Reading latest draft-ietf-tls-rfc5246-bis, I think the relevant 
paragraph is:

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

Well, it is true that NNTP can stay on TLS 1.2.  News clients and news 
servers can implement TLS 1.2 and use it.
The concern will be when TLS 1.2 is declared "flawed".  Maybe one day it 
will be considered insecure; and then, compliant TLS implementations 
won't be able to use compression.  That facility will then be lost.

I understand that a few protocols (like HTTPS) have vulnerabilities when 
compression is used.  Nonetheless, is it a sufficient reason to no 
longer support compression in TLS 1.3?
Wouldn't it be better to disable compression in implementation of 
vulnerable protocols?  (For instance Firefox, Apache...)

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.

-- 
Julien ÉLIE

« La vraie valeur d'un homme se mesure lorsqu'il a tout perdu. »

---

From: Kurt Roeckx <[email-masked]>
Date: Sat, 19 Sep 2015 13:46:49 +0200

> Since we at HOB, use SSL to maintain long-running VPN connections, might it be possible to - at least - maintain the status quo of the TLS - protocol in this aspect, enabling and disabling compress…

If compression is dropped at the TLS layer, you can still do it at
the layer above it.

Kurt

---

From: Loganaden Velvindron <[email-masked]>
Date: Sat, 19 Sep 2015 12:29:45 +0000

> If compression is dropped at the TLS layer, you can still do it at
Indeed. And, it's probably a better idea to do it in the layer above.

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

---

From: Julien ÉLIE <[email-masked]>
Date: Sat, 19 Sep 2015 15:09:33 +0200

Hi Loganaden,

> Indeed. And, it's probably a better idea to do it in the layer above.

Then how will the news server know that the client is compressing data 
after the use of STARTTLS where a security layer without compression has 
been negotiated?
It cannot guess it; and it won't try all uncompression methods to see 
which one has been used.

Unless you are speaking of an update of the NNTP protocol to add a new 
compression capability (for instance with the use of a new COMPRESS 
command with possible arguments), that could be used by clients?
Well, it will require some work to specify it.  Not to speak of its 
implementation afterwards.

I bet other protocols would also need similar new specifications to 
explain how compression can be enabled.

-- 
Julien ÉLIE

« Etna : lave dévalante. »

---

From: Geoffrey Keating <[email-masked]>
Date: 19 Sep 2015 12:44:41 -0700

> explain how compression can be enabled.

I think that's the idea.  TLS compression only works for NNTP because no
confidentiality is required.  In other protocols, there's at least
something (if not everything) where confidentality is desirable and so
compression needs to be specified very carefully if at all.

Even in NNTP, you don't want compression if you're using
AUTHINFO---and how do you know AUTHINFO will or won't be used at the
time of STARTTLS?

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 19 Sep 2015 20:06:37 +0000

> Well, it is true that NNTP can stay on TLS 1.2.  News clients and news servers
> can implement TLS 1.2 and use it.
> The concern will be when TLS 1.2 is declared "flawed".  Maybe one day it will
> be considered insecure; and then, compliant TLS implementations won't be
> able to use compression.  That facility will then be lost.

Yes.

It is widely recognized that in many cases, TLS-level compression is flawed (for example NNTP authinfo?).  TLS 1.3 does not have it.  So NNTP that needs compression can continue to use TLS 1.2, and if TLS 1.2 is "flawed" things can change.

	/r$

---

From: Dave Garrett <[email-masked]>
Date: Sat, 19 Sep 2015 16:49:38 -0400

On Saturday, September 19, 2015 04:06:37 pm Salz, Rich wrote:
> On Friday, September 18, 2015 04:25:39 pm Julien ÉLIE wrote:

Contrary to its name, TLS is not a transport protocol. It's a security protocol, and compression is not a security feature. (though, when combined with padding, I could see how it could be useful) It didn't belong in the spec like it was, even if it worked safely. It might be doable in a TLS extension, but I don't think this is a great idea. Application protocols can handle compression better and more safely, as they can actually know what they're doing and how to properly compress it.

Even if TLS compression could be fixed, the old insecure junk doesn't magically go away. It needs to be treated as ruined forever, just to be safe, as far as I'm concerned. If you need compression, I wouldn't recommend relying on it here.

Dave

---

From: Julien ÉLIE <[email-masked]>
Date: Sun, 20 Sep 2015 11:02:19 +0200

Hi Rich,

> It is widely recognized that in many cases, TLS-level compression is
> flawed (for example NNTP authinfo?).

Though I've read a few pages explaining how CRIME and BEAST attacks 
work, I still do not see well how TLS-level compression would make NNTP 
vulnerable.
Same thing for POP or IMAP I believe.

The news server does not leak information.  The responses are just OK or KO.
For instance:

AUTHINFO USER test
381 Enter password
AUTHINFO PASS test
281 Authentication succeeded

or in the case of an authentication failure:

AUTHINFO USER test
381 Enter password
AUTHINFO PASS badpassword
481 Authentication failed

How compression would make NNTP weaker?
(Brute-force attack is still necessary, even with compression enabled.)

-- 
Julien ÉLIE

---

From: Watson Ladd <[email-masked]>
Date: Sun, 20 Sep 2015 07:28:35 -0400

On Sun, Sep 20, 2015 at 5:02 AM, Julien ÉLIE <[email-masked]> wrote:
> Though I've read a few pages explaining how CRIME and BEAST attacks work, I
> still do not see well how TLS-level compression would make NNTP vulnerable.

This analysis would predict that HTTP isn't vulnerable. Furthermore,
the whole point is that TLS is supposed to provide certain services to
upper levels, and not require this kind of detailed analysis in
security designs.

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

---

From: Julien ÉLIE <[email-masked]>
Date: Sun, 20 Sep 2015 14:09:42 +0200

Hi Watson,

> This analysis would predict that HTTP isn't vulnerable.

I don't understand that point for AUTHINFO.
NNTP only answers "281 Authentication succeeded" or "481 Authentication 
failed" here, whereas HTTP response bodies are far more complex and part 
of the request may be reflected in the response.

-- 
Julien ÉLIE

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Sun, 20 Sep 2015 14:26:11 +0200

Julien,

It may well be true that some (typically unauthenticated) application protocols on top of TLS can survive TLS compression, 
but it is unlikely.  You ask a pointed question about AUTHINFO, so just as a fun game, let’s analyze its security:

AUTHINFO USER test
381 Enter password
AUTHINFO PASS test

From a formal security viewpoint, the logic behind disabling compression in this exchange is as follows.
TLS does not hide the length of plaintext, so an 8-character password  is distinguishable from a 4-character one.
While this loss of confidentiality may arguably be expected and acceptable, compression makes it worse.

Consider the two lines:
AUTHINFO PASS AAAAAAAA
AUTHINFO PASS 12345678

Both passwords have 8 characters, and so when no compression is used, a passive network adversary cannot distinguish between them.
However, if they are compressed with gzip, the first results in 7 fewer bytes than the second. 
So compression of this line already yields 3 bits of the password to a passive adversary.
No online attack needed so far.

Suppose, the client also uses this password with a different command (e.g. XSECRET).

XSECRET test AAAAAAAA
XSECRET test 12345678

Now looking at the compressed lengths of this, the passive attacker can get another 3 bits. Considering that the average password entropy can be as low as 20 bits [1], the attacker now has a significant headstart on any other attack she may wish to pursue. 

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.

Best,
Karthik

[1] http://www.jbonneau.com/doc/B12-IEEESP-analyzing_70M_anonymized_passwords.pdf

> On 20 Sep 2015, at 14:09, Julien ÉLIE <[email-masked]> wrote:
> 
> Hi Watson,
> 
> NNTP only answers "281 Authentication succeeded" or "481 Authentication failed" here, whereas HTTP response bodies are far more complex and part of the request may be reflected in the response.
> 
> -- 
> Julien ÉLIE
>

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 20 Sep 2015 13:11:50 +0000

> (Brute-force attack is still necessary, even with compression enabled.)

I don't know, which is why I put a question mark; someone else suggested it.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 20 Sep 2015 13:30:18 +0000

> (Brute-force attack is still necessary, even with compression enabled.)

Consider what happens when data that follows authentication (in
sunsequent message bodies) either does or does not match some part
of the password...

-- 
	Viktor.

---

From: Julien ÉLIE <[email-masked]>
Date: Sun, 20 Sep 2015 16:54:40 +0200

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

If TLS 1.3 is used, so without compression facility, adding a new 
COMPRESS command to NNTP will not help if how authentication is done is 
not strenghtened at the same time, won't it?
Or AUTHINFO is not a valid command after the use of COMPRESS.

-- 
Julien ÉLIE

---

From: Julien ÉLIE <[email-masked]>
Date: Sun, 20 Sep 2015 20:10:42 +0200

Hi Geoffrey,

> compression needs to be specified very carefully if at all.

OK, understood.

> AUTHINFO---and how do you know AUTHINFO will or won't be used at the

Note that AUTHINFO can also use any available SASL mechanisms instead of 
sending plain user/pass.  (Depending on the SASL mechanism, a security 
layer can be negotiated during the SASL exchange.)  Unfortunately, that 
facility is not wide-spread in news clients and servers.

To respond to your question, STARTTLS is not available after a 
successful authentication.  Therefore, it cannot be used after STARTTLS. 
  RFC 4642 states:

    A server supporting the STARTTLS command as defined in this document
    will advertise the "STARTTLS" capability label in response to the
    CAPABILITIES command ([NNTP] Section 5.2).  However, this capability
    MUST NOT be advertised once a TLS layer is active (see Section 2.2.2)
    or after successful authentication [NNTP-AUTH].

However, though that practice is discouraged, most of news clients still 
connect to port 563 (dedicated to NNTPS) and negotiate a TLS security 
layer upon connection.  They do not use STARTTLS in that case; and 
clients can authenticate with AUTHINFO, with an active TLS layer.

-- 
Julien ÉLIE

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

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 19 Sep 2015 15:04:05 -0400

> feature you need?  What TLS 1.3 feature is compelling here?

I think this line of argument is worrisome -- we should try to avoid
leaving behind protocols that need TLS, if we ever want to be able to
deprecate TLS 1.2 the way we've (finally) deprecated SSLv3.

That said, i think there are multiple approaches for NNTP and HOB/VPN
that don't involve using compression at the TLS layer.

For instance, with NNTP, if they're certain that CRIME isn't a risk for
their use case, they could introduce a STARTCOMPRESSION verb by analogy
to STARTTLS.  If the only reason they're using TLS in the first place is
for compression, this would be a simpler and less-risky approach in
terms of software dependencies as well.  I don't know enough about HOB's
use of TLS to know whether they could shim their own compression layer
in between the VPN traffic or not.

The TLS WG knows that compression represents a serious risk to encrypted
traffic, especially in situations like browsers where an adversary can
direct a peer to initiate protocol action.  Compression itself also
represents added complexity for protocol analysis.

I think we should remove compression and we should also explicitly warn
users of the protocol about the risks of combining compression with TLS.

      --dkg

---

From: Tony Arcieri <[email-masked]>
Date: Sun, 20 Sep 2015 14:15:09 -0700

On Sat, Sep 19, 2015 at 12:04 PM, Daniel Kahn Gillmor <[email-masked]
> wrote:

> users of the protocol about the risks of combining compression with TLS.

+1

-- 
Tony Arcieri

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 22 Sep 2015 10:06:31 +0200

> with the insertion of random data with random length along with the

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