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

Joachim Strömbergson <joachim@secworks.se> Thu, 27 March 2014 08:30 UTC

Return-Path: <joachim@secworks.se>
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 C83CC1A04A6 for <tls@ietfa.amsl.com>; Thu, 27 Mar 2014 01:30:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.25
X-Spam-Level:
X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no
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 HgTKw7VyFnk4 for <tls@ietfa.amsl.com>; Thu, 27 Mar 2014 01:30:50 -0700 (PDT)
Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4441A049F for <tls@ietf.org>; Thu, 27 Mar 2014 01:30:49 -0700 (PDT)
Received: from secworks82.gotanet.se (unknown [62.80.223.82]) by mail.frobbit.se (Postfix) with ESMTPSA id 1D16B20164; Thu, 27 Mar 2014 09:30:47 +0100 (CET)
Message-ID: <5333E1B5.2060601@secworks.se>
Date: Thu, 27 Mar 2014 09:30:45 +0100
From: =?ISO-8859-1?Q?Joachim_Str=F6mbergson?= <joachim@secworks.se>
User-Agent: Postbox 3.0.9 (Macintosh/20140129)
MIME-Version: 1.0
To: Martin Thomson <martin.thomson@gmail.com>
References: <DA7A3139-EE44-4FE2-B674-4ECAE4D51079@cisco.com> <53332D3D.5020908@gmail.com> <CABkgnnWCqPewKJ0NPeq1MnGo3J9wc7BRRbsCwbNucV7k3EjZyg@mail.gmail.com>
In-Reply-To: <CABkgnnWCqPewKJ0NPeq1MnGo3J9wc7BRRbsCwbNucV7k3EjZyg@mail.gmail.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Gb-liKCQhTsqHib98LH_Xxm1n0M
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Confirmation of Consensus on Removing Compression from TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: joachim@secworks.se
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: <http://www.ietf.org/mail-archive/web/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, 27 Mar 2014 08:30:52 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Aloha!

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

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

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

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

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
 Joachim Strömbergson          Secworks AB          joachim@secworks.se
========================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJTM+G1AAoJEF3cfFQkIuyNQRQQAIpN9toxSZgckekZoRa5ovbA
dvLGlkBdNSpFmJym72/9xC8IdO4puQjPT6Aj+fofO6BdL5OAR6/1j60CMMMF5SMj
IdYgRv3zo13YDgcC1zs+gYPeqEP+XQhY2yE598ifo/BWWq9fJtGlO2Eh0R4ZkO7I
81ANwoetnTQcGILAXknZv9elrC4sm7Jq4xHXaBCDiYC6a7NUxW7AbHJJdAJVNL+j
bYiLQ/fuXKSbUgXbyAnbjip81lUKU5QorLpZMcF7n6C5YEED+eO4K7kXEZmfMn0D
oFd5cnaDau842p7wfWamNDEKFQemTzJii8SSHSdu4PRbNGebGNTDcXv52dJWIdts
7SVZNT8l+JKMr5HoO0enZFXkm+IwNjXWd1xzMtg2l7nNhN6PAAa4rpG72jzWk7Ba
Jo8dYW7+a9JiJDiSCNz+FI2F/fMwf++DzRlP7KGHCUcEIb1sesjWzO9tk64ZKoZy
pM0+WNt0EyCU+4g5gPH6xa8TjgKM3j3JIgEUc1Mzf3xWzix7u2NveQfC23m9qmVi
Hx8FUFwTqlH0C3NF9wJMeV9ZlGB02YS8DOSZOj2BqHJyOZFXiXusK0qhq4zBA6p/
UiiQFcURaiRGLbVjCFB6NQrbNRMY/0F1uR5hTxEux0CfW1ygTF5ep3of+bswyYDi
BsKRLXLBNJLYEuT+8f9t
=iAnB
-----END PGP SIGNATURE-----