IETF Logo Mail Archive

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

Roland Zink <roland@zinks.de> Fri, 02 October 2015 13:59 UTC

Return-Path: <roland@zinks.de>
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 A99E61A00BD for <tls@ietfa.amsl.com>; Fri, 2 Oct 2015 06:59:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35] 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 y_eBleerFrGj for <tls@ietfa.amsl.com>; Fri, 2 Oct 2015 06:59:06 -0700 (PDT)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::11]) (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 A5EB51A00B1 for <tls@ietf.org>; Fri, 2 Oct 2015 06:59:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1443794342; l=1612; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:References:To:Subject; bh=ijeaPpST6I/xbM3XREFjmU8GJDRpEQaK7Ni9KpBGLWI=; b=k4xra6mOOv8wyY1ih1fWRCuYvlbFAoeVqL+XCkjcpcjCUuBqHNYkTI7iz4QEpceGk6x bj3KTGfG8bR8HviEtPlkfNDUWhv+zFoorI6PQYqSYNSWCyaja/koGCb2EiBNZPpWYM6GR asJcwR79Wv3B6jAC0TF831OYqNbI6+IjQEM=
X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLyImrcrs/b6npEJc9Go+veNVQOkuw==
X-RZG-CLASS-ID: mo00
Received: from [IPv6:2001:4dd0:ff67:0:98b9:74fd:ff27:7ec7] ([2001:4dd0:ff67:0:98b9:74fd:ff27:7ec7]) by smtp.strato.de (RZmta 37.12 AUTH) with ESMTPSA id 6015a7r92Dx2vX7 (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for <tls@ietf.org>; Fri, 2 Oct 2015 15:59:02 +0200 (CEST)
To: tls@ietf.org
References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <55FC5822.5070709@trigofacile.com> <77583acbe981488493fd4f0110365dae@ustx2ex-dag1mb1.msg.corp.akamai.com> <55FC7343.3090301@trigofacile.com> <6796F70E-44FD-4CD8-A691-6D0BFAE6EFDC@cs.meiji.ac.jp>
From: Roland Zink <roland@zinks.de>
Message-ID: <560E8DA8.8020903@zinks.de>
Date: Fri, 02 Oct 2015 15:59:04 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <6796F70E-44FD-4CD8-A691-6D0BFAE6EFDC@cs.meiji.ac.jp>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/8Fl7dNGoH91q646F9uWX4lI5oVY>
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: Fri, 02 Oct 2015 13:59:07 -0000

Browsers are not a concern as they already have their own comp/decomp 
codes. HTTP/1 can compress content (Content-encoding and 
transfer-encoding) and HTTP2 has additional header compression.

Regards,
Roland


Am 02.10.2015 um 15:08 schrieb takamichi saito:
>> Do we know how many protocols currently suffer from CRIME?
>>
>>
>> Maybe a best practice could be suggested by UTA for the implementation of TLS in software, to disable compression if vulnerable.  And for the others, to implement a way to enable/disable compression in case one day a vulnerability is found.
> I agree.
>
> Again,
>
> 1) We know CRIME threat, but it can not be risk for everyone.
> e.g., CVSS v2 Base Score: 2.6 (LOW)
>
> 2) If we need to have comp/decomp in an application layer,
>   clients such like browser need their own comp/decomp codes.
>
> 3) If there is no comp in tls1.3, some people may continue to use tls1.2.
> Which one is safer, "tls1.2" v.s. "tls1.3 with comp/decomp" ?
>
> That's why we explore the way to keep compression in TLSv1.3.
> How about making an option only in server-side?
> The spec has the compression but default is off, and also provides the suggestion.
>
>
>> -- 
>> Julien ÉLIE
>>
>> « La vraie valeur d'un homme se mesure lorsqu'il a tout perdu. »
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
> ;; takamixhi saito
> c2xhYWlidHNvcw
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email