idnits 2.17.1 draft-ietf-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 directly say this. It does mention RFC6066 though, so this could be OK. 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 (August 28, 2017) is 2433 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-21 ** 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) August 28, 2017 5 Intended status: Standards Track 6 Expires: March 1, 2018 8 Record Size Limit Extension for Transport Layer Security (TLS) 9 draft-ietf-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 This replaces the maximum fragment length extension defined in RFC 18 6066. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 1, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 2 56 3. Limitations of the "max_fragment_length" Extension . . . . . 3 57 4. The "record_size_limit" Extension . . . . . . . . . . . . . . 4 58 5. Deprecating "max_fragment_length" . . . . . . . . . . . . . . 5 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 63 8.2. Informative References . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 Implementing Transport Layer Security (TLS) [I-D.ietf-tls-tls13] for 69 constrained devices can be challenging. However, recent improvements 70 to the design and implementation of cryptographic algorithms have 71 made TLS accessible to some highly limited devices (see for example 72 [RFC7925]). 74 Receiving large protected records can be particularly difficult for a 75 device with limited operating memory. TLS versions 1.2 and earlier 76 [RFC5246] permit senders to generate records 16384 octets in size, 77 plus any expansion from compression and protection up to 2048 octets 78 (though typically this expansion is only 16 octets). TLS 1.3 reduces 79 the allowance for expansion to 256 octets. Allocating up to 18K of 80 memory for ciphertext is beyond the capacity of some implementations. 82 The "max_fragment_length" extension [RFC6066] was designed to enable 83 constrained clients to negotiate a lower record size. However, 84 "max_fragment_length" suffers from several design problems (see 85 Section 3). 87 This document defines a "record_size_limit" extension (Section 4). 88 This extension replaces "max_fragment_length" [RFC6066], which this 89 document deprecates. This extension is valid in all versions of TLS. 91 2. Conventions and Definitions 93 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this 94 document. It's not shouting; when they are capitalized, they have 95 the special meaning defined in [RFC2119]. 97 3. Limitations of the "max_fragment_length" Extension 99 The "max_fragment_length" extension has several limitations that make 100 it unsuitable for use. 102 A client that has no constraints preventing it from accepting a large 103 record cannot use "max_fragment_length" without risking a reduction 104 in the size of records. The maximum value that the extension permits 105 is 2^12, much smaller than the maximum record size of 2^14 that the 106 protocol permits. 108 For large data transfers, small record sizes can materially affect 109 performance [TARREAU]. Consequently, clients that are capable of 110 receiving large records could be unwilling to risk reducing 111 performance by offering the extension, especially if the extension is 112 rarely needed. 114 This would not be an issue if a codepoint were available or could be 115 added for fragments of 2^14 octets. However, RFC 6066 requires that 116 servers abort the handshake with an "illegal_parameter" alert if they 117 receive the extension with a value they don't understand. This makes 118 it impossible to add new values to the extension without risking 119 connection attempts failing. 121 A server that negotiates "max_fragment_length" is required to echo 122 the value selected by the client. The server cannot request a lower 123 limit than the one the client offered. This is a significant problem 124 if a server is more constrained than the clients it serves. 126 The "max_fragment_length" extension is also ill-suited to cases where 127 the capabilities of client and server are asymmetric. Constraints on 128 record size are often receiver constraints. In particular, an 129 Authentication Encryption with Additional Data (AEAD) ciphers (see 130 [RFC5116]) API requires that an entire record be present to decrypt 131 and authenticate it. Some implementations choose not to implement an 132 AEAD interface in this way to avoid this problem, but that exposes 133 them to risks that an AEAD is intended to protect against. 135 In comparison, an implementation might be able to send data 136 incrementally. Encryption does not have the same atomicity 137 requirement. Some ciphers can be encrypted and sent progressively. 138 Thus, an endpoint might be willing to send more than its receive 139 limit. 141 If these disincentives are sufficient to discourage clients from 142 deploying the "max_fragment_length" extension, then constrained 143 servers are unable to limit record sizes. 145 4. The "record_size_limit" Extension 147 The ExtensionData of the "record_size_limit" extension is 148 RecordSizeLimit: 150 uint16 RecordSizeLimit; 152 The value of RecordSizeLimit is the maximum size of record that the 153 endpoint is willing to receive. When the "record_size_limit" 154 extension is negotiated, an endpoint MUST NOT generate a protected 155 record with plaintext that is larger than the RecordSizeLimit value 156 it receives from its peer. Unprotected messages - handshake messages 157 in particular - are not subject to this limit. 159 This value is the size of the plaintext of a protected record. The 160 value includes the content type and padding added in TLS 1.3 (that 161 is, the complete length of TLSInnerPlaintext). Padding added as part 162 of encryption, such as that added by a block cipher, is not included 163 in this count. 165 An endpoint that supports all record sizes can include any limit up 166 to the protocol-defined limit for maximum record size. For TLS 1.3 167 and earlier, that limit is 2^14 octets. Higher values are currently 168 reserved for future versions of the protocol that may allow larger 169 records; an endpoint MUST NOT send a value higher than the protocol- 170 defined maximum record size unless explicitly allowed by such a 171 future version or extension. 173 Even if a larger record size limit is provided by a peer, an endpoint 174 MUST NOT send records larger than the protocol-defined limit, unless 175 explicitly allowed by a future TLS version or extension. 177 The size limit expressed in the "record_size_limit" extension doesn't 178 account for expansion due to compression or record protection. It is 179 expected that a constrained device will disable compression and know 180 - and account for - the maximum expansion possible due to record 181 protection based on the cipher suites it offers or selects. Note 182 that up to 256 octets of padding and padding length can be added to 183 block ciphers. 185 The record size limit only applies to records sent toward the 186 endpoint that advertises the limit. An endpoint MAY send records 187 that are larger than the limit it advertises as its own limit. 189 Clients SHOULD advertise the "record_size_limit" extension, even if 190 they have no need to limit the size of records. This allows servers 191 to apply a limit at their discretion. If this extension is not 192 negotiated, endpoints can send records of any size permitted by the 193 protocol or other negotiated extensions. 195 Endpoints MUST NOT send a "record_size_limit" extension with a value 196 smaller than 64. An endpoint MUST treat receipt of a smaller value 197 as a fatal error and generate an "illegal_parameter" alert. 199 In TLS 1.3, the server sends the "record_size_limit" extension in the 200 EncryptedExtensions message. 202 5. Deprecating "max_fragment_length" 204 The "record_size_limit" extension replaces the "max_fragment_length" 205 extension [RFC6066]. A server that supports the "record_size_limit" 206 extension MUST ignore and "max_fragment_length" that appears in a 207 ClientHello if both extensions appear. A client MUST treat receipt 208 of both "max_fragment_length" and "record_size_limit" as a fatal 209 error, and SHOULD generate an "illegal_parameter" alert. 211 Clients that depend on having a small record size MAY continue to 212 advertise the "max_fragment_length". 214 6. Security Considerations 216 Very small record sizes might generate additional work for senders 217 and receivers, limiting throughput and increasing exposure to denial 218 of service. 220 7. IANA Considerations 222 This document registers the "record_size_limit" extension in the TLS 223 "ExtensionType Values" registry established in [RFC5246]. The 224 "record_size_limit" extension has been assigned a code point of TBD; 225 it is recommended and marked as "Encrypted" in TLS 1.3. 227 8. References 229 8.1. Normative References 231 [I-D.ietf-tls-tls13] 232 Rescorla, E., "The Transport Layer Security (TLS) Protocol 233 Version 1.3", draft-ietf-tls-tls13-21 (work in progress), 234 July 2017. 236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 237 Requirement Levels", BCP 14, RFC 2119, 238 DOI 10.17487/RFC2119, March 1997, . 241 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 242 (TLS) Protocol Version 1.2", RFC 5246, 243 DOI 10.17487/RFC5246, August 2008, . 246 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 247 Extensions: Extension Definitions", RFC 6066, 248 DOI 10.17487/RFC6066, January 2011, . 251 8.2. Informative References 253 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 254 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 255 . 257 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 258 Security (TLS) / Datagram Transport Layer Security (DTLS) 259 Profiles for the Internet of Things", RFC 7925, 260 DOI 10.17487/RFC7925, July 2016, . 263 [TARREAU] Tarreau, W., "Re: Stuck in a train -- reading HTTP/2 264 draft.", n.d., . 267 Author's Address 269 Martin Thomson 270 Mozilla 272 Email: martin.thomson@gmail.com