Re: [TLS] Maximum Fragment Length negotiation
Hubert Kario <hkario@redhat.com> Thu, 01 December 2016 11:48 UTC
Return-Path: <hkario@redhat.com>
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 BA80212963B for <tls@ietfa.amsl.com>; Thu, 1 Dec 2016 03:48:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.818
X-Spam-Level:
X-Spam-Status: No, score=-9.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 cqJyZNVdYpdj for <tls@ietfa.amsl.com>; Thu, 1 Dec 2016 03:46:10 -0800 (PST)
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 244A612963A for <tls@ietf.org>; Thu, 1 Dec 2016 03:46:10 -0800 (PST)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B3562C04D2A4; Thu, 1 Dec 2016 11:46:09 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (ovpn-204-97.brq.redhat.com [10.40.204.97]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB1Bk8cm029442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 1 Dec 2016 06:46:09 -0500
From: Hubert Kario <hkario@redhat.com>
To: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 01 Dec 2016 12:46:07 +0100
Message-ID: <2548632.5mfjX3JiUz@pintsize.usersys.redhat.com>
User-Agent: KMail/5.3.2 (Linux/4.8.8-200.fc24.x86_64; KDE/5.27.0; x86_64; ; )
In-Reply-To: <CABkgnnWREnCNqRo4aHFBH4UUuMcpO7c-cJW4TMuFQfnNh6piCQ@mail.gmail.com>
References: <20161124195002.GA32346@bolet.org> <2592774.mFcuq1jeh1@pintsize.usersys.redhat.com> <CABkgnnWREnCNqRo4aHFBH4UUuMcpO7c-cJW4TMuFQfnNh6piCQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart9681735.o5vD7iRQfB"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Thu, 01 Dec 2016 11:46:09 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/tdYBmmKnUvjxYr_L7p85idiHnMg>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Maximum Fragment Length negotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 01 Dec 2016 11:48:45 -0000
On Thursday, 1 December 2016 09:43:54 CET Martin Thomson wrote: > Asking ALL TLS implementations to change to accommodate these things > is a pretty blunt instrument. I want to be sure that this is > necessary. (FWIW, I think that this is a reasonable request, I would > probably be OK with a smaller maximum by default even.) for receiving those messages you don't have to do anything above what the specification already requires for sending the implementations already have to be able to fragment their messages - the change is only to make the value that guards those sizes a variable instead of being hardcoded that leaves the matter of negotiation of the value itself - which, while it is yet another extension that needs to be supported, it is not exactly complex or that requires convoluted logic > On 1 December 2016 at 00:22, Hubert Kario <hkario@redhat.com> wrote: > > On Wednesday, 30 November 2016 11:20:01 CET Martin Thomson wrote: > >> On 30 November 2016 at 05:54, Thomas Pornin <pornin@bolet.org> wrote: > >> > Any comments? > >> > >> I'm ambivalent on this generally: though I think that the general > >> notion is OK, I'm not sure about the details. > >> > >> In particular, you need to be clearer in your motivations: the point > >> is to ensure that little things (really little things) can talk to any > >> other TLS implementation. That seems inherently good, but it might > >> pay to dig into that some more: why is that good? > > > > because if they can't use TLS, they will create a bespoke protocol, and > > those have a tendency of being completely broken, on conceptual level, > > let alone implementation > > > > combine it with the fact that "trusted network" doesn't exist any more and > > you end up with solutions that are insecure with nobody using them knows > > they are insecure, especially in IoT space > > -- > > Regards, > > Hubert Kario > > Senior Quality Engineer, QE BaseOS Security team > > Web: www.cz.redhat.com > > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
- [TLS] Maximum Fragment Length negotiation Thomas Pornin
- Re: [TLS] Maximum Fragment Length negotiation Fossati, Thomas (Nokia - GB)
- Re: [TLS] Maximum Fragment Length negotiation Hannes Tschofenig
- Re: [TLS] Maximum Fragment Length negotiation Michael Tuexen
- Re: [TLS] Maximum Fragment Length negotiation Thomas Pornin
- Re: [TLS] Maximum Fragment Length negotiation Martin Thomson
- Re: [TLS] Maximum Fragment Length negotiation Raja ashok
- Re: [TLS] Maximum Fragment Length negotiation Hubert Kario
- Re: [TLS] Maximum Fragment Length negotiation Martin Thomson
- Re: [TLS] Maximum Fragment Length negotiation Hubert Kario