Re: [TLS] Maximum Fragment Length negotiation

[Michael Tuexen <[e-mail]>]

> On 24 Nov 2016, at 20:50, Thomas Pornin <[e-mail]> 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 ?
Can we extend this in a way that you can also increase the maximum
fragment length. So if the client requests a larger value and the
server is willing to do so, it can be used?

Best regards
Michael
> 
> Thanks,
> 
> 
> 	--Thomas Pornin
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls