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

Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr> Fri, 28 March 2014 06:49 UTC

Return-Path: <karthikeyan.bhargavan@inria.fr>
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 F08921A0800 for <tls@ietfa.amsl.com>; Thu, 27 Mar 2014 23:49:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.56
X-Spam-Level:
X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 Et17pcqkOviQ for <tls@ietfa.amsl.com>; Thu, 27 Mar 2014 23:49:03 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by ietfa.amsl.com (Postfix) with ESMTP id 33CB41A07FE for <tls@ietf.org>; Thu, 27 Mar 2014 23:49:03 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.97,749,1389740400"; d="asc'?scan'208"; a="65116879"
Received: from 147.47.192.77.rev.sfr.net (HELO [192.168.1.44]) ([77.192.47.147]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 28 Mar 2014 07:49:00 +0100
Content-Type: multipart/signed; boundary="Apple-Mail=_79BC9DA6-8794-418A-AAA3-15784FAC53CD"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr>
In-Reply-To: <f15dd559-d532-471b-a7a1-8fe17851d46e@email.android.com>
Date: Fri, 28 Mar 2014 07:48:59 +0100
Message-Id: <2CA33889-D7D3-4CA1-AC1D-6BF8B62592EB@inria.fr>
References: <DA7A3139-EE44-4FE2-B674-4ECAE4D51079@cisco.com> <f15dd559-d532-471b-a7a1-8fe17851d46e@email.android.com>
To: Alyssa Rowan <akr@akr.io>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IvquAs_DCFUpoPdCZx9afOIQUvQ
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: Fri, 28 Mar 2014 06:49:05 -0000

> Compression is usually best performed as "high" as possible; transport layer is blind to what's being compressed, which is (as we now know) was definitely too low and was in retrospect a mistake.

I agree.

In particular, note that TLS 1.2 compression is performed on a per-fragment basis, and hence it leaks even more fine-grained information about the plaintext than if the compression were performed for the whole stream in the application. 

For example, we implemented a traffic-analayzer for fingerprinting equal-length files over TLS-with-compression [1]. Each file resulted in about 150 fragments, and our goal was to identify the file by its compressed length.
With TLS compression, we could fingerprint the file within the first three fragments.With application-level compression we would have needed to calculate the length of the whole stream.


1: http://www.mitls.org/downloads/miTLS-report.pdf, Section 4.1


> 
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls