idnits 2.17.1 draft-thomson-tls-record-limit-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6066, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC6066, updated by this document, for RFC5378 checks: 2007-07-02) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 27, 2017) is 2584 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-19 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS M. Thomson 3 Internet-Draft Mozilla 4 Updates: 6066 (if approved) March 27, 2017 5 Intended status: Standards Track 6 Expires: September 28, 2017 8 Record Size Limit Extension for Transport Layer Security (TLS) 9 draft-thomson-tls-record-limit-00 11 Abstract 13 An extension to Transport Layer Security (TLS) is defined that allows 14 endpoints to negotiate the maximum size of protected records that 15 each will send the other. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 28, 2017. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 2 53 3. Limitations of the "max_fragment_length" Extension . . . . . 3 54 4. The "record_size_limit" Extension . . . . . . . . . . . . . . 4 55 5. Deprecating "max_fragment_length" . . . . . . . . . . . . . . 5 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 60 8.2. Informative References . . . . . . . . . . . . . . . . . 6 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 63 1. Introduction 65 Implementing Transport Layer Security (TLS) [I-D.ietf-tls-tls13] for 66 constrained devices can be challenging. However, recent improvements 67 to the design and implementation of cryptographic algorithms have 68 made TLS accessible to some highly limited devices (see for example 69 [RFC7925]). 71 Receiving large protected records can be particularly difficult for a 72 device with limited operating memory. TLS versions 1.2 and earlier 73 [RFC5246] permit senders to generate records 16384 octets in size, 74 plus any expansion from compression and protection up to 2048 octets 75 (though typically this expansion is only 16 octets). TLS 1.3 reduces 76 the allowance for expansion to 256 octets. Allocating up to 18K of 77 memory for ciphertext is beyond the capacity of some implementations. 79 The "max_fragment_length" extension [RFC6066] was designed to enable 80 constrained clients to negotiate a lower record size. However, 81 "max_fragment_length" suffers from several design problems (see 82 Section 3). 84 This document defines a "record_size_limit" extension that replaces 85 "max_fragment_length" (see Section 4). This extension is valid in 86 all versions of TLS. 88 2. Conventions and Definitions 90 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this 91 document. It's not shouting; when they are capitalized, they have 92 the special meaning defined in [RFC2119]. 94 3. Limitations of the "max_fragment_length" Extension 96 The "max_fragment_length" extension has several limitations that make 97 it unsuitable for use. 99 A client that has no constraints preventing it from accepting a large 100 record cannot use "max_fragment_length" without risking a reduction 101 in the size of records. The maximum value that the extension permits 102 is 2^12, much smaller than the maximum record size of 2^14 that the 103 protocol permits. 105 For large data transfers, small record sizes can materially affect 106 performance [TARREAU]. Consequently, clients that are capable of 107 receiving large records could be unwilling to risk reducing 108 performance by offering the extension, especially if the extension is 109 rarely needed. 111 This would not be an issue if a codepoint were available or could be 112 added for fragments of 2^14 octets. However, RFC 6066 requires that 113 servers abort the handshake with an "illegal_parameter" alert if they 114 receive the extension with a value they don't understand. This makes 115 it impossible to add new values to the extension without risking 116 connection attempts failing. 118 The "max_fragment_length" extension is also ill-suited to cases where 119 the capabilities of client and server are asymmetric. The server is 120 required to select a fragment length that is as small or smaller than 121 the client offers and both endpoints need to comply with this smaller 122 limit. 124 Constraints on record size are often receiver constraints. In 125 particular, an Authentication Encryption with Additional Data (AEAD) 126 ciphers (see [RFC5116]) API requires that an entire record be present 127 to decrypt and authenticate it. Some implementations choose not to 128 implement an AEAD interface in this way to avoid this problem, but 129 that exposes them to risks that an AEAD is intended to protect 130 against. 132 In comparison, an implementation might be able to send data 133 incrementally. Encryption does not have the same atomicity 134 requirement. Some ciphers can be encrypted and sent progressively. 135 Thus, an endpoint might be willing to send more than its receive 136 limit. 138 If these disincentives are sufficient to discourage clients from 139 deploying the "max_fragment_length" extension, then constrained 140 servers are unable to limit record sizes. 142 4. The "record_size_limit" Extension 144 The ExtensionData of the "record_size_limit" extension is 145 RecordSizeLimit: 147 uint16 RecordSizeLimit; 149 The value of RecordSizeLimit is the maximum size of record that the 150 endpoint is willing to receive. When the "record_size_limit" 151 extension is negotiated, an endpoint MUST NOT generate a protected 152 record with plaintext that is larger than the RecordSizeLimit value 153 it receives from its peer. Unprotected messages - handshake messages 154 in particular - are not subject to this limit. 156 The size limit value governs the length of the plaintext of a 157 protected record. The value includes the content type and padding 158 added in TLS 1.3 (that is, the complete length of TLSInnerPlaintext). 159 Padding added as part of encryption, such as that added by a block 160 cipher, is not included in this count. 162 An endpoint that supports all record sizes can include any limit up 163 to the protocol-defined limit for maximum record size. For TLS 1.3 164 and earlier, that limit is 2^14 octets. Higher values are currently 165 reserved for future versions of the protocol that may allow larger 166 records; an endpoint MUST NOT send a value higher than the protocol- 167 defined maximum record size unless explicitly allowed by such a 168 future version or extension. 170 Even if a larger record size limit is provided by a peer, an endpoint 171 MUST NOT send records larger than the protocol-defined limit, unless 172 explicitly allowed by a future TLS version or extension. 174 The size limit expressed in the "record_size_limit" extension doesn't 175 account for expansion due to compression or record protection. It is 176 expected that a constrained device will disable compression and know 177 - and account for - the maximum expansion possible due to record 178 protection based on the cipher suites it offers or selects. Note 179 that up to 256 octets of padding and padding length can be added to 180 block ciphers. 182 The record size limit only applies to protected records that are sent 183 toward a peer. An endpoint MAY send records that are larger than the 184 limit it advertises. 186 Clients SHOULD advertise the "record_size_limit" extension, even if 187 they have no need to limit the size of records. This allows servers 188 to apply a limit at their discretion. If this extension is not 189 negotiated, endpoints can send records of any size permitted by the 190 protocol or other negotiated extensions. 192 Endpoints MUST NOT send a "record_size_limit" extension with a value 193 smaller than 64. An endpoint MUST treat receipt of a smaller value 194 as a fatal error and generate an "illegal_parameter" alert. 196 In TLS 1.3, the server sends the "record_size_limit" extension in the 197 EncryptedExtensions message. 199 5. Deprecating "max_fragment_length" 201 The "record_size_limit" extension replaces the "max_fragment_length" 202 extension. A server that supports the "record_size_limit" extension 203 MUST ignore and "max_fragment_length" that appears in a ClientHello 204 if both extensions appear. A client MUST treat receipt of both 205 "max_fragment_length" and "record_size_limit" as a fatal error, and 206 SHOULD generate an "illegal_parameter" alert. 208 Clients that depend on having a small record size MAY continue to 209 advertise the "max_fragment_length". 211 6. Security Considerations 213 Very small record sizes might generate additional work for senders 214 and receivers, limiting throughput and increasing exposure to denial 215 of service. 217 7. IANA Considerations 219 This document registers the "record_size_limit" extension in the TLS 220 "ExtensionType Values" registry established in [RFC5246]. The 221 "record_size_limit" extension has been assigned a code point of TBD; 222 it is recommended and marked as "Encrypted" in TLS 1.3. 224 8. References 226 8.1. Normative References 228 [I-D.ietf-tls-tls13] 229 Rescorla, E., "The Transport Layer Security (TLS) Protocol 230 Version 1.3", draft-ietf-tls-tls13-19 (work in progress), 231 March 2017. 233 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 234 Requirement Levels", BCP 14, RFC 2119, 235 DOI 10.17487/RFC2119, March 1997, 236 . 238 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 239 (TLS) Protocol Version 1.2", RFC 5246, 240 DOI 10.17487/RFC5246, August 2008, 241 . 243 8.2. Informative References 245 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 246 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 247 . 249 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 250 Extensions: Extension Definitions", RFC 6066, 251 DOI 10.17487/RFC6066, January 2011, 252 . 254 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 255 Security (TLS) / Datagram Transport Layer Security (DTLS) 256 Profiles for the Internet of Things", RFC 7925, 257 DOI 10.17487/RFC7925, July 2016, 258 . 260 [TARREAU] Tarreau, W., "Re: Stuck in a train -- reading HTTP/2 261 draft.", n.d., . 264 Author's Address 266 Martin Thomson 267 Mozilla 269 Email: martin.thomson@gmail.com