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

takamichi saito <tan1tan2tan3tan4@gmail.com> Sat, 03 October 2015 02:51 UTC

Return-Path: <tan1tan2tan3tan4@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 352371A9308 for <tls@ietfa.amsl.com>; Fri, 2 Oct 2015 19:51:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 jt2pO089LGu8 for <tls@ietfa.amsl.com>; Fri, 2 Oct 2015 19:51:03 -0700 (PDT)
Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (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 858B21A9300 for <tls@ietf.org>; Fri, 2 Oct 2015 19:51:03 -0700 (PDT)
Received: by padhy16 with SMTP id hy16so122109709pad.1 for <tls@ietf.org>; Fri, 02 Oct 2015 19:51:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:references:in-reply-to:to; bh=4yGI3M0z732+a9J3ubM8RvJ0FyLTDozzBUrydUTRuHM=; b=ePRPXexK5l9htKjxLyVZnhupMqe/UzZfyeBkyHDADovg5lvSHuJ2dqfOOswWSBxTTB eq8KCTiThn78PumUtp3U0nxnmNKDJepdnjfXVeWhZKFR1dq4eRdT2DXwdd2bGa94/Vqc WWu4M7bpwlX02V2W5DA1+S2hTfLZGaYhK79VKr2xoLhfL1rPbj503OUsawlXlZh036Rs m93ry6pKG3rLEi6I/VjtB0n8Y4yweV3+8aGPyZy/ojR7gcm/eISNwR816nXPCqtVEDY3 5OOy7LiaNemdPeoqYRzLCE1runEY0c7b4QdiaeF3UJFGw3rP1l2zi98GuBIqzcpkuuw7 mupg==
X-Received: by 10.68.243.99 with SMTP id wx3mr23981084pbc.33.1443840663184; Fri, 02 Oct 2015 19:51:03 -0700 (PDT)
Received: from [10.12.142.197] (s1402242.xgsspn.imtp.tachikawa.spmode.ne.jp. [1.75.2.242]) by smtp.gmail.com with ESMTPSA id ll9sm14433424pbc.42.2015.10.02.19.51.02 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Oct 2015 19:51:02 -0700 (PDT)
From: takamichi saito <tan1tan2tan3tan4@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail-22448A29-5EF4-4CBF-9009-7B55BCA9DDB0"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Message-Id: <CA865FAC-4FF8-4BE0-A7F8-84FA84EBFE46@gmail.com>
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> <560E8DA8.8020903@zinks.de>
In-Reply-To: <560E8DA8.8020903@zinks.de>
To: "tls@ietf.org" <tls@ietf.org>
X-Mailer: iPhone Mail (12H143)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/AEEouevupsGfFnFCxmwi_va6_4E>
X-Mailman-Approved-At: Sun, 01 Nov 2015 16:50:37 -0800
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>
Date: Sat, 03 Oct 2015 02:51:05 -0000
X-Original-Date: Sat, 3 Oct 2015 11:51:00 +0900
X-List-Received-Date: Sat, 03 Oct 2015 02:51:05 -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.
> 

I see, 
but contrary,
tls is only for browser? 

And more, 
if you kick out comp/decomp from tls,
can we be safer when we use tls?
If you know the paper, please teach me.

Or, rfc or good teacher should notify us,
"When you use TLSv1.3, you never use compression, sorry!"
I know it may be out scope, 
but we have to estimate the risk.

regards,


> 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
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

;; takamixhi saito
c2xhYWlidHNvcw