IETF Logo Mail Archive

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

Yoav Nir <ynir.ietf@gmail.com> Thu, 16 March 2017 20:49 UTC

Return-Path: <ynir.ietf@gmail.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 918C8129A67 for <tls@ietfa.amsl.com>; Thu, 16 Mar 2017 13:49:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 VzM0nlv-tIU6 for <tls@ietfa.amsl.com>; Thu, 16 Mar 2017 13:49:04 -0700 (PDT)
Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0925129A6C for <tls@ietf.org>; Thu, 16 Mar 2017 13:49:03 -0700 (PDT)
Received: by mail-wm0-x241.google.com with SMTP id u132so308098wmg.1 for <tls@ietf.org>; Thu, 16 Mar 2017 13:49:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=D/iesGjRNKcO7kaHx7eEee81c4GPlHEkZ2qHqGX2XmQ=; b=cmgH7qIktPG4lexE8xxkfswVs04gE4P6Jm84S91exm1mW4Jcyoxq1dhFqPkzu29d+V Phs5gYilgxKxXBc+p6W+Y1azTemaMZ7ocr9oCiaORLDT7J1QnWBqKx3xQChBtxrv77zF TDtuHCvqByAQq71jLvTYFBif2gagvlkf20F6AzgjgkbmHzR06GxP3GIeFGi/OvByg2tI OSK4OV414ar8VBqtQz76CwiiDePU5uRlb2GDAlCn0i2NzOK3PcIwcA+e6IbDythjGN10 KUdC53u8kJVhxA1jzrT1cuskZdEjDOg5UDZTnaJswlPLm1ExLdgv6TKzmfzx8Rr4SDpV shEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=D/iesGjRNKcO7kaHx7eEee81c4GPlHEkZ2qHqGX2XmQ=; b=myJG+3UupuFOel0kEmKk9nftYh1Gy7OKrOnpp1LBc6QRkXSMTzb9FEERB7hsk5bdjB LrOThUsbMlWeszVp3CiVgHrqvCiHt38Ie2AoycA4fFgB9lzhaDpLrgZAovQ6mZjn7Kv1 WNNmsxaqvBLAtKnqQ97rb/Fadd/BbJQ2Nkho7VIW9eMj7CjQ5LeCaiJlplgxq1HEpcHq hJsj9lIacu3pj8YjDIZ6xzKW9bwlx+ATMOVnrAIO5U3PjgywoLJ9VHmu6MQ83TKAzjBu 3tYyM1+FmL+jbPTNFjeDOBcJXCN68AA/3CkeD58aV3+gIVbUuMIpBsVd59Qpy8irYdrC 3PQA==
X-Gm-Message-State: AFeK/H169LjaRjyLfKrtdzxJfJMB8nK1X8d0C8WCNNpnmwhPl6XTLbeT25K1D5PTAL0Dug==
X-Received: by 10.28.147.129 with SMTP id v123mr11218329wmd.51.1489697342236; Thu, 16 Mar 2017 13:49:02 -0700 (PDT)
Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id d6sm200511wmd.6.2017.03.16.13.49.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 13:49:01 -0700 (PDT)
From: Yoav Nir <ynir.ietf@gmail.com>
Message-Id: <65683BD2-FED2-4953-AA48-92E262F06650@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_F7362D6C-DDD6-484B-86FB-BCE5B4926760"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Thu, 16 Mar 2017 22:48:58 +0200
In-Reply-To: <CAD8WAomJLs4hdaso9hT036=UORjT9=H5-oCHbdSofuv++n3rYg@mail.gmail.com>
Cc: tls@ietf.org
To: Nitin Shrivastav <nitin.shrivastav@broadcom.com>
References: <CAD8WAomJLs4hdaso9hT036=UORjT9=H5-oCHbdSofuv++n3rYg@mail.gmail.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/qp9O6hVSIt2dTbU0Az4X2kGG6vw>
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: Thu, 16 Mar 2017 20:49:06 -0000

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> 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
> https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email