Re: [TLS] RFC 6066 - Max fragment length negotiation

Peter Gutmann <pgut001@cs.auckland.ac.nz> Wed, 22 March 2017 02:55 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD9212702E for <tls@ietfa.amsl.com>; Tue, 21 Mar 2017 19:55:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
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 nYCmmZSX6yEd for <tls@ietfa.amsl.com>; Tue, 21 Mar 2017 19:55:33 -0700 (PDT)
Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DC4E129435 for <tls@ietf.org>; Tue, 21 Mar 2017 19:55:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1490151332; x=1521687332; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=rbYuADkBr6uFhYbvoetyvZkzPw3nbIxwS3IY3H/n+Mk=; b=j/DyLD97ic+VRbOYA1diMwG84Scu0UyTruwMJEIpfT0F0EiGBahYd8Jw 76yzli0YNaZ7APxDy5WyIRMRtwcEPcx2rNnsd6RzxhD53oM90JKiCnovR r8LpXF1zj+LvkeFc0PPNXp5qyK6U+fFo0CF9nuaZeLH2R/TvjEmTK9kmD bI7QRpNGKMpttAXoXv44va9S8HTiLhiiJXoY1s11VBc8VMxRGevNzc6/r 4G8UTn1DP/iBpTA0R82HnBhxF+Tx6RA+JXxAj/WW9SfLjRPv2l4+YG6bl EIBe30PcOIBshtZDPDT8dTxyZe7IVshDMLNhlMpcOFMWPMwI5bMNYZnhf A==;
X-IronPort-AV: E=Sophos;i="5.36,202,1486378800"; d="scan'208";a="144659088"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing
Received: from uxcn13-tdc-e.uoa.auckland.ac.nz ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 22 Mar 2017 15:55:30 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.9) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 22 Mar 2017 15:55:30 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Wed, 22 Mar 2017 15:55:30 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Thomas Pornin <pornin@bolet.org>, Ilari Liusvaara <ilariliusvaara@welho.com>
CC: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] RFC 6066 - Max fragment length negotiation
Thread-Index: AQHSnpUB8UgZsR1fnUWlpN1q8vk4DKGYGe7w//8q+oCAANxgO///LA8AgADcRWz//0AsAAAe+X57//8qVYCAACsrgIABIKju//8rnQCAAOBv1///S1IAgAAT2wCAAA7cgIAH4B0L
Date: Wed, 22 Mar 2017 02:55:29 +0000
Message-ID: <1490151325506.25280@cs.auckland.ac.nz>
References: <1489710142144.88978@cs.auckland.ac.nz> <CABkgnnXiB5ksGbbPqDP3D=FVdQu9ht0vD8-T-5HTaEKQQE4+9w@mail.gmail.com> <1489721710740.52293@cs.auckland.ac.nz> <CABkgnnWq_5e8TJgJV+okqi6vo-_5=811pOZRtUCp0TD07SmNoQ@mail.gmail.com> <CABkgnnW=Pz+6M8UYoB+MTY8rQp9vsHyh6aqiSb3EbTT_BdWokA@mail.gmail.com> <1489747107536.25854@cs.auckland.ac.nz> <CABkgnnUqHvc6zOL1SYP8FwBcF7SeMnnT-PJOwhMB1qqeDAcp9w@mail.gmail.com> <1489749662616.94542@cs.auckland.ac.nz> <20170317133344.GA20310@bolet.org> <20170317144448.GB26550@LK-Perkele-V2.elisa-laajakaista.fi>, <20170317153759.GA22929@bolet.org>
In-Reply-To: <20170317153759.GA22929@bolet.org>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/MLVra4Gp0l6cZVpoVvqYuRkSiFs>
Subject: Re: [TLS] RFC 6066 - Max fragment length negotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 22 Mar 2017 02:55:35 -0000

Thomas Pornin <pornin@bolet.org> writes:

>TLS 1.3 is moving away from the IoT/embedded world, and more toward a Web
>world. This is not necessarily _bad_, but it is likely to leave some people
>unsatisfied (and, in practice, people clinging to TLS 1.2).

I would go slightly further and say that TLS 1.3 could end up forking TLS in
the same way that HTTP/2 has forked HTTP.  There's HTTP/2 for web content
providers and HTTP 1.1 for the rest of us/them (depending on your point of
view).  Similarly, there are sizeable groups of users who will take a decade
or more to get to TLS 1.3 (they're still years away from 1.2 at the moment),
or who may never move to TLS 1.3 because too much of their existing
infrastructure is dependent on how TLS 1.x, x = 0...2, works.  So as with
HTTP/2 we may end up with TLS 1.3 for web content providers and TLS 1.0/1.2
for everything else.

Peter.