Re: [TLS] Maximum Fragment Length negotiation
Thomas Pornin <pornin@bolet.org> Tue, 29 November 2016 18:55 UTC
Return-Path: <pornin@bolet.org>
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 E5D60129C41 for <tls@ietfa.amsl.com>; Tue, 29 Nov 2016 10:55:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level:
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 unDVxcRsel7W for <tls@ietfa.amsl.com>; Tue, 29 Nov 2016 10:55:24 -0800 (PST)
Received: from brontes.bolet.org (brontes.bolet.org [62.210.214.227]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD3D8129C3D for <tls@ietf.org>; Tue, 29 Nov 2016 10:55:23 -0800 (PST)
Received: by brontes.bolet.org (Postfix, from userid 1000) id D89A02076D; Tue, 29 Nov 2016 19:54:51 +0100 (CET)
Date: Tue, 29 Nov 2016 19:54:51 +0100
From: Thomas Pornin <pornin@bolet.org>
To: "Fossati, Thomas (Nokia - GB)" <thomas.fossati@nokia.com>
Message-ID: <20161129185451.GA4541@bolet.org>
References: <20161124195002.GA32346@bolet.org> <D45D053C.76B0A%thomas.fossati@alcatel-lucent.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <D45D053C.76B0A%thomas.fossati@alcatel-lucent.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/3Fik3s3QnjN302erHYdGH8FRmkk>
Cc: "tls@ietf.org" <tls@ietf.org>
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: Tue, 29 Nov 2016 18:55:26 -0000
On Thu, Nov 24, 2016 at 09:10:00PM +0000, Fossati, Thomas (Nokia - GB) wrote: > I like your proposal, but I'm not convinced that overloading the > semantics of an already existing extension when used in combination > with a specific version of the protocol is necessarily the best > strategy. Besides, I'd like to be able to deploy a similar mechanism > in 1.2. Defining a new extension is certainly possible. However, it would then require deciding on the intended behaviour when both that new extension and the RFC 6066 extension are present. Tentatively, one could try this: - The new extension documents the maximum record length supported by whoever sends it. Encoding is as in RFC 6066: one byte of value x for a maximum record plaintext length of 2^(x+8) bytes). We extend that to the whole 1..8 range so that larger records may be used by implementations who can afford them and obtain some performance increase by doing so (actual maximum plaintext length will be slightly less than 65535 bytes becose the length header is 16-bit and there must be some room for the MAC). - If a client sends both the RFC 6066 extension and the new extension, and the server supports the new extension, then the RFC 6066 extension is ignored and only the new extension is used. A server MUST NOT send both extensions. - All implementations that support the extension MUST have the ability to apply a shorter size limit than their maximum limit (this is for _sending_ records). - The length sent by the server is the one that will be applied to subsequent records on the connection, in both directions. This applies to the whole connection, including subsequent handshakes (renegotiations), unless both client and server send the new extension again in a renegotiation (in which case the new length appplies). - If using TLS 1.3, then the following extra rules apply: - All TLS 1.3 implementations MUST support the extension. - If the client does not send the new extension, then this is equivalent to the client sending the new extension with a value of 6 (i.e. maximum plaintext length is 2^14 = 16384 bytes). In particular, this allows the server to send the extension. - If the server does not send the new extension, then this is equivalent to the server sending the new extension with the same value as the one from the client. (So, if neither sends the extension, then the usual 16384-byte limit applies.) - If using TLS 1.2 or a previous version, then there is no implicit usage: - The server MUST NOT send the new extension unless the client sent it. - The maximum plaintext limit shall be enforced only if the server sent the extension; that limit is the one defined by the server's extension. - If the client and/or the server does not send the extension, then the maximum plaintext length is the one that was in force at that point, i.e. 16384 bytes for a new connection, or whatever was used before the new handshake in case of renegotiation. Some noteworthy points: * TLS 1.3 has no renegotiation, so the renegotiation behaviour is for TLS 1.2 and previous. This avoids tricky issues with the TLS 1.3 implicit behaviour in case of renegotiation. * A client SHOULD send the new extension in all ClientHello if it is ready to use TLS 1.2 or previous, so that a non-1.3-aware server may have the possibility to negotiate a shorter maximum plaintext length. * The initial ClientHello may use records larger than what the server is willing to accept, and before the server has any chance to advertise its own maximum record size. However, since the initial records are unprotected, implementations may be able to process partial records, and thus could accept un-MACed records larger than their incoming buffer (at least BearSSL can do that). The "implicit" behaviour (both for client and server) with TLS 1.3 is a way to make the extension free (with regards to network usage) in the common case. It cannot be applied unless the extension support is made mandatory for TLS 1.3. Making it mandatory is also an important feature, since otherwise such an extension would likely remain unimplemented by "big" clients (e.g. Web browsers). Any comments? I can try to write the corresponding text for inclusion in the TLS 1.3 draft. What is the process for submitting such text? --Thomas Pornin
- [TLS] Maximum Fragment Length negotiation Thomas Pornin
- Re: [TLS] Maximum Fragment Length negotiation Fossati, Thomas (Nokia - GB)
- Re: [TLS] Maximum Fragment Length negotiation Hannes Tschofenig
- Re: [TLS] Maximum Fragment Length negotiation Michael Tuexen
- Re: [TLS] Maximum Fragment Length negotiation Thomas Pornin
- Re: [TLS] Maximum Fragment Length negotiation Martin Thomson
- Re: [TLS] Maximum Fragment Length negotiation Raja ashok
- Re: [TLS] Maximum Fragment Length negotiation Hubert Kario
- Re: [TLS] Maximum Fragment Length negotiation Martin Thomson
- Re: [TLS] Maximum Fragment Length negotiation Hubert Kario