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

Yoav Nir <ynir.ietf@gmail.com> Tue, 22 September 2015 19:44 UTC

Return-Path: <ynir.ietf@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 894711B2CA6 for <tls@ietfa.amsl.com>; Tue, 22 Sep 2015 12:44:50 -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 KtZcYRxID5wm for <tls@ietfa.amsl.com>; Tue, 22 Sep 2015 12:44:49 -0700 (PDT)
Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (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 D21AA1B2C97 for <tls@ietf.org>; Tue, 22 Sep 2015 12:44:45 -0700 (PDT)
Received: by wiclk2 with SMTP id lk2so39763355wic.1 for <tls@ietf.org>; Tue, 22 Sep 2015 12:44:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3uufoLZ7H/P5u+6BFxfs0/+CpKypFPuaQTpdaKjVD9w=; b=fvGX8Ef/Gt1hVTtXxqQj097pt+EYlfwdGmmZ8iRtbJKyPH5gHp+pyhWe+b8mVnzjBT eQSdSbwPsvF7zuAiN/uKrjnebve9VwQztDwKRISi6PfAxiJmv0sbfehqCbxW9F62umkt olQ0pgYp32i/lbJ6O1npN+EiHN8VdWGM2aCANVs+2yDpf9OOaSz50+97zXDwvSr8JU0r z/C6axH8+Qb6w/OkBLZvvLrmesltE+rZJmyTQHQ/7aELvQTxpw5wfDJkJ0q0AT/xay9v DvL/YzSfIXOgKUAuY/EFk/l5GaFV+j4PBV+eDx9hPPktYTnRleMPSfxw6BWk3A523O3j QESQ==
X-Received: by 10.180.81.199 with SMTP id c7mr20929076wiy.87.1442951084457; Tue, 22 Sep 2015 12:44:44 -0700 (PDT)
Received: from [192.168.1.12] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id uq5sm3503139wjc.3.2015.09.22.12.44.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Sep 2015 12:44:43 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <a3e83d0bbb994343b6715c958422438f@ustx2ex-dag1mb1.msg.corp.akamai.com>
Date: Tue, 22 Sep 2015 22:44:41 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <92D67610-81FD-4515-AFE6-910E8B4E0F44@gmail.com>
References: <20150922132321.17789008.2591.24358@ll.mit.edu> <CAHOTMV+riEzyYQcDfh4mMRokivCD_6T=ErTKF+BP41xABWEG8A@mail.gmail.com> <56019B0F.3020208@trigofacile.com> <201509221423.38061.davemgarrett@gmail.com> <56019FEE.5010008@trigofacile.com> <a3e83d0bbb994343b6715c958422438f@ustx2ex-dag1mb1.msg.corp.akamai.com>
To: Rich Salz <rsalz@akamai.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/WyZoUxq9hew59EqqQLKfxUfrDvA>
Cc: "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 19:44:50 -0000

> On Sep 22, 2015, at 9:40 PM, Salz, Rich <rsalz@akamai.com> wrote:
> 
> The security community thinks that compression is risky, error-prone, and that a security/auth layer is the wrong place to put it.
> 
> So far, the only counter-argument has been "if TLS 1.2 has a flaw, I want to move to TLS 1.3 without losing data compression."
> 
> Is this accurate?

I think the other counter-argument is that modifying NNTP to have a compression feature is hard, whereas updating the TLS library is something that implementations are likely to do.

I have to wonder if it’s worth it. In the last decade bandwidth has increased and prices for networking have gone down much faster than CPU speeds. 10 years ago having 1 Mbps at home was  the highest-end broadband you could get. Now you routinely get 100x that. CPU has increased, but nowhere near that. This makes compression less desirable, to the point that people did not complain much when browser vendors removed compression following the CRIME attacks. True, the rise of mobile brought back limited bandwidth, but is this really an issue?

Yoav