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

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Tue, 22 September 2015 13:23 UTC

Return-Path: <prvs=670795a046=uri@ll.mit.edu>
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 0856E1A702C for <tls@ietfa.amsl.com>; Tue, 22 Sep 2015 06:23:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.909
X-Spam-Level:
X-Spam-Status: No, score=-3.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 sHEFHENIQMeu for <tls@ietfa.amsl.com>; Tue, 22 Sep 2015 06:23:17 -0700 (PDT)
Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 192671A6FF1 for <tls@ietf.org>; Tue, 22 Sep 2015 06:23:16 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t8MDNFK4020617; Tue, 22 Sep 2015 09:23:15 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Simon Josefsson <simon@josefsson.org>, =?utf-8?B?SnVsaWVuIMOJTElF?= <julien@trigofacile.com>
Thread-Topic: [TLS] TLS 1.3 - Support for compression to be removed
Thread-Index: AdD1OdWFMSsZDobWPUarSzG2K9gkow==
Date: Tue, 22 Sep 2015 13:23:13 +0000
Message-ID: <20150922132321.17789008.2591.24358@ll.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============0854605015=="
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-09-22_04:2015-09-22,2015-09-22,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1508030000 definitions=main-1509220198
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ovHlNW_nBOKr4Cwr1iC5vDcr9vw>
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 13:23:19 -0000

Also, if compression is moved from TLS to upper layer(s) - how would it mitigate compression-related attacks? Besides "now it's somebody else's problem"?

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Simon Josefsson
Sent: Tuesday, September 22, 2015 04:07
To: Julien ÉLIE
Cc: tls@ietf.org
Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed

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