Re: [TLS] RFC 6066 - Max fragment length negotiation
Thomas Pornin <pornin@bolet.org> Fri, 17 March 2017 13:33 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 8878612943A for <tls@ietfa.amsl.com>; Fri, 17 Mar 2017 06:33:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 qER705OY5xvr for <tls@ietfa.amsl.com>; Fri, 17 Mar 2017 06:33:14 -0700 (PDT)
Received: from brontes.bolet.org (www.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 F1C03129421 for <tls@ietf.org>; Fri, 17 Mar 2017 06:33:11 -0700 (PDT)
Received: by brontes.bolet.org (Postfix, from userid 1000) id 1324E20825; Fri, 17 Mar 2017 14:33:44 +0100 (CET)
Date: Fri, 17 Mar 2017 14:33:44 +0100
From: Thomas Pornin <pornin@bolet.org>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc: Martin Thomson <martin.thomson@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <20170317133344.GA20310@bolet.org>
References: <1489707933992.42551@cs.auckland.ac.nz> <CABkgnnVRZBwXHZ6w=gX9pykNpXp80OLP1pe-VMg-uO-C6O8yEQ@mail.gmail.com> <1489710142144.88978@cs.auckland.ac.nz> <CABkgnnXiB5ksGbbPqDP3D=FVdQu9ht0vD8-T-5HTaEKQQE4+9w@mail.gmail.com> <1489721710740.52293@cs.auckland.ac.nz> <CABkgnnWq_5e8TJgJV+okqi6vo-_5=811pOZRtUCp0TD07SmNoQ@mail.gmail.com> <CABkgnnW=Pz+6M8UYoB+MTY8rQp9vsHyh6aqiSb3EbTT_BdWokA@mail.gmail.com> <1489747107536.25854@cs.auckland.ac.nz> <CABkgnnUqHvc6zOL1SYP8FwBcF7SeMnnT-PJOwhMB1qqeDAcp9w@mail.gmail.com> <1489749662616.94542@cs.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1489749662616.94542@cs.auckland.ac.nz>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/lvBIhVmyEp7GT3Asb6KWlr0c3NE>
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 13:33:16 -0000
On Fri, Mar 17, 2017 at 11:21:12AM +0000, Peter Gutmann wrote: > However, this then leads to a problem where it doesn't actually solve > the constrained-client/server issue, if a client asks for 2K max > record size and the server responds with a 4K hello then it's going to > break the client even if later application_data records are only 2K. > So it would need to apply to every record type, not just > application_data. Hello, I had tried to raise the same issues here, a few months ago. The max_frag_length extension, as currently defined in RFC 6066, has the following issues: - It is client-driven: ** The server cannot send the extension unless the client has sent it first. ** Even if the client sent the extension, the only option for the server is to respond with an extension advertising the very same length. The server has no option to negotiate a smaller maximum fragment length. - "Big" clients (Web browsers) don't support it and have no incentive to do so, since they, as client, can totally use huge records, which are negligible with regards to the dozens of megabytes they eat up just for starting up. - The extension mandates the same size constraint on both directions. A constrained implementation may have two separate buffers for sending and receiving, and these buffers need not have the same size. In fact, in dedicated specific situations, records larger than the output buffer may be sent (the sender must know in advance how many bytes it will send, but it can encrypt and MAC "on the fly"). Fragmentation of messages is another issue, which is correlated but still distinct. Note for instance that it is customary, in the case of TLS 1.0 with a CBC-based cipher suite, to fragment _all_ records (application data records, at least) as part of a protection against BEAST-like attacks. Also, having very small buffers does not necessarily prevent processing larger handshake messages, or even larger unencrypted records. Here I may point at my own SSL implementation (www.bearssl.org) that can do both: it supports unencrypted records that are larger than its input buffer, and it supports huge handshake messages. It can actually perform rudimentary X.509 path validation even with multi-megabyte certificates, while keeping to a few kilobytes of RAM and no dynamic allocation. Now that does not mean that a "don't fragment" flag has no value. Indeed, streamed processing of messages is not easy to implement (I know, since I did it), and having some guarantees on non-fragmentations may help some implementations that are very constrained in ROM size and must stick to the simplest possible code. But it still is a distinct thing. Moreover, maximum handshake message length needs not be the same as the maximum record length. For instance, OpenSSL tends to enforce a maximum 64 kB size on handshake messages. Maybe we need a "maximum handshake message length" extension. In order to "fix" RFC 6066, the following would be needed, in my opinion: - Allow the server to send the extension even if the client did not send it. - Allow the server to mandate fragment lengths smaller than the value sent by the client (a client not sending the extension would be assumed to have implicitly sent an extension with a 16384-byte max fragment length). - Preferably, change the encoding to allow for _two_ lengths, for both directions, negociated separately. - Preferably, write down in TLS 1.3 that supporting the extension is mandatory. Otherwise, chances are that Web browsers won't implement it anyway. I can prototype things in BearSSL (both client and server). --Thomas Pornin
- [TLS] RFC 6066 - Max fragment length negotiation Nitin Shrivastav
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Yoav Nir
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Yoav Nir
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Peter Gutmann
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Nitin Shrivastav
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Peter Gutmann
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Nitin Shrivastav
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Martin Thomson
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Peter Gutmann
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Martin Thomson
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Eric Rescorla
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Peter Gutmann
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Martin Thomson
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Martin Thomson
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Peter Gutmann
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Martin Thomson
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Peter Gutmann
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Thomas Pornin
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Ilari Liusvaara
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Ilari Liusvaara
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Hannes Tschofenig
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Hannes Tschofenig
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Hannes Tschofenig
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Thomas Pornin
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Ilari Liusvaara
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Peter Gutmann
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Peter Gutmann
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Peter Gutmann
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Joseph Birr-Pixton
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Peter Gutmann
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Joseph Birr-Pixton
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Martin Thomson
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Hannes Tschofenig
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Nitin Shrivastav
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Sheehe, Charles J. (GRC-LCA0)
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Thomas Pornin
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Peter Gutmann
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Nikos Mavrogiannopoulos
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Hannes Tschofenig
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Martin Thomson
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Martin Thomson
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Eric Rescorla
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Martin Thomson
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Eric Rescorla
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Martin Thomson
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Eric Rescorla
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Peter Gutmann
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Martin Rex
- Re: [TLS] RFC 6066 - Max fragment length negotiat… Peter Gutmann