Re: [TLS] Maximum Fragment Length negotiation

[Hannes Tschofenig <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>