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

Karthikeyan Bhargavan <karthik.bhargavan@gmail.com> Sun, 20 September 2015 12:26 UTC

Return-Path: <karthik.bhargavan@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 A45171B4D35 for <tls@ietfa.amsl.com>; Sun, 20 Sep 2015 05:26:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
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 x7vim-ht1dwK for <tls@ietfa.amsl.com>; Sun, 20 Sep 2015 05:26:16 -0700 (PDT)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (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 D1EED1B4D34 for <tls@ietf.org>; Sun, 20 Sep 2015 05:26:15 -0700 (PDT)
Received: by wiclk2 with SMTP id lk2so113465116wic.0 for <tls@ietf.org>; Sun, 20 Sep 2015 05:26:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kZrvtelGYq9mhvqpbbmL7gUyX5zjOnbAGeD3Ng8suwc=; b=QwdqET4J1Agh6/6tGBZh48fJnMacrm0MQmB7ukLaAjf4hUD8ZeStA8z6PyrlbOW7Ap ItqiTgJpg0asWoEcm7V6QBUkkZ48RAF+jNY2fXKHxrv5M9Hdw+eKUsx4LYchOx7bl6bT EBz+dtB2dlpo5icb+a200n1BuvpUXJLzoZ2cZx7I1V/cY2d5oTETfoPdmx9QuQsvoxLZ dr8utk6U4wAZ8rkxdd746TcDn5fDnM7WROFG/lrF7yNYMBuqhvvyeHYfPXWvKvFdey9p QgnaCVW1Z0cN87nNJwrJGvyzkEFk+8XNuqyaA5fSgJQ6RuU7SgWdYWSSNnd/7Dtl7Pcu OVbQ==
X-Received: by 10.194.121.100 with SMTP id lj4mr17299058wjb.104.1442751974286; Sun, 20 Sep 2015 05:26:14 -0700 (PDT)
Received: from [192.168.0.12] (89-156-8-219.rev.numericable.fr. [89.156.8.219]) by smtp.gmail.com with ESMTPSA id hx4sm3428665wjb.31.2015.09.20.05.26.12 (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Sep 2015 05:26:13 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>
In-Reply-To: <55FEA206.3010504@trigofacile.com>
Date: Sun, 20 Sep 2015 14:26:11 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <A93EC035-A7D6-45E1-8931-74C96F44C854@gmail.com>
References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <55FC5822.5070709@trigofacile.com> <77583acbe981488493fd4f0110365dae@ustx2ex-dag1mb1.msg.corp.akamai.com> <55FC7343.3090301@trigofacile.com> <fa252c02f4504e5fb11cb95aa2701562@ustx2ex-dag1mb1.msg.corp.akamai.com> <55FE761B.803@trigofacile.com> <CACsn0cm4Lre7H8XLUVOPCFh7VAwBB+2wt89bDzTq1rYQmDd3Mw@mail.gmail.com> <55FEA206.3010504@trigofacile.com>
To: Julien ÉLIE <julien@trigofacile.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/6qhN9sRALWIib0CfP380VzFVkJs>
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, 20 Sep 2015 12:26:17 -0000

Julien,

It may well be true that some (typically unauthenticated) application protocols on top of TLS can survive TLS compression, 
but it is unlikely.  You ask a pointed question about AUTHINFO, so just as a fun game, let’s analyze its security:

AUTHINFO USER test
381 Enter password
AUTHINFO PASS test
281 Authentication succeeded

From a formal security viewpoint, the logic behind disabling compression in this exchange is as follows.
TLS does not hide the length of plaintext, so an 8-character password  is distinguishable from a 4-character one.
While this loss of confidentiality may arguably be expected and acceptable, compression makes it worse.

Consider the two lines:
AUTHINFO PASS AAAAAAAA
AUTHINFO PASS 12345678

Both passwords have 8 characters, and so when no compression is used, a passive network adversary cannot distinguish between them.
However, if they are compressed with gzip, the first results in 7 fewer bytes than the second. 
So compression of this line already yields 3 bits of the password to a passive adversary.
No online attack needed so far.

Suppose, the client also uses this password with a different command (e.g. XSECRET).

XSECRET test AAAAAAAA
XSECRET test 12345678

Now looking at the compressed lengths of this, the passive attacker can get another 3 bits. Considering that the average password entropy can be as low as 20 bits [1], the attacker now has a significant headstart on any other attack she may wish to pursue. 

HTTP is a particularly bad case because the attacker can potentially inject arbitrary data before (and after) the secret. With NNTP you may escape the worst of this adversary, but you probably won’t find any TLS expert willing to say that compressing the password is ok.

Best,
Karthik

[1] http://www.jbonneau.com/doc/B12-IEEESP-analyzing_70M_anonymized_passwords.pdf


> On 20 Sep 2015, at 14:09, Julien ÉLIE <julien@trigofacile.com> wrote:
> 
> Hi Watson,
> 
>>> Though I've read a few pages explaining how CRIME and BEAST attacks work, I
>>> still do not see well how TLS-level compression would make NNTP vulnerable.
>>> Same thing for POP or IMAP I believe.
>>> 
>>> The news server does not leak information.  The responses are just OK or KO.
>> 
>> This analysis would predict that HTTP isn't vulnerable.
> 
> I don't understand that point for AUTHINFO.
> NNTP only answers "281 Authentication succeeded" or "481 Authentication failed" here, whereas HTTP response bodies are far more complex and part of the request may be reflected in the response.
> 
> -- 
> Julien ÉLIE
> 
> « Etna : lave dévalante. »
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls