IETF Logo Mail Archive

Re: [TLS] Maximum Fragment Length negotiation

Hubert Kario <hkario@redhat.com> Wed, 30 November 2016 13:25 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 585A812987B for <tls@ietfa.amsl.com>; Wed, 30 Nov 2016 05:25:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.399
X-Spam-Level:
X-Spam-Status: No, score=-8.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, 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 L8LC36YO7_Oi for <tls@ietfa.amsl.com>; Wed, 30 Nov 2016 05:25:43 -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 F3F2812989B for <tls@ietf.org>; Wed, 30 Nov 2016 05:22:25 -0800 (PST)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (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 902A431B32C; Wed, 30 Nov 2016 13:22:25 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAUDMNsS027194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 30 Nov 2016 08:22:25 -0500
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Wed, 30 Nov 2016 14:22:17 +0100
Message-ID: <2592774.mFcuq1jeh1@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: <CABkgnnXMN5ayBVXQfFqkPJ+k8a4faSe2cCn-Qw4Azbu3SFpFaA@mail.gmail.com>
References: <20161124195002.GA32346@bolet.org> <20161129185451.GA4541@bolet.org> <CABkgnnXMN5ayBVXQfFqkPJ+k8a4faSe2cCn-Qw4Azbu3SFpFaA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2930380.bCDdgpxlce"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 30 Nov 2016 13:22:25 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/mbUUQIJF0dqQ8QeYDGDJfwFhy3k>
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: Wed, 30 Nov 2016 13:25:44 -0000

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

v2.23.0 | Report a Bug | By Email