Hi Thomas, your observations are in line with what we had noticed as well, see Section 6 of https://tools.ietf.org/html/draft-fossati-tls-iot-optimizations-00
Ciao Hannes On 11/24/2016 08:50 PM, Thomas Pornin 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 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
