Record Size Limit Extension for TLS
updates
- rfc-6066 — Transport Layer Security (TLS) Extensions: Extension Definitions
Extracted elements (22)
AEAD ciphers require an entire record to be present before decryption and authentication can complete; incremental processing exposes endpoints to forged data. This is the core motivation for allowing constrained receivers to negotiate smaller record sizes.
`max_fragment_length` is asymmetric by design flaw: it limits what the server sends to the client's stated limit, but cannot limit what the client receives from a more constrained server. `record_size_limit` fixes this by letting each endpoint independently advertise the limit it is willing to receive.
`max_fragment_length` only permits values up to 2^12, which is smaller than the protocol's 2^14 maximum, and RFC 6066 requires servers to abort with `illegal_parameter` on unknown values, making it impossible to add a 2^14 codepoint without breaking existing servers.
The record size limit applies only to records sent toward the advertising endpoint; a sender may transmit records larger than its own advertised limit. This reflects that encryption is not atomically constrained the same way decryption is for AEAD ciphers.
During renegotiation or resumption the record size limit is renegotiated; records are governed by the limits set in the handshake that produced their protecting keys, meaning the extension might not be negotiated on a resumed connection.
In DTLS, the Path MTU (PMTU) independently constrains record sizes. The `record_size_limit` extension SHOULD be set independently of PMTU discovery because the limit is fixed at handshake time based on endpoint constraints, whereas PMTU is dynamic.
This document deprecates `max_fragment_length` (RFC 6066) and changes its TLS ExtensionType registry entry to not recommended. Clients that depend on small record sizes MAY continue to advertise `max_fragment_length` for backward compatibility.
A client MAY abort the handshake with an `illegal_parameter` alert if the peer's `record_size_limit` value exceeds the maximum record size permitted by the negotiated protocol version and extensions.
A server that supports `record_size_limit` MUST ignore a `max_fragment_length` extension that appears in a ClientHello when both extensions are present. A client MUST treat receipt of both extensions as a fatal error and SHOULD generate an `illegal_parameter` alert.
A TLS endpoint that receives a record larger than its advertised RecordSizeLimit MUST generate a fatal `record_overflow` alert. A DTLS endpoint in the same situation MAY either generate the alert or silently discard the record.
An endpoint MUST NOT send a `record_size_limit` value higher than the protocol-defined maximum record size unless explicitly allowed by a future version or extension. A server MUST NOT enforce this restriction on the client's advertised value.
An endpoint MUST NOT send records larger than the protocol-defined limit (2^14 for TLS 1.2, 2^14+1 for TLS 1.3) regardless of what the peer advertises, unless explicitly permitted by a future TLS version or extension.
Endpoints MUST NOT send a `record_size_limit` extension with a value smaller than 64. An endpoint MUST treat receipt of a value smaller than 64 as a fatal error and generate an `illegal_parameter` alert.
Endpoints SHOULD advertise the `record_size_limit` extension even if they have no need to limit record size, so that peers can know their limit will be respected and servers can advertise limits at their discretion.
In TLS 1.2, when a record size limit lower than the protocol-defined limit is in effect, an endpoint MUST NOT add padding to block-cipher records that would cause the protected record to exceed the size of a maximum-plaintext record with minimum padding.
When `record_size_limit` is negotiated, an endpoint MUST NOT generate a protected record with plaintext larger than the RecordSizeLimit value received from its peer. Unprotected messages are not subject to this limit.
In TLS 1.3, the server sends the `record_size_limit` extension in the EncryptedExtensions message. The limit covers the full TLSInnerPlaintext length, including content type and padding bytes added by TLS 1.3.
The `record_size_limit` extension carries a single uint16 field, RecordSizeLimit, whose value is the maximum plaintext size in octets that the advertising endpoint is willing to receive in a single protected record.
The RecordSizeLimit value represents plaintext length: in TLS 1.3 this is the complete TLSInnerPlaintext (content type and padding included); in TLS 1.2 and earlier it covers all input to compression and encryption, but excludes block-cipher padding.
The `record_size_limit` extension is registered in the IANA TLS ExtensionType Values registry with code point 28, marked Recommended (Y), and listed as valid in ClientHello (CH) and EncryptedExtensions (EE) messages. Simultaneously, `max_fragment_length` is changed to not recommended (N).
Very small record sizes generate additional per-record processing work for both senders and receivers, which can reduce throughput and increase exposure to denial-of-service attacks by amplifying the cost of sending data.
The ExtensionData of `record_size_limit` is a 2-octet unsigned integer (uint16) named RecordSizeLimit, encoding the maximum protected-record plaintext size the sender will accept.