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