What is the RAM cost of TLS and how do you minimize it?

TLS RAM consumption comes from three main sources. The handshake requires buffers for incoming and outgoing handshake messages — the largest being the server's certificate chain, which can be 2-4 KB per certificate (a chain of 2-3 certificates means 4-12 KB just for reassembly). The record layer needs send and receive buffers — by default 16 KB each (the maximum TLS record size), totaling 32 KB. The session state includes the symmetric keys, sequence numbers, and cipher context — typically 1-2 KB. Total baseline: 10-50 KB per TLS connection, depending on configuration.

To minimize RAM, apply these techniques. Reduce the maximum fragment length using the TLS Maximum Fragment Length (MFL) extension (RFC 6066): negotiate 1 KB or 2 KB fragments instead of 16 KB, reducing the record buffers from 32 KB to 2-4 KB. Both client and server must support this extension. Use ECDSA certificates instead of RSA — ECDSA certificates are much smaller (a 256-bit ECDSA certificate is ~500 bytes vs ~1.5 KB for a 2048-bit RSA certificate), reducing the certificate reassembly buffer. Enable session resumption to avoid the full handshake (and its peak RAM usage) on reconnections. Limit cipher suites to a single suite (e.g., TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256) to avoid code and RAM for unused algorithms.

With aggressive optimization in mbedTLS, you can achieve a per-connection RAM footprint of 10-15 KB — achievable on Cortex-M4 devices with 64-128 KB of RAM. BearSSL is even more aggressive, achieving under 25 KB total (including code) with careful configuration. The key insight is that TLS RAM cost is not fixed — it is highly configurable, and embedded engineers must tune it rather than accepting the defaults that were designed for desktop machines.