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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 22 September 2015 17:35 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 8402E1A9237 for <tls@ietfa.amsl.com>; Tue, 22 Sep 2015 10:35:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 bZyIfEfjz3hR for <tls@ietfa.amsl.com>; Tue, 22 Sep 2015 10:35:36 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 711811A9175 for <tls@ietf.org>; Tue, 22 Sep 2015 10:35:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3EABCBE87; Tue, 22 Sep 2015 18:35:35 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDnMgoSoMw4z; Tue, 22 Sep 2015 18:35:34 +0100 (IST)
Received: from [10.87.48.73] (unknown [86.46.24.221]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8BD26BE35; Tue, 22 Sep 2015 18:35:33 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1442943334; bh=UCWjk8aYludsCcEbH6BM+kDm4GBZg1F64oj9W7ebGDU=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=qVbYNLMTOAUglxHjA4J1yLGSfe9LmBubKcccykmYQcV9X2BeVoX5cu2oKSMZhuoSL 95EcwcAOD1URE90drQadM62zP1dmT8JJUGNdOdEhWreHYc3juCoAhiL+SyqI7ssTsz BSStx1TJatHr3SdIcKipguqc7P9TjuyvMEZcFrNI=
To: Tony Arcieri <bascule@gmail.com>, "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
References: <20150922132321.17789008.2591.24358@ll.mit.edu> <CAHOTMV+riEzyYQcDfh4mMRokivCD_6T=ErTKF+BP41xABWEG8A@mail.gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <56019165.3020605@cs.tcd.ie>
Date: Tue, 22 Sep 2015 18:35:33 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <CAHOTMV+riEzyYQcDfh4mMRokivCD_6T=ErTKF+BP41xABWEG8A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/VTGZ9UCTYUUoNwu_ka2f-i0EqV0>
Cc: Simon Josefsson <simon@josefsson.org>, "tls@ietf.org" <tls@ietf.org>
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: Tue, 22 Sep 2015 17:35:37 -0000


On 22/09/15 17:23, Tony Arcieri wrote:
> But an unsafe feature shouldn't be kept in
> TLS just because some protocols want to do unsafe things and are too lazy
> to implement their own compression.

Compression does have issues clearly, but it's not correct to describe
people wanting TLS to compress as lazy. They're rather looking for the
same features that TLS has offered for a couple of decades. So if there
were a way to help them, that'd be good. And if not, the onus I think
is on us in this WG to clearly explain why we're removing that feature
in TLS1.3.

That doesn't have to be text in the TLS1.3 specification but I would
guess the question may keep coming up, so documenting the answer in
some archival form (such as an RFC:-) might be a good plan.

S.