IETF Logo Mail Archive

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

"Sheehe, Charles J. (GRC-LCA0)" <charles.j.sheehe@nasa.gov> Mon, 20 March 2017 12:01 UTC

Return-Path: <charles.j.sheehe@nasa.gov>
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 F059012F28B for <tls@ietfa.amsl.com>; Mon, 20 Mar 2017 05:01:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nasa.gov
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 HvFINkpF2BO9 for <tls@ietfa.amsl.com>; Mon, 20 Mar 2017 05:00:58 -0700 (PDT)
Received: from ndjsvnpf101.ndc.nasa.gov (NDJSVNPF101.ndc.nasa.gov [198.117.1.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB58412F280 for <tls@ietf.org>; Mon, 20 Mar 2017 05:00:58 -0700 (PDT)
X-Comment: SPF check N/A for local connections - client-ip=198.117.1.197; helo=ndjsppt103.ndc.nasa.gov; envelope-from=charles.j.sheehe@nasa.gov; receiver=tls@ietf.org
DKIM-Filter: OpenDKIM Filter v2.11.0 ndjsvnpf101.ndc.nasa.gov B66474006E6D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nasa.gov; s=letsgomars; t=1490011257; bh=ZnBHjymRPHbuDcGQXXxGVqj+l/34JOdM+sl4BmiSd6A=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ZKDkK7k/82+arp7PxTJDmV/bewfGHA3EWRwql+2pvgeGA+ZwrfrZcJtGPu7vG1Z5p YDtpgefv3e+3d+A2bgjgdasb7JtnWhD/f1IjppOnzorlkX34bWpup+8neWhED7/cRQ 5MeU800GjFW1iv4lNY/RXD218NJ03eSvoRRMae5jhyCNfTZTad3KfEZZ6VrIVWPiCO jmCwzJ3RMJvkmPE3gVZBAA6rIU6io/I1I3xyU14cVwrHz0Jnn5EX0MYMbeEp/ILu3J JZws4shnsFgT7g/TIy97ICwGzxzSWsgDBnJJqAT+awOnmhC3BWTHoYL+Q6bOnsG6j3 Mvp5MYzQLt+Kw==
Received: from ndjsppt103.ndc.nasa.gov (ndjsppt103.ndc.nasa.gov [198.117.1.197]) by ndjsvnpf101.ndc.nasa.gov (Postfix) with ESMTP id B66474006E6D; Mon, 20 Mar 2017 07:00:57 -0500 (CDT)
Received: from pps.filterd (ndjsppt103.ndc.nasa.gov [127.0.0.1]) by ndjsppt103.ndc.nasa.gov (8.16.0.20/8.16.0.20) with SMTP id v2KBqBDT004606; Mon, 20 Mar 2017 07:00:57 -0500
Received: from ndjscht114.ndc.nasa.gov (ndjscht114-pub.ndc.nasa.gov [198.117.1.214]) by ndjsppt103.ndc.nasa.gov with ESMTP id 29ad2ngcbt-1; Mon, 20 Mar 2017 07:00:57 -0500
Received: from NDJSMBX202.ndc.nasa.gov ([169.254.3.32]) by NDJSCHT114.ndc.nasa.gov ([198.117.1.184]) with mapi id 14.03.0319.002; Mon, 20 Mar 2017 07:00:56 -0500
From: "Sheehe, Charles J. (GRC-LCA0)" <charles.j.sheehe@nasa.gov>
To: Nitin Shrivastav <nitin.shrivastav@broadcom.com>, Yoav Nir <ynir.ietf@gmail.com>
CC: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] RFC 6066 - Max fragment length negotiation
Thread-Index: AQHSnpUQvyj8RgnlZ0qnQayWaIb/O6GYRB8AgAABEYCABWAb4A==
Date: Mon, 20 Mar 2017 12:00:56 +0000
Message-ID: <2D5292B061A3D547B3D87C3841793B300BE94389@NDJSMBX202.ndc.nasa.gov>
References: <CAD8WAomJLs4hdaso9hT036=UORjT9=H5-oCHbdSofuv++n3rYg@mail.gmail.com> <65683BD2-FED2-4953-AA48-92E262F06650@gmail.com> <CAD8WAomFPpSKLHK9ZFs1Z-3hdcpkAUiAwnNstSW4rgcAUgHNpA@mail.gmail.com>
In-Reply-To: <CAD8WAomFPpSKLHK9ZFs1Z-3hdcpkAUiAwnNstSW4rgcAUgHNpA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [139.88.44.182]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-20_09:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/lCv_iVJV_3p1PHRBWNNyoD9ypqQ>
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: Mon, 20 Mar 2017 12:01:01 -0000

Hi

I agree that this would be a benefit to bandwidth restricted channels as well.

Thanks
Chuck  

Charles J. Sheehe III
Electronics Engineer
Glenn Research Center
21000 Brookpark Rd
Cleveland, OH 44135
Charles.J.Sheehe@NASA.GOV
Office: 216-433-5179

"Science is the belief in the ignorance of the experts" – Richard Feynman
What you do makes a difference and you have to decide what kind of difference you want to make.



-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Nitin Shrivastav
Sent: Thursday, March 16, 2017 4:53 PM
To: Yoav Nir <ynir.ietf@gmail.com>
Cc: tls@ietf.org
Subject: Re: [TLS] RFC 6066 - Max fragment length negotiation

Thanks Yoav. I am assuming it is true for TLS1.2 also?

It would be nice to provide a mechanism for servers to do this as we are trying to run a web server in a constrained IoT end-points with only tens of KBytes of RAM and SSL/TLS based connection is important..

On Thu, Mar 16, 2017 at 4:48 PM, Yoav Nir <ynir.ietf@gmail.com <mailto:ynir.ietf@gmail.com> > wrote:


	Hi, Nitin.

	In section 7.4.1.4 of RFC 5246 it says:

	   An extension type MUST NOT appear in the ServerHello unless the same
	   extension type appeared in the corresponding ClientHello.

	So the answer is no. Only the client may request this.

	Yoav


		On 16 Mar 2017, at 21:12, Nitin Shrivastav <nitin.shrivastav@broadcom.com <mailto:nitin.shrivastav@broadcom.com> > wrote:

		Hello,

		This is Nitin Shrivastav, Engineering Manager at Broadcom. I have a question on RFC 6066 Maximum Fragment Length Negotiation section 
		
		
		The question i have is whether it is possible for a server to initiate the Max fragment length negotiation. The RFC describes a scenario where a constrained client can initiate this but in our product the server is very tightly constrained on memory and we want to reduce the memory used for SSL connections by forcing the clients to use reduce fragment length. We don't have control over the clients in our scenario which are basically the browsers like Chrome, IE etc.
		
		
		Thanks,
		Nitin
		_______________________________________________
		TLS mailing list
		TLS@ietf.org <mailto:TLS@ietf.org> 
		https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>

v2.23.0 | Report a Bug | By Email