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

"Alewa, Christos" <christos.alewa@hob.de> Thu, 17 September 2015 13:23 UTC

Return-Path: <christos.alewa@hob.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B991B2F08 for <tls@ietfa.amsl.com>; Thu, 17 Sep 2015 06:23:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.442
X-Spam-Level:
X-Spam-Status: No, score=0.442 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FSL_MY_NAME_IS=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYBZLiePY1KP for <tls@ietfa.amsl.com>; Thu, 17 Sep 2015 06:23:24 -0700 (PDT)
Received: from hobex19.hob.de (hobex19.hob.de [212.185.199.31]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49BD91B2FB2 for <tls@ietf.org>; Thu, 17 Sep 2015 06:23:23 -0700 (PDT)
Received: from HOBEX22.hob.de (172.22.1.22) by hobex19.hob.de (172.25.1.31) with Microsoft SMTP Server (TLS) id 14.2.347.0; Thu, 17 Sep 2015 15:23:07 +0200
Received: from HOBEX21.hob.de ([fe80::886:fbb5:dd12:7a2f]) by HOBEX22.hob.de ([::1]) with mapi id 14.02.0387.000; Thu, 17 Sep 2015 15:23:21 +0200
From: "Alewa, Christos" <christos.alewa@hob.de>
To: "'tls@ietf.org'" <tls@ietf.org>
Thread-Topic: TLS 1.3 - Support for compression to be removed
Thread-Index: AdDxQJ3JYArzGe7ATXi4PYaM2RxpYA==
Date: Thu, 17 Sep 2015 13:23:19 +0000
Message-ID: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.24.71.140]
old-x-esetresult: clean, is OK
old-x-esetid: 46BD7B39450636351CF824
x-esetresult: clean, is OK
x-esetid: 46BD7B39450636351CF824
Content-Type: multipart/alternative; boundary="_000_79C632BCF9D17346A0D3285990FDB01AA3B9DAD8HOBEX21hobde_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ZBXl6g_pcSJGRLbN6eJChWI3gFc>
X-Mailman-Approved-At: Thu, 17 Sep 2015 21:46:57 -0700
Subject: [TLS] TLS 1.3 - Support for compression to be removed
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Sep 2015 13:24:09 -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