IETF Logo Mail Archive

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

Tony Arcieri <bascule@gmail.com> Sun, 04 October 2015 17:50 UTC

Return-Path: <bascule@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 1D2FF1B33F0 for <tls@ietfa.amsl.com>; Sun, 4 Oct 2015 10:50:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 J4pnRG-eVz0K for <tls@ietfa.amsl.com>; Sun, 4 Oct 2015 10:50:14 -0700 (PDT)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 625911B33EF for <tls@ietf.org>; Sun, 4 Oct 2015 10:50:14 -0700 (PDT)
Received: by igbkq10 with SMTP id kq10so48917071igb.0 for <tls@ietf.org>; Sun, 04 Oct 2015 10:50:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ExsEFgkR/p4EB7uGbGFCK0RHRJtLDjSinSY0qHdqo20=; b=sn82P1kKX52VzdCtVYOoZu4GLeXzG6X1puS2tzJJrCIdjMIoSTtCLeSO/Vuv5OLvvT J4KkbNScjq2u1Kxi8c2lZs2foU6V5G9PYV0OhDQc43/HPgxLz/KRoAgpRZJuyAGLe8vc c0gqwb6B9llyySSAjWn/kBwmmAPHfJ12cwF7a6VbNQJPOPSP3HvTPReEPEepd319BAaa LcRC+PGQ6XV4EHtx70fpxsPGGEG6H9Wp0xI9vgSUwxXk73YhGalMYyO9Olu6xK2CC39A YzpCL5cCj7bgPO+eShgveu6Thy5jT2q0lxWDtvVgs3MHj9lO4yrgNr/yJilBM2cfef1G Qz1g==
X-Received: by 10.50.66.141 with SMTP id f13mr5787278igt.51.1443981013571; Sun, 04 Oct 2015 10:50:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.19.67 with HTTP; Sun, 4 Oct 2015 10:49:53 -0700 (PDT)
In-Reply-To: <ED4C2E8B-3327-451E-8E59-D87705B935C8@gmail.com>
References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <55FC5822.5070709@trigofacile.com> <77583acbe981488493fd4f0110365dae@ustx2ex-dag1mb1.msg.corp.akamai.com> <55FC7343.3090301@trigofacile.com> <6796F70E-44FD-4CD8-A691-6D0BFAE6EFDC@cs.meiji.ac.jp> <682cb934aeeb42fabdf1fecfccf4c5b5@ustx2ex-dag1mb3.msg.corp.akamai.com> <7E1B8B3D-DEF5-439A-8E56-0CB2DFC061A8@cs.meiji.ac.jp> <ED4C2E8B-3327-451E-8E59-D87705B935C8@gmail.com>
From: Tony Arcieri <bascule@gmail.com>
Date: Sun, 04 Oct 2015 10:49:53 -0700
Message-ID: <CAHOTMVL+C4Q2=wAVMWmSbyzmmZb7o6pucN=bEKv70eq8wWLA_w@mail.gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="047d7bdc0dd260610805214b0722"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ruUHche6czazBeR-195nFnvLgDk>
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: Sun, 04 Oct 2015 17:50:16 -0000

On Sat, Oct 3, 2015 at 4:54 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:

> An even more executive-level lesson might be that security layers should
> not provide non-security services, but that is not really convincing
> because if there was a separate compression layer that you could compose
> with the security layer in TLS, CRIME would still be possible. To compress
> HTTP without the danger of CRIME you need to either not compress header
> fields with sensitive information, not compress header fields that might be
> controlled by an attacker, or at least delegate those to a separate
> compression state.


The attack you're describing (or one fairly close to it) already happened,
and it's called BREACH. It impacts HTTP compression, and allows attackers
to recover things like CSRF tokens in page bodies.

The takeaway for me is you can't mix compression, any fixed value an
attacker wishes to learn, and attacker-controlled data, or there will be a
compression side-channel.

-- 
Tony Arcieri

v2.23.0 | Report a Bug | By Email