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

Viktor Dukhovni <ietf-dane@dukhovni.org> Sun, 20 September 2015 13:30 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 8902F1B4F24 for <tls@ietfa.amsl.com>; Sun, 20 Sep 2015 06:30:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 rfh0dNXU8iwS for <tls@ietfa.amsl.com>; Sun, 20 Sep 2015 06:30:19 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 530031B4F23 for <tls@ietf.org>; Sun, 20 Sep 2015 06:30:19 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 35A34283048; Sun, 20 Sep 2015 13:30:18 +0000 (UTC)
Date: Sun, 20 Sep 2015 13:30:18 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150920133017.GW21942@mournblade.imrryr.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <55FE761B.803@trigofacile.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Q57psUHfCeenG2GcO4eGkBSEGJE>
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: tls@ietf.org
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 13:30:20 -0000

On Sun, Sep 20, 2015 at 11:02:19AM +0200, Julien ÉLIE wrote:

> 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.
> For instance:
> 
> AUTHINFO USER test
> 381 Enter password
> AUTHINFO PASS test
> 281 Authentication succeeded
> 
> or in the case of an authentication failure:
> 
> AUTHINFO USER test
> 381 Enter password
> AUTHINFO PASS badpassword
> 481 Authentication failed
> 
> 
> 
> How compression would make NNTP weaker?
> (Brute-force attack is still necessary, even with compression enabled.)

Consider what happens when data that follows authentication (in
sunsequent message bodies) either does or does not match some part
of the password...

-- 
	Viktor.