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

Dave Garrett <davemgarrett@gmail.com> Sat, 19 September 2015 20:49 UTC

Return-Path: <davemgarrett@gmail.com>
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 20DC11A8F34 for <tls@ietfa.amsl.com>; Sat, 19 Sep 2015 13:49:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 HPmd1HZgjnIp for <tls@ietfa.amsl.com>; Sat, 19 Sep 2015 13:49:43 -0700 (PDT)
Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB5B61A8BC0 for <tls@ietf.org>; Sat, 19 Sep 2015 13:49:42 -0700 (PDT)
Received: by qgx61 with SMTP id 61so63719205qgx.3 for <tls@ietf.org>; Sat, 19 Sep 2015 13:49:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=SiiOPy056/gv2PkEh3ELFgAaNaA2VS6+0LiWNsyYutY=; b=zKrefZvet8PX6QogKgr2ZFZWcbeqFEDuuzAKWeA+/3msOuvj9qo+ImU5Bm1igyTkJq /xRNZyY0XQanyKJmS0C0PPvrxes9MM73UVz5AUThAhKp7P1la8Fs9lRR/PolohYKPQYs K/W5zfB4wyq7WbiBEZTKODjCNhVwOnFPG2QZ85Nal6DD8k8500yyXwZ9biiCYef3ZVMY x768IMam6bfgypC2AfobthmRUJoMRY1ZzDGfQV/ZTDCE8O+jyHqIKCUtE0YpfVh3hpHu lYrAOs6EQ0vkVx/LKbLjv35vzQjtNiPmGFX6Q9P0sPMz3fTwNtvSmqehrs9WSurSXHN3 UEcg==
X-Received: by 10.140.89.47 with SMTP id u44mr13916176qgd.67.1442695781938; Sat, 19 Sep 2015 13:49:41 -0700 (PDT)
Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id f103sm6501913qkh.38.2015.09.19.13.49.40 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 19 Sep 2015 13:49:41 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org
Date: Sat, 19 Sep 2015 16:49:38 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <55FC7343.3090301@trigofacile.com> <fa252c02f4504e5fb11cb95aa2701562@ustx2ex-dag1mb1.msg.corp.akamai.com>
In-Reply-To: <fa252c02f4504e5fb11cb95aa2701562@ustx2ex-dag1mb1.msg.corp.akamai.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201509191649.39277.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ZuXhGJCptTtyfaRFXMknUvFrSM4>
Cc: "Alewa, Christos" <christos.alewa@hob.de>
Subject: Re: [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: Sat, 19 Sep 2015 20:49:44 -0000

On Saturday, September 19, 2015 04:06:37 pm Salz, Rich wrote:
> On Friday, September 18, 2015 04:25:39 pm Julien ÉLIE wrote:
> > 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.

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