Valentin Sawadski

In the internet SSL/TLS is a widely adopted standard. Almost any time sensitive information is transmitted the technology is being used.

However when it comes to small and resource constrained devices it always seems a bit to heavy for cost sensitive devices to implement it. Mainly because of these factors:

  1. Computational effort: Establishing a TLS connection can take seconds depending on the platform. However, maintaining one is cheap for most Microcontrollers.
  2. Binary size: A small SSL/TLS library can still use 30-40 kByte of the devices Memory, large ones use up a couple of hundred kBytes.
  3. RAM size: TLS specifies a maximum fragment length of 16 kByte. So the internal receive buffer of any device must be at least this size, otherwise will not be able to receive large messages from the other party. Because encryption can only be done if a complete fragment has been received.

Especially the large buffer is a huge waste of RAM for most devices. They usually send and receive only smaller messages. Still they have reserve all the memory.

To overcome this limitation the IETF wrote RFC 6066, an extension to TLS. In there a maximum fragment length negotiation has been introduced, allowing constrained devices to choose buffers as small as 512 bytes. This would allow most applications to choose a buffer closer to the size of their transmission sizes, and save precious RAM.

However looking at the support for this extension only GnuTLS provides support for that. Even implementations especially written for embedded devices such as axTLS don't support the extension.

This puts a lot of developers in a tough spot. If they don't want to waste all the unused RAM they have the following option:

  1. Find/write RFC 6066 compliant libraries for the devices and server.
  2. Hack the receiving TLS library to use a smaller buffer and drop all fragments that don't fit.

Clearly both are not perfect. While the first is the clean way it might be a lot work to do it properly. The second hack could maybe be done easier. But it would not only break compliance with the standard, even worse it could mean losing connection to the devices if the sending party does not take care of the size of the fragments it sends.

So there is no silver bullet. But I hope strongly for adoption of RFC 6066 to finally get TLS into the internet of things!



This work is licensed under a Creative Commons Attribution 4.0 International License. Hosted by GitHub. Impressum