1. Introduction

1. Introduction

Implementing Transport Layer Security (TLS) [TLS] or Datagram TLS (DTLS) [DTLS] for constrained devices can be challenging. However, recent improvements to the design and implementation of cryptographic algorithms have made TLS accessible to some highly limited devices (see, for example, [RFC7925]).

Receiving large protected records can be particularly difficult for a device with limited operating memory. TLS versions 1.2 [RFC5246] and earlier permit senders to generate records 16384 octets in size, plus any expansion from compression and protection up to 2048 octets (though typically this expansion is only 16 octets). TLS 1.3 reduces the allowance for expansion to 256 octets. Allocating up to 18K of memory for ciphertext is beyond the capacity of some implementations.

An Authentication Encryption with Additional Data (AEAD) cipher (see [RFC5116]) API requires that an entire record be present to decrypt and authenticate it. Similarly, other ciphers cannot produce authenticated data until the entire record is present. Incremental processing of records exposes endpoints to the risk of forged data.

The max_fragment_length extension [RFC6066] was designed to enable constrained clients to negotiate a lower record size. However, max_fragment_length suffers from several design problems (see Section 3).

This document defines a record_size_limit extension (Section 4). This extension replaces max_fragment_length [RFC6066], which this document deprecates. This extension is valid in all versions of TLS.

A smaller protected record size is just one of many problems that a constrained implementation might need to address. The record_size_limit extension only addresses the memory allocation problem; it does not address limits of code size, processing capability, or bandwidth capacity.