1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
|
<pre>Internet Engineering Task Force (IETF) M. Thomson
Request for Comments: 8449 Mozilla
Updates: <a href="./rfc6066">6066</a> August 2018
Category: Standards Track
ISSN: 2070-1721
<span class="h1">Record Size Limit Extension for TLS</span>
Abstract
An extension to Transport Layer Security (TLS) is defined that allows
endpoints to negotiate the maximum size of protected records that
each will send the other.
This replaces the maximum fragment length extension defined in
<a href="./rfc6066">RFC 6066</a>.
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 <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc8449">https://www.rfc-editor.org/info/rfc8449</a>.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a>) 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.
<span class="grey">Thomson Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8449">RFC 8449</a> TLS Record Limit August 2018</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Conventions and Definitions . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. Limitations of the "max_fragment_length" Extension . . . . . <a href="#page-3">3</a>
<a href="#section-4">4</a>. The "record_size_limit" Extension . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4.1">4.1</a>. Record Expansion Limits . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5">5</a>. Deprecating "max_fragment_length" . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-6">6</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-7">7</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-8">8</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-8.1">8.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-8.2">8.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Implementing Transport Layer Security (TLS) [<a href="#ref-TLS" title=""The Transport Layer Security (TLS) Protocol Version 1.3"">TLS</a>] or Datagram TLS
(DTLS) [<a href="#ref-DTLS" title=""Datagram Transport Layer Security Version 1.2"">DTLS</a>] 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, [<a href="./rfc7925" title=""Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things"">RFC7925</a>]).
Receiving large protected records can be particularly difficult for a
device with limited operating memory. TLS versions 1.2 [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>] 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
[<a href="./rfc5116" title=""An Interface and Algorithms for Authenticated Encryption"">RFC5116</a>]) 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 [<a href="./rfc6066" title=""Transport Layer Security (TLS) Extensions: Extension Definitions"">RFC6066</a>] was designed to enable
constrained clients to negotiate a lower record size. However,
"max_fragment_length" suffers from several design problems (see
<a href="#section-3">Section 3</a>).
This document defines a "record_size_limit" extension (<a href="#section-4">Section 4</a>).
This extension replaces "max_fragment_length" [<a href="./rfc6066" title=""Transport Layer Security (TLS) Extensions: Extension Definitions"">RFC6066</a>], which this
document deprecates. This extension is valid in all versions of TLS.
<span class="grey">Thomson Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8449">RFC 8449</a> TLS Record Limit August 2018</span>
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.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Conventions and Definitions</span>
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
<a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="./rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>] when, and only when, they appear in all
capitals, as shown here.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Limitations of the "max_fragment_length" Extension</span>
The "max_fragment_length" extension has several limitations that make
it unsuitable for use.
A client that has no constraints preventing it from accepting a large
record cannot use "max_fragment_length" without risking a reduction
in the size of records. The maximum value that the extension permits
is 2^12, much smaller than 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 record headers and for expansion due to
encryption. Processing more records also adds computational
overheads that can be amortized more effectively for larger record
sizes. Consequently, clients that are capable of receiving large
records could be unwilling to risk reducing performance by offering
the extension, especially if the extension is rarely needed.
This would not be an issue if a codepoint were available or could be
added for fragments of 2^14 octets. However, <a href="./rfc6066">RFC 6066</a> requires that
servers abort the handshake with an "illegal_parameter" alert if they
receive the extension with a value they don't understand. This makes
it impossible to add new values to the extension without the risk of
failed connection attempts.
A server that negotiates "max_fragment_length" is required to echo
the value selected by the client. The server cannot request a lower
limit than the one the client offered. This is a significant problem
if a server is more constrained than the clients it serves.
<span class="grey">Thomson Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8449">RFC 8449</a> TLS Record Limit August 2018</span>
The "max_fragment_length" extension is also ill-suited to cases where
the capabilities of client and server are asymmetric. Constraints on
record size are 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 be encrypted and sent progressively.
Thus, an endpoint might be willing to send records larger than the
limit it advertises for records that it receives.
If these disincentives are sufficient to discourage clients from
deploying the "max_fragment_length" extension, then constrained
servers are unable to limit record sizes.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. The "record_size_limit" Extension</span>
The ExtensionData of the "record_size_limit" extension is
RecordSizeLimit:
uint16 RecordSizeLimit;
The value of RecordSizeLimit is the maximum size of record in octets
that the endpoint is willing to receive. This value is used to limit
the size of records that are created when encoding application data
and the protected handshake message into records.
When the "record_size_limit" extension is negotiated, an endpoint
MUST NOT generate a protected record with plaintext that is larger
than the RecordSizeLimit value it receives from its peer.
Unprotected messages are not subject to this limit.
This value is the length of the plaintext of a protected record. The
value includes the content type and padding added in TLS 1.3 (that
is, the complete length of TLSInnerPlaintext). In TLS 1.2 and
earlier, the limit covers all input to compression and encryption
(that is, the data that ultimately produces TLSCiphertext.fragment).
Padding added as part of encryption, such as that added by a block
cipher, is not included in this count (see <a href="#section-4.1">Section 4.1</a>).
An endpoint that supports all record sizes can include any limit up
to the protocol-defined limit for maximum record size. For TLS 1.2
and earlier, that limit is 2^14 octets. TLS 1.3 uses a limit of
2^14+1 octets. Higher values are currently reserved for future
versions of the protocol that may allow larger records; an endpoint
MUST NOT send a value higher than the protocol-defined maximum record
size unless explicitly allowed by such a future version or extension.
A server MUST NOT enforce this restriction; a client might advertise
a higher limit that is enabled by an extension or version the server
<span class="grey">Thomson Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8449">RFC 8449</a> TLS Record Limit August 2018</span>
does not understand. A client MAY abort the handshake with an
"illegal_parameter" alert if the record_size_limit extension includes
a value greater than the maximum 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 NOT send records larger than the protocol-defined limit, unless
explicitly allowed by a future TLS version or extension.
The record size limit only applies to records sent toward the
endpoint that advertises the limit. An endpoint can send records
that are larger than the limit it advertises as its own limit. A TLS
endpoint that receives a record larger than its advertised limit MUST
generate a fatal "record_overflow" alert; a DTLS endpoint that
receives a record larger than its advertised limit MAY either
generate a fatal "record_overflow" alert or discard the record.
Endpoints SHOULD advertise the "record_size_limit" extension, even if
they have no need to limit the size of records. For clients, this
allows servers to advertise a limit at their discretion. For
servers, this allows clients to know that their limit will be
respected. If this extension is not negotiated, endpoints can send
records of any size permitted by the protocol or other negotiated
extensions.
Endpoints MUST NOT send a "record_size_limit" extension with a value
smaller than 64. An endpoint MUST treat receipt of a smaller value
as a fatal error and generate an "illegal_parameter" alert.
In TLS 1.3, the server sends the "record_size_limit" extension in the
EncryptedExtensions message.
During renegotiation or resumption, the record size limit is
renegotiated. Records are subject to the limits that were set in the
handshake that produces the keys that are used to protect those
records. This admits the possibility that the extension might not be
negotiated when a connection is renegotiated or resumed.
The Path Maximum Transmission Unit (PMTU) in DTLS also limits the
size of records. The record size limit does not affect PMTU
discovery and SHOULD be set 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 can change
dynamically over time. See [<a href="#ref-PMTU" title=""Path MTU Discovery for IP version 6"">PMTU</a>] and Section 4.1.1.1 of [<a href="#ref-DTLS" title=""Datagram Transport Layer Security Version 1.2"">DTLS</a>] for
more detail on PMTU discovery.
<span class="grey">Thomson Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8449">RFC 8449</a> TLS Record Limit August 2018</span>
PMTU governs the size of UDP datagrams, which limits the size of
records, but does not prevent records from being smaller. An
endpoint that sends small records is still able to send multiple
records in a single UDP datagram.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Record Expansion Limits</span>
The size limit expressed in the "record_size_limit" extension doesn't
account for expansion due to compression or record protection. It is
expected that a constrained device will disable compression to avoid
unpredictable increases in record size. Stream ciphers and existing
AEAD ciphers don't permit variable amounts of expansion, but block
ciphers do permit variable expansion.
In TLS 1.2, block ciphers allow from 1 to 256 octets of padding.
When a limit lower than the protocol-defined limit is advertised, a
second limit applies to the length of records that use block ciphers.
An endpoint MUST NOT add padding to records that would cause the
protected record to exceed the size of a protected record that
contains the maximum amount of plaintext and the minimum permitted
amount of padding.
For example, TLS_RSA_WITH_AES_128_CBC_SHA has 16-octet blocks and a
20-octet MAC. Given a record size limit of 256, a record of that
length would require a minimum of 11 octets of padding (for
[<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>], where the MAC is covered by encryption); or 15 octets if
the "encrypt_then_mac" extension [<a href="./rfc7366" title=""Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"">RFC7366</a>] is negotiated. With this
limit, a record with 250 octets of plaintext could be padded to the
same length by including at most 17 octets of padding, or 21 octets
with "encrypt_then_mac".
An implementation that always adds the minimum amount of padding will
always comply with this requirement.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Deprecating "max_fragment_length"</span>
The "record_size_limit" extension replaces the "max_fragment_length"
extension [<a href="./rfc6066" title=""Transport Layer Security (TLS) Extensions: Extension Definitions"">RFC6066</a>]. A server that supports the "record_size_limit"
extension MUST ignore a "max_fragment_length" that appears in a
ClientHello if both extensions appear. A client MUST treat receipt
of both "max_fragment_length" and "record_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 the "max_fragment_length".
<span class="grey">Thomson Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8449">RFC 8449</a> TLS Record Limit August 2018</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
Very small record sizes might generate additional work for senders
and receivers, limiting throughput and increasing exposure to denial
of service.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
This document registers the "record_size_limit" extension in the "TLS
ExtensionType Values" registry established in [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>]. The
"record_size_limit" extension has been assigned a code point of 28.
The IANA registry [<a href="#ref-TLS-REGISTRY">TLS-REGISTRY</a>] lists this extension as
"Recommended" (i.e., "Y") and indicates that it may appear in the
ClientHello (CH) or EncryptedExtensions (EE) messages in TLS 1.3
[<a href="#ref-TLS" title=""The Transport Layer Security (TLS) Protocol Version 1.3"">TLS</a>].
In the same registry, the "max_fragment_length" has been changed to
not recommended (i.e., "N").
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC5246">RFC5246</a>] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", <a href="./rfc5246">RFC 5246</a>,
DOI 10.17487/RFC5246, August 2008,
<<a href="https://www.rfc-editor.org/info/rfc5246">https://www.rfc-editor.org/info/rfc5246</a>>.
[<a id="ref-RFC6066">RFC6066</a>] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", <a href="./rfc6066">RFC 6066</a>,
DOI 10.17487/RFC6066, January 2011,
<<a href="https://www.rfc-editor.org/info/rfc6066">https://www.rfc-editor.org/info/rfc6066</a>>.
[<a id="ref-RFC7366">RFC7366</a>] Gutmann, P., "Encrypt-then-MAC for Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", <a href="./rfc7366">RFC 7366</a>, DOI 10.17487/RFC7366, September 2014,
<<a href="https://www.rfc-editor.org/info/rfc7366">https://www.rfc-editor.org/info/rfc7366</a>>.
[<a id="ref-RFC8174">RFC8174</a>] Leiba, B., "Ambiguity of Uppercase vs Lowercase in <a href="./rfc2119">RFC</a>
<a href="./rfc2119">2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>, DOI 10.17487/RFC8174,
May 2017, <<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>>.
<span class="grey">Thomson Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8449">RFC 8449</a> TLS Record Limit August 2018</span>
[<a id="ref-TLS">TLS</a>] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", <a href="./rfc8446">RFC 8446</a>, DOI 10.17487/RFC8446, August 2018,
<<a href="https://www.rfc-editor.org/info/rfc8446">https://www.rfc-editor.org/info/rfc8446</a>>.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-DTLS">DTLS</a>] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", <a href="./rfc6347">RFC 6347</a>, DOI 10.17487/RFC6347,
January 2012, <<a href="https://www.rfc-editor.org/info/rfc6347">https://www.rfc-editor.org/info/rfc6347</a>>.
[<a id="ref-PMTU">PMTU</a>] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, <a href="./rfc8201">RFC 8201</a>,
DOI 10.17487/RFC8201, July 2017,
<<a href="https://www.rfc-editor.org/info/rfc8201">https://www.rfc-editor.org/info/rfc8201</a>>.
[<a id="ref-RFC5116">RFC5116</a>] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", <a href="./rfc5116">RFC 5116</a>, DOI 10.17487/RFC5116, January 2008,
<<a href="https://www.rfc-editor.org/info/rfc5116">https://www.rfc-editor.org/info/rfc5116</a>>.
[<a id="ref-RFC7925">RFC7925</a>] Tschofenig, H., Ed. and T. Fossati, "Transport Layer
Security (TLS) / Datagram Transport Layer Security (DTLS)
Profiles for the Internet of Things", <a href="./rfc7925">RFC 7925</a>,
DOI 10.17487/RFC7925, July 2016,
<<a href="https://www.rfc-editor.org/info/rfc7925">https://www.rfc-editor.org/info/rfc7925</a>>.
[<a id="ref-TLS-REGISTRY">TLS-REGISTRY</a>]
Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", <a href="./rfc8447">RFC 8447</a>, DOI 10.17487/RFC8447, August 2018,
<<a href="https://www.rfc-editor.org/info/rfc8447">https://www.rfc-editor.org/info/rfc8447</a>>.
Acknowledgments
Thomas Pornin and Hannes Tschofenig provided significant input to
this document. Alan DeKok identified an issue with the interaction
between record size limits and PMTU.
Author's Address
Martin Thomson
Mozilla
Email: martin.thomson@gmail.com
Thomson Standards Track [Page 8]
</pre>
|
