IETF Logo Mail Archive

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

Jeffrey Walton <noloader@gmail.com> Mon, 05 October 2015 02:19 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 5738C1B3F24 for <tls@ietfa.amsl.com>; Sun, 4 Oct 2015 19:19: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 SXHU9xPl0uee for <tls@ietfa.amsl.com>; Sun, 4 Oct 2015 19:19:17 -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 092B91B3F21 for <tls@ietf.org>; Sun, 4 Oct 2015 19:19:17 -0700 (PDT)
Received: by iofh134 with SMTP id h134so171579696iof.0 for <tls@ietf.org>; Sun, 04 Oct 2015 19:19:16 -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=Fl7Bm5Cz/pPyxkH/nFNeMC6QgijlVWskBrFXz0eOd/Q=; b=BGFqCzRaC7G92SHq1Uwz/dFCakQec618k7jM8wGMYxVE1yEgI5djaCDxUuN3iDSm4O fRUJKkMtAyvkPf9iStM7zNZa9OR9Wwkkso9j10OSp95bJ51nX6xTx5RV9gQsUO98UrAA vo4lnOMvtk0+GoVK22nl0odKm/+a2GmcZXTYPsaPO6E4VPhANdoOjw+lhOFU5dzds7KQ 8COVAfYWC8NAYx3kMikB49z1jLToqFwM9xokbMt65GZaKNJLMeSM6QftnAkd/wY+zbol /XeDP9ljlqQ0cKm5utfsmwoosoPIJ847Bnx4XwdMmFVmcJZKcFs7KyMOZsWeR10PU1eN hVqw==
MIME-Version: 1.0
X-Received: by 10.107.135.218 with SMTP id r87mr25983005ioi.153.1444011556401; Sun, 04 Oct 2015 19:19:16 -0700 (PDT)
Received: by 10.36.123.131 with HTTP; Sun, 4 Oct 2015 19:19:16 -0700 (PDT)
In-Reply-To: <84faf2113b9946f79763886867d65925@ustx2ex-dag1mb3.msg.corp.akamai.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> <84faf2113b9946f79763886867d65925@ustx2ex-dag1mb3.msg.corp.akamai.com>
Date: Sun, 04 Oct 2015 22:19:16 -0400
Message-ID: <CAH8yC8=JcWo+4rtymKLCfs3aKFQmCc+C4jD0eb74jbfMLJFAaw@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/7rszzxFTYalRgBN56K-MYFkxTVo>
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: Mon, 05 Oct 2015 02:19:18 -0000

On Sun, Oct 4, 2015 at 9:28 PM, Salz, Rich <rsalz@akamai.com> wrote:
>> There are many lessons to be learned from this: that a bearer token that is
>> repeated many times is not a good idea; that the trust model in the web is
>> not great; but also that blindly compressing content with no regard to its
>> structure and sources is dangerous and reveals information about the
>> cleartext.  A security protocol should not do that.
>
> This is a great note, and excellent explanation.

I'm not sure about some of it (I'm not trying to be argumentative).

If compression leaks information from a structured message, then
surely an uncompressed message leaks the same information. As Kurt
eloquently put it, only the density of the information changed.
Naively, that means the encryption services are defective, and not
compression.

Or maybe I should back pedal and ask: when is it safe to use TLS with
a structured message? Is it safe to use with HTTP? How about SMTP? If
HTTP always sends the cookie in the same position in unique messages,
then wouldn't that mean its not safe to use with HTTP over TLS?

Perhaps I'm missing something obvious....

Jeff

v2.23.0 | Report a Bug | By Email