Re: [TLS] Confirmation of Consensus on Removing Compression from TLS 1.3

Martin Thomson <martin.thomson@gmail.com> Wed, 26 March 2014 19:57 UTC

Return-Path: <martin.thomson@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 8D51D1A03CC for <tls@ietfa.amsl.com>; Wed, 26 Mar 2014 12:57:18 -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 Jds92ZQU8wWk for <tls@ietfa.amsl.com>; Wed, 26 Mar 2014 12:57:17 -0700 (PDT)
Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 08AE11A01E9 for <tls@ietf.org>; Wed, 26 Mar 2014 12:57:16 -0700 (PDT)
Received: by mail-wg0-f42.google.com with SMTP id y10so1623071wgg.13 for <tls@ietf.org>; Wed, 26 Mar 2014 12:57:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xZPxXK/NGG3nm9asSrrcu0UwVFKcxpGvosxnxem9Q1A=; b=vBYxe08wXe+KLgGeN5exXl7ZeZ2woymMrej+erTa1hZNwE/Vs3H5X+cy+JMOXtGKpn BAgETvTip3k6mtZT/WrSvk+YjaTDJEVgKxeJXM6OOKvlYlEA2mIBdYIPsomiGgtCNiUJ F9FPSIZlEOPOgRgHEdJ8TpthEXzD03XDwUX9vdPVJMldL0jdmWQsPW3gvxKRAnUXcFA+ yVxAdahb0qHLoWQySvm8wwk9gilx5haQcR5Z2G3d6ATNs1MSTpxQaSD+QfEBNr1hMZgu peAf8Ubgp4OlAtEhTJ0p4F+kpdOgNqo+RK7mpOVfGbMNmlVhhBR1mKGKNAbWLjECfWks 54VQ==
MIME-Version: 1.0
X-Received: by 10.180.221.68 with SMTP id qc4mr31795694wic.30.1395863834946; Wed, 26 Mar 2014 12:57:14 -0700 (PDT)
Received: by 10.227.147.10 with HTTP; Wed, 26 Mar 2014 12:57:14 -0700 (PDT)
In-Reply-To: <53332D3D.5020908@gmail.com>
References: <DA7A3139-EE44-4FE2-B674-4ECAE4D51079@cisco.com> <53332D3D.5020908@gmail.com>
Date: Wed, 26 Mar 2014 12:57:14 -0700
Message-ID: <CABkgnnWCqPewKJ0NPeq1MnGo3J9wc7BRRbsCwbNucV7k3EjZyg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UjHNYNyuysDlbBb9WmM7zXE_pdE
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Confirmation of Consensus on Removing Compression from TLS 1.3
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: <http://www.ietf.org/mail-archive/web/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: Wed, 26 Mar 2014 19:57:18 -0000

On 26 March 2014 12:40, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
> The reason is that we have compression at the HTTP layer too, it is widely
> used, and is subject to similar vulnerabilities when run over TLS. AFAIK,
> no-one is proposing to ban HTTP compression [1]. So we're just moving the
> problem to a different protocol layer, one that may be less security
> conscious.

I think that this is perhaps the wrong interpretation.  I wouldn't
want to assume that TLS has a monopoly on communications security.
HTTPbis is acutely aware of the risks that compression comes with.

Compression is critical to the performance of HTTP/2.  HTTP/2 has
mandated support for compression, despite the risks, because the
performance gains are considered worth pursuing anyway.

The general trend I've observed in these discussions is to move the
decision to compress closer to the application.  This means that the
decision can be informed better by context.  Generically applied
compression is necessarily less aware of constraints on its use.

For that reason, I support the decision here.  Application protocols
will be more aware of hazards.  TLS will be easier to build without
this baggage.