Status of This Memo

This is an Internet Standards Track document.¶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8449.¶

Copyright Notice

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶

Table of Contents

1. Introduction

Implementing Transport Layer Security (TLS)[TLS] orDatagram TLS (DTLS)[DTLS] for constrained devices can be challenging.However, recent improvements to the design and implementation of cryptographicalgorithms have made TLS accessible to some highly limited devices (see, forexample,[RFC7925]).¶

Receiving large protected records can be particularly difficult for a devicewith limited operating memory. TLS versions 1.2[RFC5246] andearlier permitsenders to generate records 16384 octets in size, plus any expansion fromcompression and protection up to 2048 octets (though typically this expansion isonly 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 someimplementations.¶

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

Themax_fragment_length extension[RFC6066] was designed to enableconstrained clients to negotiate a lower record size. However,max_fragment_length suffers from several design problems (seeSection 3).¶

This document defines arecord_size_limit extension (Section 4). Thisextension replacesmax_fragment_length[RFC6066], which this documentdeprecates. This extension is valid in all versions of TLS.¶

A smaller protected record size is just one of many problems that a constrainedimplementation might need to address. Therecord_size_limit extension onlyaddresses the memory allocation problem; it does not address limits of codesize, processing capability, or bandwidth capacity.¶

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Limitations of the "max_fragment_length" Extension

Themax_fragment_length extension has several limitations that make itunsuitable for use.¶

A client that has no constraints preventing it from accepting a large recordcannot usemax_fragment_length without risking a reduction in the size ofrecords. The maximum value that the extension permits is 2^12, much smallerthan the maximum record size of 2^14 that the protocol permits.¶

For large data transfers, small record sizes can materially affect performance.Every record incurs additional costs, both in the additional octets for recordheaders and for expansion due to encryption. Processing more records also addscomputational overheads that can be amortized more effectively for larger recordsizes. Consequently, clients that are capable of receiving large records couldbe unwilling to risk reducing performance by offering the extension, especiallyif the extension is rarely needed.¶

This would not be an issue if a codepoint were available or could be added forfragments of 2^14 octets. However, RFC 6066 requires that servers abort thehandshake with an "illegal_parameter" alert if they receive the extension with avalue they don't understand. This makes it impossible to add new values to theextension without the risk of failed connection attempts.¶

A server that negotiatesmax_fragment_length is required to echo the valueselected by the client. The server cannot request a lower limit than the onethe client offered. This is a significant problem if a server is moreconstrained than the clients it serves.¶

Themax_fragment_length extension is also ill-suited to cases where thecapabilities of client and server are asymmetric. Constraints on record sizeare often receiver constraints.¶

In comparison, an implementation might be able to send data incrementally.Encryption does not have the same atomicity requirement. Some ciphers can beencrypted and sent progressively. Thus, an endpoint might be willing to sendrecords larger than thelimit it advertises for records that it receives.¶

If these disincentives are sufficient to discourage clients from deploying themax_fragment_length extension, then constrained servers are unable to limitrecord sizes.¶

4. The "record_size_limit" Extension

The ExtensionData of therecord_size_limit extension is RecordSizeLimit:¶

   uint16 RecordSizeLimit;

The value of RecordSizeLimit is the maximum size of record in octets that theendpoint is willing to receive. This value is used to limit the size of recordsthat are created when encoding application data and the protected handshake messageinto records.¶

When therecord_size_limit extension is negotiated, an endpoint MUST NOTgenerate a protected record with plaintext that is larger than theRecordSizeLimit value it receives from its peer. Unprotected messages are notsubject to this limit.¶

This value is the length of the plaintext of a protected record. The valueincludes the content type and padding added in TLS 1.3 (that is, the completelength of TLSInnerPlaintext). In TLS 1.2 and earlier, the limit covers allinput to compression and encryption (that is, the data that ultimately producesTLSCiphertext.fragment). Padding added as part of encryption, such as thatadded by a block cipher, is not included in this count (seeSection 4.1).¶

An endpoint that supports all record sizes can include any limit up to theprotocol-defined limit for maximum record size. For TLS 1.2 and earlier, thatlimit is 2^14 octets. TLS 1.3 uses a limit of 2^14+1 octets. Higher values arecurrently reserved for future versions of the protocol that may allow largerrecords; an endpoint MUST NOT send a value higher than the protocol-definedmaximum record size unless explicitly allowed by such a future version orextension. A server MUST NOT enforce this restriction; a client mightadvertise a higher limit that is enabled by an extension or version the serverdoes not understand. A client MAY abort the handshake with an "illegal_parameter"alert if the record_size_limit extension includes a value greater than themaximum record size permitted by the negotiated protocol version and extensions.¶

Even if a larger record size limit is provided by a peer, an endpoint MUST NOTsend records larger than the protocol-defined limit, unless explicitly allowedby a future TLS version or extension.¶

The record size limit only applies to records sent toward the endpoint thatadvertises the limit. An endpoint can send records that are larger than thelimit it advertises as its own limit. A TLS endpoint that receives a recordlarger than its advertised limit MUST generate a fatal "record_overflow" alert;a DTLS endpoint that receives a record larger than its advertised limit MAYeither generate a fatal "record_overflow" alert or discard the record.¶

Endpoints SHOULD advertise therecord_size_limit extension, even if they haveno need to limit the size of records. For clients, this allows servers toadvertise a limit at their discretion. For servers, this allows clients to knowthat their limit will be respected. If this extension is not negotiated,endpoints can send records of any size permitted by the protocol or othernegotiated extensions.¶

Endpoints MUST NOT send arecord_size_limit extension with a value smallerthan 64. An endpoint MUST treat receipt of a smaller value as a fatal error andgenerate an "illegal_parameter" alert.¶

In TLS 1.3, the server sends therecord_size_limit extension in theEncryptedExtensions message.¶

During renegotiation or resumption, the record size limit is renegotiated.Records are subject to the limits that were set in the handshake that producesthe keys that are used to protect those records. This admits the possibilitythat the extension might not be negotiated when a connection is renegotiated orresumed.¶

The Path Maximum Transmission Unit (PMTU) in DTLS also limits the size ofrecords. The record size limit does not affect PMTU discovery and SHOULD beset independently. The record size limit is fixed during the handshake and so should be set based on constraints at the endpoint and not based on the current network environment.In comparison, the PMTU is determined by the network path and canchange dynamically over time. See[PMTU] and Section 4.1.1.1 of[DTLS] for more detail on PMTU discovery.¶

PMTU governs the size of UDP datagrams, which limits the size of records, butdoes not prevent records from being smaller. An endpoint that sends smallrecords is still able to send multiple records in a single UDP datagram.¶

5. Deprecating "max_fragment_length"

Therecord_size_limit extension replaces themax_fragment_length extension[RFC6066]. A server that supports therecord_size_limit extension MUSTignore amax_fragment_length that appears in a ClientHello if bothextensions appear. A client MUST treat receipt of bothmax_fragment_lengthandrecord_size_limit as a fatal error, and it SHOULD generate an"illegal_parameter" alert.¶

Clients that depend on having a small record size MAY continue to advertise themax_fragment_length.¶

6. Security Considerations

Very small record sizes might generate additional work for senders andreceivers, limiting throughput and increasing exposure to denial of service.¶

7. IANA Considerations

This document registers therecord_size_limitextension in the "TLS ExtensionType Values" registry established in[RFC5246]. Therecord_size_limit extension has been assigned acode point of 28. The IANA registry[TLS-REGISTRY] liststhis extension as as "Recommended" (i.e., "Y") and indicates that it mayappear in the ClientHello (CH) or EncryptedExtensions (EE) messages in TLS 1.3[TLS].¶

In the same registry, themax_fragment_length has been changedto not recommended (i.e., "N").¶

Acknowledgments

Thomas Pornin and Hannes Tschofenig provided significant input to thisdocument. Alan DeKok identified an issue with the interaction between recordsize limits and PMTU.¶

Author's Address