[TLS] Maximum Fragment Length negotiation

[Thomas Pornin <[e-mail]>]

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