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

Nikos Mavrogiannopoulos <nmav@redhat.com> Thu, 24 September 2015 12:04 UTC

Return-Path: <nmav@redhat.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 19A251A90A0 for <tls@ietfa.amsl.com>; Thu, 24 Sep 2015 05:04:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 jTM1tqk9ZFIq for <tls@ietfa.amsl.com>; Thu, 24 Sep 2015 05:04:03 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 199761A9096 for <tls@ietf.org>; Thu, 24 Sep 2015 05:04:03 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id D88D6C0798E8; Thu, 24 Sep 2015 12:04:02 +0000 (UTC)
Received: from dhcp-10-40-3-77.brq.redhat.com (dhcp-10-40-3-77.brq.redhat.com [10.40.3.77]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8OC40QY008971 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 24 Sep 2015 08:04:02 -0400
Message-ID: <1443096240.20825.9.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Date: Thu, 24 Sep 2015 14:04:00 +0200
In-Reply-To: <D616F41E-3D87-4101-8B64-C2E1B6709B48@gmail.com>
References: <20150922132321.17789008.2591.24358@ll.mit.edu> <CAHOTMV+riEzyYQcDfh4mMRokivCD_6T=ErTKF+BP41xABWEG8A@mail.gmail.com> <56019B0F.3020208@trigofacile.com> <201509221423.38061.davemgarrett@gmail.com> <56019FEE.5010008@trigofacile.com> <a3e83d0bbb994343b6715c958422438f@ustx2ex-dag1mb1.msg.corp.akamai.com> <92D67610-81FD-4515-AFE6-910E8B4E0F44@gmail.com> <CAH8yC8n-mda=axRTR79RYKVBf63cLtoDP6u6uQPqCqBHqZFENg@mail.gmail.com> <D616F41E-3D87-4101-8B64-C2E1B6709B48@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/p4Esis0nEl1_1GGnxFLh2vI-L08>
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: Thu, 24 Sep 2015 12:04:04 -0000

On Thu, 2015-09-24 at 10:52 +0300, Yoav Nir wrote:

> > On other lists I still see the occasional quip about suffering a
> > low
> > bandwidth connection. It used to be folks in some European
> > countries,
> > but most recently I seem to recall South American. (I think we're
> > seeing the shift because South American countries are going places
> > American and Europeans have already been with respect to
> > infrastructure).
> 
> At some point the countries with the least developed infrastructure
> eventually go through some government-led project to improve
> infrastructure, and that makes them leapfrog most other countries
> just because all their infrastructure is suddenly new. It happened in
> South Korea 15 years ago, and it’s happening in many African
> countries now. I don’t think we should burden a security protocol
> with a problematic mode based on a perceived need that might
> evaporate in a couple of years. Deploying high bandwidth is even
> faster now that you can make the last mile wireless rather than
> running copper or fiber to individual homes.

That only works if you think the browser over the internet usage of
TLS. TLS as used in the "Internet of Things" applications, is going to
be deployed in many low bandwidth scenarios.

regards,
Nikos