[TLS] Server-side fragment size signalling

["Paul Bakker" <[e-mail]>]

Hi,

While we are on the TLS 1.3 discussion, I would like to start a discussion
on bringing equality to low-footprint servers compared to the options
clients have now. Currently low-footprint clients that have very restricted
memory resources are able to indicate using smaller send/receive buffers
with the max_fragment_length extension (If the server supports the RFC
6066). This removes the need to be able to accept packets 16k bytes in size,
which is often one of the largest 'permanent' buffers you need in
low-footprint environments.

But low-footprint servers that get connected to by high-footprint clients
don't have this option. They cannot indicate to the client that they would
only like to receive fragments with a maximum size of 2^9.

As the world of small-footprint devices is still growing rapidly (i.e.
Internet of Things), life for low-footprint servers should be viable as
well.

The simplest solution to this is to modify the current extension's
definition (Other RFC but as follows:
* Change:
   "In order to negotiate smaller maximum fragment lengths, clients MAY
include an extension of type "max_fragment_length" in the (extended) client
hello.  "
   Into:
   "If a clients support this extension, clients SHALL include an extension
of type "max_fragment_length" in the (extended) client hello."
* And:
   "The "extension_data" field of this extension SHALL contain a
"MaxFragmentLength" whose value is the same as the requested maximum
fragment length."
   Into:
   "The "extension_data" field of this extension SHALL contain a
"MaxFragmentLength" whose value is the same or lower as the requested
maximum fragment length."

An alternative is to allow the server to send a max_fragment_length
extension even if it did not receive one from the client, but this violates
the 'standard way' and the server does not know if the client even supports
the max_fragment_length extension.

I'm actively looking for feedback or alternatives that people have in mind!

Best regards,
Paul Bakker
Lead maintainer PolarSSL