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
