3. Limitations of the "max_fragment_length" Extension

3. Limitations of the "max_fragment_length" Extension

The max_fragment_length extension has several limitations that make it unsuitable for use.

A client that has no constraints preventing it from accepting a large record cannot use max_fragment_length without risking a reduction in the size of records. The maximum value that the extension permits is 2^12, much smaller than the maximum record size of 2^14 that the protocol permits.

For large data transfers, small record sizes can materially affect performance. Every record incurs additional costs, both in the additional octets for record headers and for expansion due to encryption. Processing more records also adds computational overheads that can be amortized more effectively for larger record sizes. Consequently, clients that are capable of receiving large records could be unwilling to risk reducing performance by offering the extension, especially if the extension is rarely needed.

This would not be an issue if a codepoint were available or could be added for fragments of 2^14 octets. However, RFC 6066 requires that servers abort the handshake with an illegal_parameter alert if they receive the extension with a value they don't understand. This makes it impossible to add new values to the extension without the risk of failed connection attempts.

A server that negotiates max_fragment_length is required to echo the value selected by the client. The server cannot request a lower limit than the one the client offered. This is a significant problem if a server is more constrained than the clients it serves.

The max_fragment_length extension is also ill-suited to cases where the capabilities of client and server are asymmetric. Constraints on record size are often receiver constraints.

In comparison, an implementation might be able to send data incrementally. Encryption does not have the same atomicity requirement. Some ciphers can be encrypted and sent progressively. Thus, an endpoint might be willing to send records larger than the limit it advertises for records that it receives.

If these disincentives are sufficient to discourage clients from deploying the max_fragment_length extension, then constrained servers are unable to limit record sizes.