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

Nitin Shrivastav <nitin.shrivastav@broadcom.com> Fri, 17 March 2017 00:00 UTC

Return-Path: <nitin.shrivastav@broadcom.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 27B1D129B6F for <tls@ietfa.amsl.com>; Thu, 16 Mar 2017 17:00:07 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 (1024-bit key) header.d=broadcom.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 2w_4fSY1QKfF for <tls@ietfa.amsl.com>; Thu, 16 Mar 2017 17:00:05 -0700 (PDT)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 38B18129717 for <tls@ietf.org>; Thu, 16 Mar 2017 17:00:05 -0700 (PDT)
Received: by mail-it0-x233.google.com with SMTP id g138so7790664itb.0 for <tls@ietf.org>; Thu, 16 Mar 2017 17:00:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Fwt6qUKHBJ/4/z9m9uC0Fnf0ogeT5DjeMoa2KGpsmhc=; b=B9xtF0Yg0ZYvkC7mQuhEA0g9t06kU0+4GQbdBOm4jmVimA6qUHipoPlLgauA6bCK3J BvaIoaGbw/ZfGgITctiFQwUHcN2HqwOZuu6FzUkxgYOoFYXiQH9n8x2r7q/yuQwgyYm1 OqrGpJnKVo6xKNni111QCItec31GrhGkjleTU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Fwt6qUKHBJ/4/z9m9uC0Fnf0ogeT5DjeMoa2KGpsmhc=; b=Z3wIHvEkH+BrWHWw1wcWaS7fLihpATbvh+hcgA1unYTZ/kMFibuFuPUZ5MV9nSeiqF pDSyqu/JZhIwvTmzPfZy+fAVKoe8iUzf5F/xqO8G9EvfZKCcbd4iokPxMmnWTKW5XNII Z2xJGLVttHpuy/J3oYMbzMxsvTIQ3APNIWPikSNKywSFQ2/26PXM17xzwYcF9ivzY1bf Feb5STyFjDIlQQIFjaYIcL78Pk8N9eh0RhGQyCG6k4mU5bs5FXD5i6rqLeD25ktyBA/r xU9w13CeNAjO8AOrOCXA/xne03GoS5QLBiHboeEz/Fe8u79FSmEsCN4JeZo7iBK3qe3V 34lw==
X-Gm-Message-State: AFeK/H1s+rN5pcOXHBAQQ1ZxCEofNzbLaonKnITJQVp4uWnvbwTTXi0GqkigAl7yHWfVoocJ
X-Received: by 10.36.238.202 with SMTP id b193mr387000iti.39.1489708804528; Thu, 16 Mar 2017 17:00:04 -0700 (PDT)
Received: from ?IPv6:2602:304:cd81:1060:5849:6f84:6e28:92fb? ([2602:304:cd81:1060:5849:6f84:6e28:92fb]) by smtp.gmail.com with ESMTPSA id 78sm318383ity.7.2017.03.16.17.00.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 17:00:03 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-7563F123-1667-4D2E-8F4E-0178293CE5BF"
Mime-Version: 1.0 (1.0)
From: Nitin Shrivastav <nitin.shrivastav@broadcom.com>
X-Mailer: iPhone Mail (14D27)
In-Reply-To: <C1F16A02-3BE9-48C1-9176-9B3929534770@gmail.com>
Date: Thu, 16 Mar 2017 20:00:01 -0400
Cc: tls@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <F139CA6D-B33E-4A8E-97B7-A255EBB44215@broadcom.com>
References: <CAD8WAomJLs4hdaso9hT036=UORjT9=H5-oCHbdSofuv++n3rYg@mail.gmail.com> <65683BD2-FED2-4953-AA48-92E262F06650@gmail.com> <CAD8WAomFPpSKLHK9ZFs1Z-3hdcpkAUiAwnNstSW4rgcAUgHNpA@mail.gmail.com> <C1F16A02-3BE9-48C1-9176-9B3929534770@gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/zGl7JxgtPPvJgm733VpkiQF8FDQ>
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: Fri, 17 Mar 2017 00:00:07 -0000

Yoav

The constrained end point is server serving web pages to browsers. 

Nitin

> On Mar 16, 2017, at 4:59 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
> 
> 
>> On 16 Mar 2017, at 22:52, Nitin Shrivastav <nitin.shrivastav@broadcom.com> wrote:
>> 
>> Thanks Yoav. I am assuming it is true for TLS1.2 also?
> 
> RFC 5246 *is* TLS 1.2.  But it’s true for previous versions and for 1.3 as well.
>> 
>> 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..
> 
> I don’t get if you mean that the constrained end-point is the client or the server. But either way, both sides can be configured to use small records. You only really need this extension when you both have large amounts of data (so large records would be used without this extension) and the server is a generic web server that responds to both constrained and non-constrained devices. 
> 
> But even in that case, adding the extension to the ClientHello should not be infeasible.
> 
> Yoav
> 
>>> On Thu, Mar 16, 2017 at 4:48 PM, Yoav Nir <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> 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
>>> 
>> 
>