IETF Logo Mail Archive

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

Dave Garrett <davemgarrett@gmail.com> Fri, 25 September 2015 20:31 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 929D21A1B0D for <tls@ietfa.amsl.com>; Fri, 25 Sep 2015 13:31:27 -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 MJxDtv2xTXJX for <tls@ietfa.amsl.com>; Fri, 25 Sep 2015 13:31:26 -0700 (PDT)
Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (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 4B4651A1ADF for <tls@ietf.org>; Fri, 25 Sep 2015 13:31:26 -0700 (PDT)
Received: by qgt47 with SMTP id 47so79011664qgt.2 for <tls@ietf.org>; Fri, 25 Sep 2015 13:31:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=b9XKhMpFrIprGft1EgWcy8UQtNOKUiODI8Du3pDevLY=; b=WFWXgUq85b14eqr9FyHS7rtWzXn5C57THWr8HREiYjtSQktRekx4Ix2LIMj0hVymU4 v0PCvbaHp56Pfus71DSVf0IuhPmffi+CBZ8DQDD40fOSEWZ4N3e/Ra4ijifyLwveovaq d7Lwitit9XVG0ELPFtmbwJSwax3Dds/J8wDtA8dJqaIB/EqZ/QEvo4+mPcZ8a9R3lQEj wLhNKl+Y7cQAhrSGr2FCEwfLIgH6NeuQMJkfdpDHVQjy3nWmc5Cil5jOq/1uI0Hn7MXi 8NahLUlEAoOlxqNt9TxNwKEQLsmGKVAZEtRjTCRUJur73cnMX9aXWLJrveWYQnfNoSP2 O8IQ==
X-Received: by 10.140.39.180 with SMTP id v49mr8481494qgv.98.1443213085318; Fri, 25 Sep 2015 13:31:25 -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 b16sm2162709qkj.1.2015.09.25.13.31.24 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 25 Sep 2015 13:31:24 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org, Jeremy Harris <jgh@wizmail.org>
Date: Fri, 25 Sep 2015 16:31:23 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <20150922132321.17789008.2591.24358@ll.mit.edu> <CAHOTMV+jB9N4AS60voE5pFNVaL6hJnOQDt5b3V-6k5GsByW3AQ@mail.gmail.com> <56059505.5000001@wizmail.org>
In-Reply-To: <56059505.5000001@wizmail.org>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201509251631.23760.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/j6V-R-uBzyVBAbGL3seeP--3XMg>
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: Fri, 25 Sep 2015 20:31:27 -0000

On Friday, September 25, 2015 02:40:05 pm Jeremy Harris wrote:
> Why is it not possible for TLS1.3 to provide that same service
> 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

v2.23.0 | Report a Bug | By Email