Hi Thomas, We encountered the same issue and suggested something similar in [1] -- although not at the same level of detail as you below.
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. So, why not simply allocating a new code-point for an extension with the semantics you describe and make it available across different protocol versions? Cheers, t [1] https://tools.ietf.org/html/draft-fossati-tls-iot-optimizations-00#section- 6 On 24/11/2016 19:50, "TLS on behalf of Thomas Pornin" <tls-boun...@ietf.org on behalf of por...@bolet.org> wrote: >Hello, > >I know that I am a bit late to the party, but I have a suggestion for >the upcoming TLS 1.3. > >Context: I am interested in TLS support in constrained architectures, >specifically those which have very little RAM. I recently published a >first version of an implementation of TLS 1.0 to 1.2, that primarily >targets that kind of system ( https://www.bearssl.org/ ); a fully >functional TLS server can then run in as little as 25 kB of RAM (and >even less of ROM, for the code itself). > >Out of these 25 kB, 16 kB are used for the buffer for incoming records, >because encrypted records cannot be processed until fully received (data >could be obtained from a partial record, but we must wait for the MAC >before actually acting on the data) and TLS specifies that records can >have up to 16384 bytes of plaintext. Thus, about 2/3 of the RAM usage is >directly related to that maximum fragment length. > >There is a defined extension (in RFC 6066) that allows a client to >negotiate a smaller maximum fragment length. That extension is simple >to implement, but it has two problems that prevent it from being >really usable: > > 1. It is optional, so any implementation is free not to implement it, > and in practice many do not (e.g. last time I checked, OpenSSL did > not support it). > > 2. It is one-sided: the client may asked for a smaller fragment, but > the server has no choice but to accept the value sent by the client. > In situations where the constrained system is the server, the > extension is not useful (e.g. the embedded system runs a minimal > HTTPS server, for a Web-based configuration interface; the client is > a Web browser and won't ask for a smaller maximum fragment length). > > >I suggest to fix these issues in TLS 1.3. My proposal is the following: > > - Make Max Fragment Length extension support mandatory (right now, > draft 18 makes it "recommended" only). > > - Extend the extension semantics **when used in TLS 1.3** in the >following > ways: > > * When an implementation supports a given maximum fragment length, it > MUST also support all smaller lengths (in the list of lengths > indicated in the extension: 512, 1024, 2048, 4096 and 16384). > > * When the server receives the extension for maximum length N, it > may respond with the extension with any length N' <= N (in the > list above). > > * If the client does not send the extension, then this is equivalent > to sending it with a maximum length of 16384 bytes (so the server > may still send the extension, even if the client did not). > > Semantics for the extension in TLS 1.2 and previous is unchanged. > >With these changes, RAM-constrained clients and servers can negotiate a >maximum length for record plaintext that they both support, and such an >implementation can use a small record buffer with the guarantee that all >TLS-1.3-aware peers will refrain from sending larger records. With, for >instance, a 2048-byte buffer, per-record overhead is still small (about >1%), and overall RAM usage is halved, which is far from negligible. > > >RAM-constrained full TLS 1.3 is likely to be challenging (I envision >issues with, for instance, cookies, since they can be up to 64 kB in >length), but a guaranteed flexible negotiation for maximum fragment >length would be a step in the right direction. > >Any comments / suggestions ? > >Thanks, > > > --Thomas Pornin > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
