IETF Logo Mail Archive

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

Jeffrey Walton <noloader@gmail.com> Tue, 22 September 2015 18:56 UTC

Return-Path: <noloader@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 23BBC1AD082 for <tls@ietfa.amsl.com>; Tue, 22 Sep 2015 11:56:39 -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 zK1HZTHugvva for <tls@ietfa.amsl.com>; Tue, 22 Sep 2015 11:56:37 -0700 (PDT)
Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 BA2D21ACD8E for <tls@ietf.org>; Tue, 22 Sep 2015 11:56:37 -0700 (PDT)
Received: by ioiz6 with SMTP id z6so23785079ioi.2 for <tls@ietf.org>; Tue, 22 Sep 2015 11:56:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=2bWatG05cSqI479zkLQCftv6hpQzzhQchy/39+j9Zlo=; b=d0w2pJAXGlxYlSWK2hwwawMOeja6QZKlsObuKvMjuQBPcQPL+5BAbH+nBXVvARTRjI ZfATGTogW/T6zB/oqeTOpbl/GlvolMqeVnteWU9LCxP1Yic8LvbmlZxkcgGhBCgEHGPN xynMR+nj49mhtv3eMEebBYj4pFqRwjCgMhVpaccnBcVA6mJOiiamdpMGadSaE0N5sfs8 l/Diwnv1Ap/luc14CmOzi0b24e/KlabGpYTNeNnHAo+MXF3y6shcQ+vF3j8zXcDibwSa 5EEbv7ye/fbnE5o7P2Mdj6rg8MdVymM5p6dwrxHNkGzBecCbfZvipdc+demXJiBPLE3T ukOQ==
MIME-Version: 1.0
X-Received: by 10.107.14.196 with SMTP id 187mr37915999ioo.11.1442948197151; Tue, 22 Sep 2015 11:56:37 -0700 (PDT)
Received: by 10.36.123.131 with HTTP; Tue, 22 Sep 2015 11:56:36 -0700 (PDT)
In-Reply-To: <a3e83d0bbb994343b6715c958422438f@ustx2ex-dag1mb1.msg.corp.akamai.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>
Date: Tue, 22 Sep 2015 14:56:36 -0400
Message-ID: <CAH8yC8kotbP2L8phU9inQ63aivq+KYfo414TGH-aT_Zczu8AGg@mail.gmail.com>
From: Jeffrey Walton <noloader@gmail.com>
To: "Salz, Rich" <rsalz@akamai.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/-s558y4WYZah9bGl3sEsf8O5fS4>
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
Reply-To: noloader@gmail.com
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 18:56:39 -0000

On Tue, Sep 22, 2015 at 2: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?

TLS lacks a clear list of goals and objectives, so its makes things
harder and reduces some of the arguments to the favorite color of the
bikeshed.

If compression increases entropy, then one could argue its a desired
service with security benefits.

Is all compression risky, or just DEFLATE? If compression is a benefit
and DEFLATE is risky, then maybe a new compression method needs to be
offered.

Call out the goals and objectives, and most of the speculation about
what to do with it should go away. You will either find authority, or
you will lack authority, to provide it.

Jeff

v2.23.0 | Report a Bug | By Email