IETF Logo Mail Archive

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

Yoav Nir <ynir.ietf@gmail.com> Thu, 16 March 2017 21:00 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 85B09129A83 for <tls@ietfa.amsl.com>; Thu, 16 Mar 2017 14:00:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, 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 CU6zGMAlkVP0 for <tls@ietfa.amsl.com>; Thu, 16 Mar 2017 13:59:59 -0700 (PDT)
Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 7837B129A89 for <tls@ietf.org>; Thu, 16 Mar 2017 13:59:59 -0700 (PDT)
Received: by mail-wm0-x242.google.com with SMTP id n11so353024wma.0 for <tls@ietf.org>; Thu, 16 Mar 2017 13:59:59 -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=xkXlD5GJnvv4fICzcGRfXd3azO5+KUkFzFWkAid0mTQ=; b=o+Qem3FFb0k/F2nNa9581nBhU7jXsXI53+0JnVU7hgrUG3y8K7ArerAn+EDaP11aXV JXBetvZ6VSnhCE+0Ttwv6q/p+dKKmGoE8HWNDv/fh0pNfYLl37CbpEo1U4TVb91S8EXg FnvZZ/2Uw+WnMOMGV89oZsDa/VinzPkUfLwHW8HwkfgHGrzbuM9vrHrm2ahu3uGs4oOB O3PlLVN1v4Y3aFbw+H1KFO+pBufeD3+nU5Q+d8xr/SMBy0pQpCsb+0dudDJDwHgc16L9 mpjixoD3MOyhuzTS0KmcC5E+yG9hIlbfrxSGZ3isigmJb0luiikwxV3B2x1snYom3358 HKgQ==
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=xkXlD5GJnvv4fICzcGRfXd3azO5+KUkFzFWkAid0mTQ=; b=J1BnEiZhqiD6Hb5KWemJCxTLaOc3Tsb8Uvo6gQ46byc9MO3PlsDwFsb3dPxwX6Kpyj 2tC7zofQwL3whqC6bBx2hBX37f94JlbaHnABLHA5vKCVrJU264qxxGguSv3+26GYV0dR CjgIjNHbU6xzrqwMrDK9GrS7BaVrhASXGN/oxlIxYQekgngRobuwA84rtOey41HN9aHj BZUebohSC8cEP8UsHcXJNyPzQeKsvSgPX8JHc6O3fCtbDePODOZPIGKNbum410Yevu7u s3XWIc0IThtR/e0EjBNx2rR0KKRoWaSD3zDuB0VjNjOWJs8XF1M3aSwY9knNYhCuLF7S OHHQ==
X-Gm-Message-State: AFeK/H1PErAgMHQQ8wwdpj4i6VQv5Z/cWyrdy9obPoGr6Np0pGimm7ph9udWXx8E5syllA==
X-Received: by 10.28.158.148 with SMTP id h142mr6368548wme.36.1489697998011; Thu, 16 Mar 2017 13:59:58 -0700 (PDT)
Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id k139sm221342wmg.11.2017.03.16.13.59.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 13:59:57 -0700 (PDT)
From: Yoav Nir <ynir.ietf@gmail.com>
Message-Id: <C1F16A02-3BE9-48C1-9176-9B3929534770@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_CED555AE-A293-4364-8A6C-142D168A144C"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Thu, 16 Mar 2017 22:59:54 +0200
In-Reply-To: <CAD8WAomFPpSKLHK9ZFs1Z-3hdcpkAUiAwnNstSW4rgcAUgHNpA@mail.gmail.com>
Cc: tls@ietf.org
To: Nitin Shrivastav <nitin.shrivastav@broadcom.com>
References: <CAD8WAomJLs4hdaso9hT036=UORjT9=H5-oCHbdSofuv++n3rYg@mail.gmail.com> <65683BD2-FED2-4953-AA48-92E262F06650@gmail.com> <CAD8WAomFPpSKLHK9ZFs1Z-3hdcpkAUiAwnNstSW4rgcAUgHNpA@mail.gmail.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/kkfed2Qz9itk4kqpIjDCgUd_irA>
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 21:00:01 -0000

> 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 <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