IETF Logo Mail Archive

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

Simon Josefsson <simon@josefsson.org> Tue, 22 September 2015 08:06 UTC

Return-Path: <simon@josefsson.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 916FF1A0203 for <tls@ietfa.amsl.com>; Tue, 22 Sep 2015 01:06:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.251
X-Spam-Level:
X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 AkXFO2EG469j for <tls@ietfa.amsl.com>; Tue, 22 Sep 2015 01:06:36 -0700 (PDT)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51DE41A01F7 for <tls@ietf.org>; Tue, 22 Sep 2015 01:06:36 -0700 (PDT)
Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t8M86WnG007524 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 22 Sep 2015 10:06:33 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Julien ÉLIE <julien@trigofacile.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> <A93EC035-A7D6-45E1-8931-74C96F44C854@gmail.com> <55FEC8B0.9070904@trigofacile.com>
OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt
X-Hashcash: 1:22:150922:julien@trigofacile.com::mHUS4cmQr6rpkZ9U:8UZG
X-Hashcash: 1:22:150922:tls@ietf.org::I2l3q758S9LsaRLe:IKG3
Date: Tue, 22 Sep 2015 10:06:31 +0200
In-Reply-To: <55FEC8B0.9070904@trigofacile.com> ("Julien \=\?iso-8859-1\?Q\?\=C9LIE\=22's\?\= message of "Sun, 20 Sep 2015 16:54:40 +0200")
Message-ID: <87vbb23mk8.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/hSeqll7PubYA10nb-6DLN-dvpH4>
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: Tue, 22 Sep 2015 08:06:37 -0000

Julien ÉLIE <julien@trigofacile.com> writes:

> Hi Karthik,
>
>> It may well be true that some (typically unauthenticated) application
>> protocols on top of TLS can survive TLS compression, but it is
>> unlikely.
> [...]
>> 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.
>
> OK, many thanks for the illustration!
>
> So in fact, to be safer, authentication commands should either be sent
> uncompressed or be more complex than they currently are (for instance
> with the insertion of random data with random length along with the
> authentication command).

I believe the general recommendation is to not send passwords in
cleartext at all, even in encrypted tunnels.  I'm sure you are aware of
it, but you may SASL in NNTP as described in RFC 4643.

/Simon

v2.28.0 | Report a Bug | By Email | System Status