Re: [TLS] Maximum Fragment Length negotiation

["Fossati, Thomas (Nokia - GB)" <[e-mail]>]

Hi Thomas,

We encountered the same issue and suggested something similar in [1] --
although not at the same level of detail as you below.

I like your proposal, but I'm not convinced that overloading the semantics
of an already existing extension when used in combination with a specific
version of the protocol is necessarily the best strategy.  Besides, I'd
like to be able to deploy a similar mechanism in 1.2.

So, why not simply allocating a new code-point for an extension with the
semantics you describe and make it available across different protocol
versions?

Cheers, t

[1] 
https://tools.ietf.org/html/draft-fossati-tls-iot-optimizations-00#section-
6

On 24/11/2016 19:50, "TLS on behalf of Thomas Pornin"
<[e-mail] on behalf of [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 ?
>
>Thanks,
>
>
>	--Thomas Pornin
>
>_______________________________________________
>TLS mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/tls
>