idnits 2.17.1 draft-ietf-tls-dtls13-38.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 49 instances of too long lines in the document, the longest one being 3 characters in excess of 72. -- The draft header indicates that this document obsoletes RFC6347, 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 contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (29 May 2020) is 1428 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '32' on line 2332 -- Looks like a reference, but probably isn't: '2' on line 2334 == Missing Reference: 'ACK' is mentioned on line 1704, but not defined == Missing Reference: 'NewSessionTicket' is mentioned on line 1701, but not defined == Missing Reference: 'HelloRetryRequest' is mentioned on line 1665, but not defined ** Downref: Normative reference to an Informational RFC: RFC 8439 (ref. 'CHACHA') == Outdated reference: A later version (-13) exists of draft-ietf-tls-dtls-connection-id-07 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS E. Rescorla 3 Internet-Draft RTFM, Inc. 4 Obsoletes: 6347 (if approved) H. Tschofenig 5 Intended status: Standards Track Arm Limited 6 Expires: 30 November 2020 N. Modadugu 7 Google, Inc. 8 29 May 2020 10 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 11 draft-ietf-tls-dtls13-38 13 Abstract 15 This document specifies Version 1.3 of the Datagram Transport Layer 16 Security (DTLS) protocol. DTLS 1.3 allows client/server applications 17 to communicate over the Internet in a way that is designed to prevent 18 eavesdropping, tampering, and message forgery. 20 The DTLS 1.3 protocol is intentionally based on the Transport Layer 21 Security (TLS) 1.3 protocol and provides equivalent security 22 guarantees with the exception of order protection/non-replayability. 23 Datagram semantics of the underlying transport are preserved by the 24 DTLS protocol. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 30 November 2020. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 73 3. DTLS Design Rationale and Overview . . . . . . . . . . . . . 6 74 3.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 6 75 3.2. Reordering . . . . . . . . . . . . . . . . . . . . . . . 7 76 3.3. Message Size . . . . . . . . . . . . . . . . . . . . . . 7 77 3.4. Replay Detection . . . . . . . . . . . . . . . . . . . . 8 78 4. The DTLS Record Layer . . . . . . . . . . . . . . . . . . . . 8 79 4.1. Determining the Header Format . . . . . . . . . . . . . . 12 80 4.2. Sequence Number and Epoch . . . . . . . . . . . . . . . . 12 81 4.2.1. Processing Guidelines . . . . . . . . . . . . . . . . 13 82 4.2.2. Reconstructing the Sequence Number and Epoch . . . . 13 83 4.2.3. Sequence Number Encryption . . . . . . . . . . . . . 14 84 4.3. Transport Layer Mapping . . . . . . . . . . . . . . . . . 15 85 4.4. PMTU Issues . . . . . . . . . . . . . . . . . . . . . . . 15 86 4.5. Record Payload Protection . . . . . . . . . . . . . . . . 17 87 4.5.1. Anti-Replay . . . . . . . . . . . . . . . . . . . . . 17 88 4.5.2. Handling Invalid Records . . . . . . . . . . . . . . 18 89 4.5.3. AEAD Limits . . . . . . . . . . . . . . . . . . . . . 18 90 5. The DTLS Handshake Protocol . . . . . . . . . . . . . . . . . 20 91 5.1. Denial-of-Service Countermeasures . . . . . . . . . . . . 20 92 5.2. DTLS Handshake Message Format . . . . . . . . . . . . . . 23 93 5.3. ClientHello Message . . . . . . . . . . . . . . . . . . . 25 94 5.4. Handshake Message Fragmentation and Reassembly . . . . . 26 95 5.5. End Of Early Data . . . . . . . . . . . . . . . . . . . . 27 96 5.6. DTLS Handshake Flights . . . . . . . . . . . . . . . . . 27 97 5.7. Timeout and Retransmission . . . . . . . . . . . . . . . 30 98 5.7.1. State Machine . . . . . . . . . . . . . . . . . . . . 31 99 5.7.2. Timer Values . . . . . . . . . . . . . . . . . . . . 34 100 5.7.3. State machine duplication for post-handshake 101 messages . . . . . . . . . . . . . . . . . . . . . . 34 102 5.8. CertificateVerify and Finished Messages . . . . . . . . . 36 103 5.9. Cryptographic Label Prefix . . . . . . . . . . . . . . . 36 104 5.10. Alert Messages . . . . . . . . . . . . . . . . . . . . . 36 105 5.11. Establishing New Associations with Existing Parameters . 36 106 6. Example of Handshake with Timeout and Retransmission . . . . 37 107 6.1. Epoch Values and Rekeying . . . . . . . . . . . . . . . . 39 108 7. ACK Message . . . . . . . . . . . . . . . . . . . . . . . . . 41 109 7.1. Sending ACKs . . . . . . . . . . . . . . . . . . . . . . 42 110 7.2. Receiving ACKs . . . . . . . . . . . . . . . . . . . . . 43 111 7.3. Design Rational . . . . . . . . . . . . . . . . . . . . . 44 112 8. Key Updates . . . . . . . . . . . . . . . . . . . . . . . . . 44 113 9. Connection ID Updates . . . . . . . . . . . . . . . . . . . . 45 114 9.1. Connection ID Example . . . . . . . . . . . . . . . . . . 46 115 10. Application Data Protocol . . . . . . . . . . . . . . . . . . 48 116 11. Security Considerations . . . . . . . . . . . . . . . . . . . 48 117 12. Changes to DTLS 1.2 . . . . . . . . . . . . . . . . . . . . . 49 118 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 119 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 120 14.1. Normative References . . . . . . . . . . . . . . . . . . 50 121 14.2. Informative References . . . . . . . . . . . . . . . . . 51 122 Appendix A. Protocol Data Structures and Constant Values . . . . 53 123 A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 53 124 A.2. Handshake Protocol . . . . . . . . . . . . . . . . . . . 54 125 A.3. ACKs . . . . . . . . . . . . . . . . . . . . . . . . . . 55 126 A.4. Connection ID Management . . . . . . . . . . . . . . . . 56 127 Appendix B. Analysis of Limits on CCM Usage . . . . . . . . . . 56 128 B.1. Confidentiality Limits . . . . . . . . . . . . . . . . . 57 129 B.2. Integrity Limits . . . . . . . . . . . . . . . . . . . . 57 130 B.3. Limits for AEAD_AES_128_CCM_8 . . . . . . . . . . . . . . 58 131 Appendix C. History . . . . . . . . . . . . . . . . . . . . . . 58 132 Appendix D. Working Group Information . . . . . . . . . . . . . 60 133 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 60 134 Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 61 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 137 1. Introduction 139 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH 140 The source for this draft is maintained in GitHub. Suggested changes 141 should be submitted as pull requests at https://github.com/tlswg/ 142 dtls13-spec. Instructions are on that page as well. Editorial 143 changes can be managed in GitHub, but any substantive change should 144 be discussed on the TLS mailing list. 146 The primary goal of the TLS protocol is to establish an 147 authenticated, confidentiality and integrity protected channel 148 between two communicating peers. The TLS protocol is composed of two 149 layers: the TLS Record Protocol and the TLS Handshake Protocol. 150 However, TLS must run over a reliable transport channel - typically 151 TCP [RFC0793]. 153 There are applications that use UDP [RFC0768] as a transport and to 154 offer communication security protection for those applications the 155 Datagram Transport Layer Security (DTLS) protocol has been developed. 156 DTLS is deliberately designed to be as similar to TLS as possible, 157 both to minimize new security invention and to maximize the amount of 158 code and infrastructure reuse. 160 DTLS 1.0 [RFC4347] was originally defined as a delta from TLS 1.1 161 [RFC4346] and DTLS 1.2 [RFC6347] was defined as a series of deltas to 162 TLS 1.2 [RFC5246]. There is no DTLS 1.1; that version number was 163 skipped in order to harmonize version numbers with TLS. This 164 specification describes the most current version of the DTLS protocol 165 based on TLS 1.3 [TLS13]. 167 Implementations that speak both DTLS 1.2 and DTLS 1.3 can 168 interoperate with those that speak only DTLS 1.2 (using DTLS 1.2 of 169 course), just as TLS 1.3 implementations can interoperate with TLS 170 1.2 (see Appendix D of [TLS13] for details). While backwards 171 compatibility with DTLS 1.0 is possible the use of DTLS 1.0 is not 172 recommended as explained in Section 3.1.2 of RFC 7525 [RFC7525]. 174 2. Conventions and Terminology 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 178 "OPTIONAL" in this document are to be interpreted as described in BCP 179 14 [RFC2119] [RFC8174] when, and only when, they appear in all 180 capitals, as shown here. 182 The following terms are used: 184 * client: The endpoint initiating the DTLS connection. 186 * connection: A transport-layer connection between two endpoints. 188 * endpoint: Either the client or server of the connection. 190 * handshake: An initial negotiation between client and server that 191 establishes the parameters of their transactions. 193 * peer: An endpoint. When discussing a particular endpoint, "peer" 194 refers to the endpoint that is remote to the primary subject of 195 discussion. 197 * receiver: An endpoint that is receiving records. 199 * sender: An endpoint that is transmitting records. 201 * session: An association between a client and a server resulting 202 from a handshake. 204 * server: The endpoint which did not initiate the DTLS connection. 206 * CID: Connection ID 208 * MSL: Maximum Segment Lifetime 210 The reader is assumed to be familiar with the TLS 1.3 specification 211 since this document is defined as a delta from TLS 1.3. As in TLS 212 1.3 the HelloRetryRequest has the same format as a ServerHello 213 message but for convenience we use the term HelloRetryRequest 214 throughout this document as if it were a distinct message. 216 The reader is also as to be familiar with 217 [I-D.ietf-tls-dtls-connection-id] as this document applies the CID 218 functionality to DTLS 1.3. 220 Figures in this document illustrate various combinations of the DTLS 221 protocol exchanges and the symbols have the following meaning: 223 * '+' indicates noteworthy extensions sent in the previously noted 224 message. 226 * '*' indicates optional or situation-dependent messages/extensions 227 that are not always sent. 229 * '{}' indicates messages protected using keys derived from a 230 [sender]_handshake_traffic_secret. 232 * '[]' indicates messages protected using keys derived from 233 traffic_secret_N. 235 3. DTLS Design Rationale and Overview 237 The basic design philosophy of DTLS is to construct "TLS over 238 datagram transport". Datagram transport does not require nor provide 239 reliable or in-order delivery of data. The DTLS protocol preserves 240 this property for application data. Applications such as media 241 streaming, Internet telephony, and online gaming use datagram 242 transport for communication due to the delay-sensitive nature of 243 transported data. The behavior of such applications is unchanged 244 when the DTLS protocol is used to secure communication, since the 245 DTLS protocol does not compensate for lost or reordered data traffic. 247 TLS cannot be used directly in datagram environments for the 248 following five reasons: 250 1. TLS relies on an implicit sequence number on records. If a 251 record is not received, then the recipient will use the wrong 252 sequence number when attempting to remove record protection from 253 subsequent records. DTLS solves this problem by adding sequence 254 numbers. 256 2. The TLS handshake is a lock-step cryptographic handshake. 257 Messages must be transmitted and received in a defined order; any 258 other order is an error. DTLS handshake messages are also 259 assigned sequence numbers to enable reassembly in the correct 260 order in case datagrams are lost or reordered. 262 3. During the handshake, messages are implicitly acknowledged by 263 other handshake messages. Some handshake messages, such as the 264 NewSessionTicket message, do not result in any direct response 265 that would allow the sender to detect loss. DTLS adds an 266 acknowledgment message to enable better loss recovery. 268 4. Handshake messages are potentially larger than can be contained 269 in a single datagram. DTLS adds fields to handshake messages to 270 support fragmentation and reassembly. 272 5. Datagram transport protocols, like UDP, are susceptible to 273 abusive behavior effecting denial of service attacks against 274 nonparticipants. DTLS adds a return-routability check that uses 275 the TLS HelloRetryRequest message (see Section 5.1 for details). 277 3.1. Packet Loss 279 DTLS uses a simple retransmission timer to handle packet loss. 280 Figure 1 demonstrates the basic concept, using the first phase of the 281 DTLS handshake: 283 Client Server 284 ------ ------ 285 ClientHello ------> 287 X<-- HelloRetryRequest 288 (lost) 290 [Timer Expires] 292 ClientHello ------> 293 (retransmit) 295 Figure 1: DTLS retransmission example 297 Once the client has transmitted the ClientHello message, it expects 298 to see a HelloRetryRequest or a ServerHello from the server. 299 However, if the server's message is lost, the client knows that 300 either the ClientHello or the response from the server has been lost 301 and retransmits. When the server receives the retransmission, it 302 knows to retransmit. 304 The server also maintains a retransmission timer and retransmits when 305 that timer expires. 307 Note that timeout and retransmission do not apply to the 308 HelloRetryRequest since this would require creating state on the 309 server. The HelloRetryRequest is designed to be small enough that it 310 will not itself be fragmented, thus avoiding concerns about 311 interleaving multiple HelloRetryRequests. 313 3.2. Reordering 315 In DTLS, each handshake message is assigned a specific sequence 316 number. When a peer receives a handshake message, it can quickly 317 determine whether that message is the next message it expects. If it 318 is, then it processes it. If not, it queues it for future handling 319 once all previous messages have been received. 321 3.3. Message Size 323 TLS and DTLS handshake messages can be quite large (in theory up to 324 2^24-1 bytes, in practice many kilobytes). By contrast, UDP 325 datagrams are often limited to less than 1500 bytes if IP 326 fragmentation is not desired. In order to compensate for this 327 limitation, each DTLS handshake message may be fragmented over 328 several DTLS records, each of which is intended to fit in a single 329 UDP datagram. Each DTLS handshake message contains both a fragment 330 offset and a fragment length. Thus, a recipient in possession of all 331 bytes of a handshake message can reassemble the original unfragmented 332 message. 334 3.4. Replay Detection 336 DTLS optionally supports record replay detection. The technique used 337 is the same as in IPsec AH/ESP, by maintaining a bitmap window of 338 received records. Records that are too old to fit in the window and 339 records that have previously been received are silently discarded. 340 The replay detection feature is optional, since packet duplication is 341 not always malicious, but can also occur due to routing errors. 342 Applications may conceivably detect duplicate packets and accordingly 343 modify their data transmission strategy. 345 4. The DTLS Record Layer 347 The DTLS 1.3 record layer is different from the TLS 1.3 record layer 348 and also different from the DTLS 1.2 record layer. 350 1. The DTLSCiphertext structure omits the superfluous version number 351 and type fields. 353 2. DTLS adds an epoch and sequence number to the TLS record header. 354 This sequence number allows the recipient to correctly verify the 355 DTLS MAC. However, the number of bits used for the epoch and 356 sequence number fields in the DTLSCiphertext structure have been 357 reduced from those in previous versions. 359 3. The DTLSCiphertext structure has a variable length header. 361 DTLSPlaintext records are used to send unprotected records and 362 DTLSCiphertext records are used to send protected records. 364 The DTLS record formats are shown below. Unless explicitly stated 365 the meaning of the fields is unchanged from previous TLS / DTLS 366 versions. 368 struct { 369 ContentType type; 370 ProtocolVersion legacy_record_version; 371 uint16 epoch = 0 372 uint48 sequence_number; 373 uint16 length; 374 opaque fragment[DTLSPlaintext.length]; 375 } DTLSPlaintext; 377 struct { 378 opaque content[DTLSPlaintext.length]; 379 ContentType type; 380 uint8 zeros[length_of_padding]; 381 } DTLSInnerPlaintext; 383 struct { 384 opaque unified_hdr[variable]; 385 opaque encrypted_record[length]; 386 } DTLSCiphertext; 388 Figure 2: DTLS 1.3 Record Format 390 unified_hdr: The unified_hdr is a field of variable length, as shown 391 in Figure 3. 393 encrypted_record: Identical to the encrypted_record field in a TLS 394 1.3 record. 396 The DTLSCiphertext header is tightly bit-packed, as shown below: 398 0 1 2 3 4 5 6 7 399 +-+-+-+-+-+-+-+-+ 400 |0|0|1|C|S|L|E E| 401 +-+-+-+-+-+-+-+-+ 402 | Connection ID | Legend: 403 | (if any, | 404 / length as / C - Connection ID (CID) present 405 | negotiated) | S - Sequence number length 406 +-+-+-+-+-+-+-+-+ L - Length present 407 | 8 or 16 bit | E - Epoch 408 |Sequence Number| 409 +-+-+-+-+-+-+-+-+ 410 | 16 bit Length | 411 | (if present) | 412 +-+-+-+-+-+-+-+-+ 414 Figure 3: DTLS 1.3 CipherText Header 416 Fixed Bits: The three high bits of the first byte of the 417 DTLSCiphertext header are set to 001. 419 C: The C bit (0x10) is set if the Connection ID is present. 421 S: The S bit (0x08) indicates the size of the sequence number. 0 422 means an 8-bit sequence number, 1 means 16-bit. 424 L: The L bit (0x04) is set if the length is present. 426 E: The two low bits (0x03) include the low order two bits of the 427 epoch. 429 Connection ID: Variable length CID. The CID functionality is 430 described in [I-D.ietf-tls-dtls-connection-id]. An example can be 431 found in Section 9.1. 433 Sequence Number: The low order 8 or 16 bits of the record sequence 434 number. This value is 16 bits if the S bit is set to 1, and 8 435 bits if the S bit is 0. 437 Length: Identical to the length field in a TLS 1.3 record. 439 As with previous versions of DTLS, multiple DTLSPlaintext and 440 DTLSCiphertext records can be included in the same underlying 441 transport datagram. 443 Figure 4 illustrates different record layer header types. 445 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 446 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 447 | Content Type | |0|0|1|1|1|1|E E| |0|0|1|0|0|0|E E| 448 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 449 | 16 bit | | 16 bit | |8-bit Seq. No. | 450 | Version | |Sequence Number| +-+-+-+-+-+-+-+-+ 451 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | | 452 | 16 bit | | | | Encrypted | 453 | Epoch | / Connection ID / / Record / 454 +-+-+-+-+-+-+-+-+ | | | | 455 | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 456 | | | 16 bit | 457 | 48 bit | | Length | DTLSCiphertext 458 |Sequence Number| +-+-+-+-+-+-+-+-+ Structure 459 | | | | (minimal) 460 | | | Encrypted | 461 +-+-+-+-+-+-+-+-+ / Record / 462 | 16 bit | | | 463 | Length | +-+-+-+-+-+-+-+-+ 464 +-+-+-+-+-+-+-+-+ 465 | | DTLSCiphertext 466 | | Structure 467 / Fragment / (full) 468 | | 469 +-+-+-+-+-+-+-+-+ 471 DTLSPlaintext 472 Structure 474 Figure 4: Header Examples 476 The length field MAY be omitted by clearing the L bit, which means 477 that the record consumes the entire rest of the datagram in the lower 478 level transport. In this case it is not possible to have multiple 479 DTLSCiphertext format records without length fields in the same 480 datagram. Omitting the length field MUST only be used for the last 481 record in a datagram. 483 If a connection ID is negotiated, then it MUST be contained in all 484 datagrams. Sending implementations MUST NOT mix records from 485 multiple DTLS associations in the same datagram. If the second or 486 later record has a connection ID which does not correspond to the 487 same association used for previous records, the rest of the datagram 488 MUST be discarded. 490 When expanded, the epoch and sequence number can be combined into an 491 unpacked RecordNumber structure, as shown below: 493 struct { 494 uint16 epoch; 495 uint48 sequence_number; 496 } RecordNumber; 498 This 64-bit value is used in the ACK message as well as in the 499 "record_sequence_number" input to the AEAD function. 501 The entire header value shown in Figure 4 (but prior to record number 502 encryption) is used as as the additional data value for the AEAD 503 function. For instance, if the minimal variant is used, the AAD is 2 504 octets long. Note that this design is different from the additional 505 data calculation for DTLS 1.2 and for DTLS 1.2 with Connection ID. 507 4.1. Determining the Header Format 509 Implementations can distinguish the two header formats by examining 510 the first byte: 512 * If the first byte is alert(21), handshake(22), or ack(proposed, 513 26), the record MUST be interpreted as a DTLSPlaintext record. 515 * If the first byte is any other value, then receivers MUST check to 516 see if the leading bits of the first byte are 001. If so, the 517 implementation MUST process the record as DTLSCiphertext; the true 518 content type will be inside the protected portion. 520 * Otherwise, the record MUST be rejected as if it had failed 521 deprotection, as described in Section 4.5.2. 523 4.2. Sequence Number and Epoch 525 DTLS uses an explicit or partly explicit sequence number, rather than 526 an implicit one, carried in the sequence_number field of the record. 527 Sequence numbers are maintained separately for each epoch, with each 528 sequence_number initially being 0 for each epoch. 530 The epoch number is initially zero and is incremented each time 531 keying material changes and a sender aims to rekey. More details are 532 provided in Section 6.1. 534 4.2.1. Processing Guidelines 536 Because DTLS records could be reordered, a record from epoch M may be 537 received after epoch N (where N > M) has begun. In general, 538 implementations SHOULD discard records from earlier epochs, but if 539 packet loss causes noticeable problems implementations MAY choose to 540 retain keying material from previous epochs for up to the default MSL 541 specified for TCP [RFC0793] to allow for packet reordering. (Note 542 that the intention here is that implementers use the current guidance 543 from the IETF for MSL, as specified in [RFC0793] or successors not 544 that they attempt to interrogate the MSL that the system TCP stack is 545 using.) 547 Conversely, it is possible for records that are protected with the 548 new epoch to be received prior to the completion of a handshake. For 549 instance, the server may send its Finished message and then start 550 transmitting data. Implementations MAY either buffer or discard such 551 records, though when DTLS is used over reliable transports (e.g., 552 SCTP [RFC4960]), they SHOULD be buffered and processed once the 553 handshake completes. Note that TLS's restrictions on when records 554 may be sent still apply, and the receiver treats the records as if 555 they were sent in the right order. 557 Implementations MUST send retransmissions of lost messages using the 558 same epoch and keying material as the original transmission. 560 Implementations MUST either abandon an association or re-key prior to 561 allowing the sequence number to wrap. 563 Implementations MUST NOT allow the epoch to wrap, but instead MUST 564 establish a new association, terminating the old association. 566 4.2.2. Reconstructing the Sequence Number and Epoch 568 When receiving protected DTLS records message, the recipient does not 569 have a full epoch or sequence number value and so there is some 570 opportunity for ambiguity. Because the full epoch and sequence 571 number are used to compute the per-record nonce, failure to 572 reconstruct these values leads to failure to deprotect the record, 573 and so implementations MAY use a mechanism of their choice to 574 determine the full values. This section provides an algorithm which 575 is comparatively simple and which implementations are RECOMMENDED to 576 follow. 578 If the epoch bits match those of the current epoch, then 579 implementations SHOULD reconstruct the sequence number by computing 580 the full sequence number which is numerically closest to one plus the 581 sequence number of the highest successfully deprotected record. 583 During the handshake phase, the epoch bits unambiguously indicate the 584 correct key to use. After the handshake is complete, if the epoch 585 bits do not match those from the current epoch implementations SHOULD 586 use the most recent past epoch which has matching bits, and then 587 reconstruct the sequence number as described above. 589 4.2.3. Sequence Number Encryption 591 In DTLS 1.3, when records are encrypted, record sequence numbers are 592 also encrypted. The basic pattern is that the underlying encryption 593 algorithm used with the AEAD algorithm is used to generate a mask 594 which is then XORed with the sequence number. 596 When the AEAD is based on AES, then the Mask is generated by 597 computing AES-ECB on the first 16 bytes of the ciphertext: 599 Mask = AES-ECB(sn_key, Ciphertext[0..15]) 601 When the AEAD is based on ChaCha20, then the mask is generated by 602 treating the first 4 bytes of the ciphertext as the block counter and 603 the next 12 bytes as the nonce, passing them to the ChaCha20 block 604 function (Section 2.3 of [CHACHA]): 606 Mask = ChaCha20(sn_key, Ciphertext[0..3], Ciphertext[4..15]) 608 The sn_key is computed as follows: 610 [sender]_sn_key = HKDF-Expand-Label(Secret, "sn" , "", key_length) 612 [sender] denotes the sending side. The Secret value to be used is 613 described in Section 7.3 of [TLS13]. 615 The encrypted sequence number is computed by XORing the leading bytes 616 of the Mask with the sequence number. Decryption is accomplished by 617 the same process. 619 This procedure requires the ciphertext length be at least 16 bytes. 620 Receivers MUST reject shorter records as if they had failed 621 deprotection, as described in Section 4.5.2. Senders MUST pad short 622 plaintexts out (using the conventional record padding mechanism) in 623 order to make a suitable-length ciphertext. Note most of the DTLS 624 AEAD algorithms have a 16-byte authentication tag and need no 625 padding. However, some algorithms such as TLS_AES_128_CCM_8_SHA256 626 have a shorter authentication tag and may require padding for short 627 inputs. 629 Note that sequence number encryption is only applied to the 630 DTLSCiphertext structure and not to the DTLSPlaintext structure, 631 which also contains a sequence number. 633 4.3. Transport Layer Mapping 635 DTLS messages MAY be fragmented into multiple DTLS records. Each 636 DTLS record MUST fit within a single datagram. In order to avoid IP 637 fragmentation, clients of the DTLS record layer SHOULD attempt to 638 size records so that they fit within any PMTU estimates obtained from 639 the record layer. 641 Multiple DTLS records MAY be placed in a single datagram. Records 642 are encoded consecutively. The length field from DTLS records 643 containing that field can be used to determine the boundaries between 644 records. The final record in a datagram can omit the length field. 645 The first byte of the datagram payload MUST be the beginning of a 646 record. Records MUST NOT span datagrams. 648 DTLS records without CIDs do not contain any association identifiers 649 and applications must arrange to multiplex between associations. 650 With UDP, the host/port number is used to look up the appropriate 651 security association for incoming records. 653 Some transports, such as DCCP [RFC4340], provide their own sequence 654 numbers. When carried over those transports, both the DTLS and the 655 transport sequence numbers will be present. Although this introduces 656 a small amount of inefficiency, the transport layer and DTLS sequence 657 numbers serve different purposes; therefore, for conceptual 658 simplicity, it is superior to use both sequence numbers. 660 Some transports provide congestion control for traffic carried over 661 them. If the congestion window is sufficiently narrow, DTLS 662 handshake retransmissions may be held rather than transmitted 663 immediately, potentially leading to timeouts and spurious 664 retransmission. When DTLS is used over such transports, care should 665 be taken not to overrun the likely congestion window. [RFC5238] 666 defines a mapping of DTLS to DCCP that takes these issues into 667 account. 669 4.4. PMTU Issues 671 In general, DTLS's philosophy is to leave PMTU discovery to the 672 application. However, DTLS cannot completely ignore PMTU for three 673 reasons: 675 * The DTLS record framing expands the datagram size, thus lowering 676 the effective PMTU from the application's perspective. 678 * In some implementations, the application may not directly talk to 679 the network, in which case the DTLS stack may absorb ICMP 680 [RFC1191] "Datagram Too Big" indications or ICMPv6 [RFC4443] 681 "Packet Too Big" indications. 683 * The DTLS handshake messages can exceed the PMTU. 685 In order to deal with the first two issues, the DTLS record layer 686 SHOULD behave as described below. 688 If PMTU estimates are available from the underlying transport 689 protocol, they should be made available to upper layer protocols. In 690 particular: 692 * For DTLS over UDP, the upper layer protocol SHOULD be allowed to 693 obtain the PMTU estimate maintained in the IP layer. 695 * For DTLS over DCCP, the upper layer protocol SHOULD be allowed to 696 obtain the current estimate of the PMTU. 698 * For DTLS over TCP or SCTP, which automatically fragment and 699 reassemble datagrams, there is no PMTU limitation. However, the 700 upper layer protocol MUST NOT write any record that exceeds the 701 maximum record size of 2^14 bytes. 703 Note that DTLS does not defend against spoofed ICMP messages; 704 implementations SHOULD ignore any such messages that indicate PMTUs 705 below the IPv4 and IPv6 minimums of 576 and 1280 bytes respectively 707 The DTLS record layer SHOULD allow the upper layer protocol to 708 discover the amount of record expansion expected by the DTLS 709 processing. 711 If there is a transport protocol indication (either via ICMP or via a 712 refusal to send the datagram as in Section 14 of [RFC4340]), then the 713 DTLS record layer MUST inform the upper layer protocol of the error. 715 The DTLS record layer SHOULD NOT interfere with upper layer protocols 716 performing PMTU discovery, whether via [RFC1191] or [RFC4821] 717 mechanisms. In particular: 719 * Where allowed by the underlying transport protocol, the upper 720 layer protocol SHOULD be allowed to set the state of the DF bit 721 (in IPv4) or prohibit local fragmentation (in IPv6). 723 * If the underlying transport protocol allows the application to 724 request PMTU probing (e.g., DCCP), the DTLS record layer SHOULD 725 honor this request. 727 The final issue is the DTLS handshake protocol. From the perspective 728 of the DTLS record layer, this is merely another upper layer 729 protocol. However, DTLS handshakes occur infrequently and involve 730 only a few round trips; therefore, the handshake protocol PMTU 731 handling places a premium on rapid completion over accurate PMTU 732 discovery. In order to allow connections under these circumstances, 733 DTLS implementations SHOULD follow the following rules: 735 * If the DTLS record layer informs the DTLS handshake layer that a 736 message is too big, it SHOULD immediately attempt to fragment it, 737 using any existing information about the PMTU. 739 * If repeated retransmissions do not result in a response, and the 740 PMTU is unknown, subsequent retransmissions SHOULD back off to a 741 smaller record size, fragmenting the handshake message as 742 appropriate. This standard does not specify an exact number of 743 retransmits to attempt before backing off, but 2-3 seems 744 appropriate. 746 4.5. Record Payload Protection 748 Like TLS, DTLS transmits data as a series of protected records. The 749 rest of this section describes the details of that format. 751 4.5.1. Anti-Replay 753 Each DTLS record contains a sequence number to provide replay 754 protection. Sequence number verification SHOULD be performed using 755 the following sliding window procedure, borrowed from Section 3.4.3 756 of [RFC4303]. 758 The received record counter for a session MUST be initialized to zero 759 when that session is established. For each received record, the 760 receiver MUST verify that the record contains a sequence number that 761 does not duplicate the sequence number of any other record received 762 during the lifetime of the session. This check SHOULD happen after 763 deprotecting the record; otherwise the record discard might itself 764 serve as a timing channel for the record number. Note that 765 decompressing the records number is still a potential timing channel 766 for the record number, though a less powerful one than whether it was 767 deprotected. 769 Duplicates are rejected through the use of a sliding receive window. 770 (How the window is implemented is a local matter, but the following 771 text describes the functionality that the implementation must 772 exhibit.) The receiver SHOULD pick a window large enough to handle 773 any plausible reordering, which depends on the data rate. (The 774 receiver does not notify the sender of the window size.) 775 The "right" edge of the window represents the highest validated 776 sequence number value received on the session. Records that contain 777 sequence numbers lower than the "left" edge of the window are 778 rejected. Records falling within the window are checked against a 779 list of received records within the window. An efficient means for 780 performing this check, based on the use of a bit mask, is described 781 in Section 3.4.3 of [RFC4303]. If the received record falls within 782 the window and is new, or if the record is to the right of the 783 window, then the record is new. 785 The window MUST NOT be updated until the record has been deprotected 786 successfully. 788 4.5.2. Handling Invalid Records 790 Unlike TLS, DTLS is resilient in the face of invalid records (e.g., 791 invalid formatting, length, MAC, etc.). In general, invalid records 792 SHOULD be silently discarded, thus preserving the association; 793 however, an error MAY be logged for diagnostic purposes. 794 Implementations which choose to generate an alert instead, MUST 795 generate error alerts to avoid attacks where the attacker repeatedly 796 probes the implementation to see how it responds to various types of 797 error. Note that if DTLS is run over UDP, then any implementation 798 which does this will be extremely susceptible to denial-of-service 799 (DoS) attacks because UDP forgery is so easy. Thus, this practice is 800 NOT RECOMMENDED for such transports, both to increase the reliability 801 of DTLS service and to avoid the risk of spoofing attacks sending 802 traffic to unrelated third parties. 804 If DTLS is being carried over a transport that is resistant to 805 forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts 806 because an attacker will have difficulty forging a datagram that will 807 not be rejected by the transport layer. 809 4.5.3. AEAD Limits 811 Section 5.5 of TLS [TLS13] defines limits on the number of records 812 that can be protected using the same keys. These limits are specific 813 to an AEAD algorithm, and apply equally to DTLS. Implementations 814 SHOULD NOT protect more records than allowed by the limit specified 815 for the negotiated AEAD. Implementations SHOULD initiate a key 816 update before reaching this limit. 818 [TLS13] does not specify a limit for AEAD_AES_128_CCM, but the 819 analysis in Appendix B shows that a limit of 2^23 packets can be used 820 to obtain the same confidentiality protection as the limits specified 821 in TLS. 823 The usage limits defined in TLS 1.3 exist for protection against 824 attacks on confidentiality and apply to successful applications of 825 AEAD protection. The integrity protections in authenticated 826 encryption also depend on limiting the number of attempts to forge 827 packets. TLS achieves this by closing connections after any record 828 fails an authentication check. In comparison, DTLS ignores any 829 packet that cannot be authenticated, allowing multiple forgery 830 attempts. 832 Implementations MUST count the number of received packets that fail 833 authentication with each key. If the number of packets that fail 834 authentication exceed a limit that is specific to the AEAD in use, an 835 implementation SHOULD immediately close the connection. 836 Implementations SHOULD initiate a key update with update_requested 837 before reaching this limit. Once a key update has been initiated, 838 the previous keys can be dropped when the limit is reached rather 839 than closing the connection. Applying a limit reduces the 840 probability that an attacker is able to successfully forge a packet; 841 see [AEBounds] and [ROBUST]. 843 For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305, 844 the limit on the number of records that fail authentication is 2^36. 845 Note that the analysis in [AEBounds] supports a higher limit for the 846 AEAD_AES_128_GCM and AEAD_AES_256_GCM, but this specification 847 recommends a lower limit. For AEAD_AES_128_CCM, the limit on the 848 number of records that fail authentication is 2^23.5; see Appendix B. 850 The AEAD_AES_128_CCM_8 AEAD, as used in TLS_AES_128_CCM_SHA256, does 851 not have a limit on the number of records that fail authentication 852 that both limits the probability of forgery by the same amount and 853 does not expose implementations to the risk of denial of service; see 854 Appendix B.3. Therefore, TLS_AES_128_CCM_SHA256 MUST NOT used in 855 DTLS without additional safeguards against forgery. Implementations 856 MUST set usage limits for AEAD_AES_128_CCM_8 based on an 857 understanding of any additional forgery protections that are used. 859 Any TLS cipher suite that is specified for use with DTLS MUST define 860 limits on the use of the associated AEAD function that preserves 861 margins for both confidentiality and integrity. That is, limits MUST 862 be specified for the number of packets that can be authenticated and 863 for the number packets that can fail authentication. Providing a 864 reference to any analysis upon which values are based - and any 865 assumptions used in that analysis - allows limits to be adapted to 866 varying usage conditions. 868 5. The DTLS Handshake Protocol 870 DTLS 1.3 re-uses the TLS 1.3 handshake messages and flows, with the 871 following changes: 873 1. To handle message loss, reordering, and fragmentation 874 modifications to the handshake header are necessary. 876 2. Retransmission timers are introduced to handle message loss. 878 3. A new ACK content type has been added for reliable message 879 delivery of handshake messages. 881 Note that TLS 1.3 already supports a cookie extension, which is used 882 to prevent denial-of-service attacks. This DoS prevention mechanism 883 is described in more detail below since UDP-based protocols are more 884 vulnerable to amplification attacks than a connection-oriented 885 transport like TCP that performs return-routability checks as part of 886 the connection establishment. 888 DTLS implementations do not use the TLS 1.3 "compatibility mode" 889 described in Section D.4 of [TLS13]. DTLS servers MUST NOT echo the 890 "session_id" value from the client and endpoints MUST NOT send 891 ChangeCipherSpec messages. 893 With these exceptions, the DTLS message formats, flows, and logic are 894 the same as those of TLS 1.3. 896 5.1. Denial-of-Service Countermeasures 898 Datagram security protocols are extremely susceptible to a variety of 899 DoS attacks. Two attacks are of particular concern: 901 1. An attacker can consume excessive resources on the server by 902 transmitting a series of handshake initiation requests, causing 903 the server to allocate state and potentially to perform expensive 904 cryptographic operations. 906 2. An attacker can use the server as an amplifier by sending 907 connection initiation messages with a forged source of the 908 victim. The server then sends its response to the victim 909 machine, thus flooding it. Depending on the selected parameters 910 this response message can be quite large, as it is the case for a 911 Certificate message. 913 In order to counter both of these attacks, DTLS borrows the stateless 914 cookie technique used by Photuris [RFC2522] and IKE [RFC7296]. When 915 the client sends its ClientHello message to the server, the server 916 MAY respond with a HelloRetryRequest message. The HelloRetryRequest 917 message, as well as the cookie extension, is defined in TLS 1.3. The 918 HelloRetryRequest message contains a stateless cookie generated using 919 the technique of [RFC2522]. The client MUST retransmit the 920 ClientHello with the cookie added as an extension. The server then 921 verifies the cookie and proceeds with the handshake only if it is 922 valid. This mechanism forces the attacker/client to be able to 923 receive the cookie, which makes DoS attacks with spoofed IP addresses 924 difficult. This mechanism does not provide any defense against DoS 925 attacks mounted from valid IP addresses. 927 The DTLS 1.3 specification changes how cookies are exchanged compared 928 to DTLS 1.2. DTLS 1.3 re-uses the HelloRetryRequest message and 929 conveys the cookie to the client via an extension. The client 930 receiving the cookie uses the same extension to place the cookie 931 subsequently into a ClientHello message. DTLS 1.2 on the other hand 932 used a separate message, namely the HelloVerifyRequest, to pass a 933 cookie to the client and did not utilize the extension mechanism. 934 For backwards compatibility reasons, the cookie field in the 935 ClientHello is present in DTLS 1.3 but is ignored by a DTLS 1.3 936 compliant server implementation. 938 The exchange is shown in Figure 5. Note that the figure focuses on 939 the cookie exchange; all other extensions are omitted. 941 Client Server 942 ------ ------ 943 ClientHello ------> 945 <----- HelloRetryRequest 946 + cookie 948 ClientHello ------> 949 + cookie 951 [Rest of handshake] 953 Figure 5: DTLS exchange with HelloRetryRequest containing the 954 "cookie" extension 956 The cookie extension is defined in Section 4.2.2 of [TLS13]. When 957 sending the initial ClientHello, the client does not have a cookie 958 yet. In this case, the cookie extension is omitted and the 959 legacy_cookie field in the ClientHello message MUST be set to a zero 960 length vector (i.e., a single zero byte length field). 962 When responding to a HelloRetryRequest, the client MUST create a new 963 ClientHello message following the description in Section 4.1.2 of 964 [TLS13]. 966 If the HelloRetryRequest message is used, the initial ClientHello and 967 the HelloRetryRequest are included in the calculation of the 968 transcript hash. The computation of the message hash for the 969 HelloRetryRequest is done according to the description in 970 Section 4.4.1 of [TLS13]. 972 The handshake transcript is not reset with the second ClientHello and 973 a stateless server-cookie implementation requires the transcript of 974 the HelloRetryRequest to be stored in the cookie or the internal 975 state of the hash algorithm, since only the hash of the transcript is 976 required for the handshake to complete. 978 When the second ClientHello is received, the server can verify that 979 the cookie is valid and that the client can receive packets at the 980 given IP address. If the client's apparent IP address is embedded in 981 the cookie, this prevents an attacker from generating an acceptable 982 ClientHello apparently from another user. 984 One potential attack on this scheme is for the attacker to collect a 985 number of cookies from different addresses where it controls 986 endpoints and then reuse them to attack the server. The server can 987 defend against this attack by changing the secret value frequently, 988 thus invalidating those cookies. If the server wishes to allow 989 legitimate clients to handshake through the transition (e.g., a 990 client received a cookie with Secret 1 and then sent the second 991 ClientHello after the server has changed to Secret 2), the server can 992 have a limited window during which it accepts both secrets. 993 [RFC7296] suggests adding a key identifier to cookies to detect this 994 case. An alternative approach is simply to try verifying with both 995 secrets. It is RECOMMENDED that servers implement a key rotation 996 scheme that allows the server to manage keys with overlapping 997 lifetime. 999 Alternatively, the server can store timestamps in the cookie and 1000 reject cookies that were generated outside a certain interval of 1001 time. 1003 DTLS servers SHOULD perform a cookie exchange whenever a new 1004 handshake is being performed. If the server is being operated in an 1005 environment where amplification is not a problem, the server MAY be 1006 configured not to perform a cookie exchange. The default SHOULD be 1007 that the exchange is performed, however. In addition, the server MAY 1008 choose not to do a cookie exchange when a session is resumed or, more 1009 generically, when the DTLS handshake uses a PSK-based key exchange. 1010 Clients MUST be prepared to do a cookie exchange with every 1011 handshake. 1013 If a server receives a ClientHello with an invalid cookie, it MUST 1014 NOT terminate the handshake with an "illegal_parameter" alert. This 1015 allows the client to restart the connection from scratch without a 1016 cookie. 1018 As described in Section 4.1.4 of [TLS13], clients MUST abort the 1019 handshake with an "unexpected_message" alert in response to any 1020 second HelloRetryRequest which was sent in the same connection (i.e., 1021 where the ClientHello was itself in response to a HelloRetryRequest). 1023 5.2. DTLS Handshake Message Format 1025 In order to support message loss, reordering, and message 1026 fragmentation, DTLS modifies the TLS 1.3 handshake header: 1028 enum { 1029 client_hello(1), 1030 server_hello(2), 1031 new_session_ticket(4), 1032 end_of_early_data(5), 1033 encrypted_extensions(8), 1034 certificate(11), 1035 certificate_request(13), 1036 certificate_verify(15), 1037 finished(20), 1038 key_update(24), 1039 message_hash(254), 1040 (255) 1041 } HandshakeType; 1043 struct { 1044 HandshakeType msg_type; /* handshake type */ 1045 uint24 length; /* bytes in message */ 1046 uint16 message_seq; /* DTLS-required field */ 1047 uint24 fragment_offset; /* DTLS-required field */ 1048 uint24 fragment_length; /* DTLS-required field */ 1049 select (HandshakeType) { 1050 case client_hello: ClientHello; 1051 case server_hello: ServerHello; 1052 case end_of_early_data: EndOfEarlyData; 1053 case encrypted_extensions: EncryptedExtensions; 1054 case certificate_request: CertificateRequest; 1055 case certificate: Certificate; 1056 case certificate_verify: CertificateVerify; 1057 case finished: Finished; 1058 case new_session_ticket: NewSessionTicket; 1059 case key_update: KeyUpdate; 1060 } body; 1061 } Handshake; 1063 The first message each side transmits in each association always has 1064 message_seq = 0. Whenever a new message is generated, the 1065 message_seq value is incremented by one. When a message is 1066 retransmitted, the old message_seq value is re-used, i.e., not 1067 incremented. From the perspective of the DTLS record layer, the 1068 retransmission is a new record. This record will have a new 1069 DTLSPlaintext.sequence_number value. 1071 Note: In DTLS 1.2 the message_seq was reset to zero in case of a 1072 rehandshake (i.e., renegotiation). On the surface, a rehandshake in 1073 DTLS 1.2 shares similarities with a post-handshake message exchange 1074 in DTLS 1.3. However, in DTLS 1.3 the message_seq is not reset to 1075 allow distinguishing a retransmission from a previously sent post- 1076 handshake message from a newly sent post-handshake message. 1078 DTLS implementations maintain (at least notionally) a 1079 next_receive_seq counter. This counter is initially set to zero. 1080 When a handshake message is received, if its message_seq value 1081 matches next_receive_seq, next_receive_seq is incremented and the 1082 message is processed. If the sequence number is less than 1083 next_receive_seq, the message MUST be discarded. If the sequence 1084 number is greater than next_receive_seq, the implementation SHOULD 1085 queue the message but MAY discard it. (This is a simple space/ 1086 bandwidth tradeoff). 1088 In addition to the handshake messages that are deprecated by the TLS 1089 1.3 specification, DTLS 1.3 furthermore deprecates the 1090 HelloVerifyRequest message originally defined in DTLS 1.0. DTLS 1091 1.3-compliant implements MUST NOT use the HelloVerifyRequest to 1092 execute a return-routability check. A dual-stack DTLS 1.2/DTLS 1.3 1093 client MUST, however, be prepared to interact with a DTLS 1.2 server. 1095 5.3. ClientHello Message 1097 The format of the ClientHello used by a DTLS 1.3 client differs from 1098 the TLS 1.3 ClientHello format as shown below. 1100 uint16 ProtocolVersion; 1101 opaque Random[32]; 1103 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 1105 struct { 1106 ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2 1107 Random random; 1108 opaque legacy_session_id<0..32>; 1109 opaque legacy_cookie<0..2^8-1>; // DTLS 1110 CipherSuite cipher_suites<2..2^16-2>; 1111 opaque legacy_compression_methods<1..2^8-1>; 1112 Extension extensions<8..2^16-1>; 1113 } ClientHello; 1115 legacy_version: In previous versions of DTLS, this field was used 1116 for version negotiation and represented the highest version number 1117 supported by the client. Experience has shown that many servers 1118 do not properly implement version negotiation, leading to "version 1119 intolerance" in which the server rejects an otherwise acceptable 1120 ClientHello with a version number higher than it supports. In 1121 DTLS 1.3, the client indicates its version preferences in the 1122 "supported_versions" extension (see Section 4.2.1 of [TLS13]) and 1123 the legacy_version field MUST be set to {254, 253}, which was the 1124 version number for DTLS 1.2. The version fields for DTLS 1.0 and 1125 DTLS 1.2 are 0xfeff and 0xfefd (to match the wire versions) but 1126 the version field for DTLS 1.3 is 0x0304. 1128 random: Same as for TLS 1.3. 1130 legacy_session_id: Same as for TLS 1.3. 1132 legacy_cookie: A DTLS 1.3-only client MUST set the legacy_cookie 1133 field to zero length. If a DTLS 1.3 ClientHello is received with 1134 any other value in this field, the server MUST abort the handshake 1135 with an "illegal_parameter" alert. 1137 cipher_suites: Same as for TLS 1.3. 1139 legacy_compression_methods: Same as for TLS 1.3. 1141 extensions: Same as for TLS 1.3. 1143 5.4. Handshake Message Fragmentation and Reassembly 1145 Each DTLS message MUST fit within a single transport layer datagram. 1146 However, handshake messages are potentially bigger than the maximum 1147 record size. Therefore, DTLS provides a mechanism for fragmenting a 1148 handshake message over a number of records, each of which can be 1149 transmitted separately, thus avoiding IP fragmentation. 1151 When transmitting the handshake message, the sender divides the 1152 message into a series of N contiguous data ranges. The ranges MUST 1153 NOT overlap. The sender then creates N handshake messages, all with 1154 the same message_seq value as the original handshake message. Each 1155 new message is labeled with the fragment_offset (the number of bytes 1156 contained in previous fragments) and the fragment_length (the length 1157 of this fragment). The length field in all messages is the same as 1158 the length field of the original message. An unfragmented message is 1159 a degenerate case with fragment_offset=0 and fragment_length=length. 1160 Each range MUST be delivered in a single UDP datagram. 1162 When a DTLS implementation receives a handshake message fragment, it 1163 MUST buffer it until it has the entire handshake message. DTLS 1164 implementations MUST be able to handle overlapping fragment ranges. 1165 This allows senders to retransmit handshake messages with smaller 1166 fragment sizes if the PMTU estimate changes. 1168 Note that as with TLS, multiple handshake messages may be placed in 1169 the same DTLS record, provided that there is room and that they are 1170 part of the same flight. Thus, there are two acceptable ways to pack 1171 two DTLS messages into the same datagram: in the same record or in 1172 separate records. 1174 5.5. End Of Early Data 1176 The DTLS 1.3 handshake has one important difference from the TLS 1.3 1177 handshake: the EndOfEarlyData message is omitted both from the wire 1178 and the handshake transcript: because DTLS records have epochs, 1179 EndOfEarlyData is not necessary to determine when the early data is 1180 complete, and because DTLS is lossy, attackers can trivially mount 1181 the deletion attacks that EndOfEarlyData prevents in TLS. Servers 1182 SHOULD aggressively age out the epoch 1 keys upon receiving the first 1183 epoch 2 record and SHOULD NOT accept epoch 1 data after the first 1184 epoch 3 record is received. (See Section 6.1 for the definitions of 1185 each epoch.) 1187 5.6. DTLS Handshake Flights 1189 DTLS messages are grouped into a series of message flights, according 1190 to the diagrams below. 1192 Client Server 1194 ClientHello +----------+ 1195 + key_share* | Flight 1 | 1196 + pre_shared_key* --------> +----------+ 1198 +----------+ 1199 <-------- HelloRetryRequest | Flight 2 | 1200 + cookie +----------+ 1202 ClientHello +----------+ 1203 + key_share* | Flight 3 | 1204 + pre_shared_key* --------> +----------+ 1205 + cookie 1207 ServerHello 1208 + key_share* 1209 + pre_shared_key* +----------+ 1210 {EncryptedExtensions} | Flight 4 | 1211 {CertificateRequest*} +----------+ 1212 {Certificate*} 1213 {CertificateVerify*} 1214 <-------- {Finished} 1215 [Application Data*] 1217 {Certificate*} +----------+ 1218 {CertificateVerify*} | Flight 5 | 1219 {Finished} --------> +----------+ 1220 [Application Data] 1222 +----------+ 1223 <-------- [ACK] | Flight 6 | 1224 [Application Data*] +----------+ 1226 [Application Data] <-------> [Application Data] 1228 Figure 6: Message flights for a full DTLS Handshake (with cookie 1229 exchange) 1231 ClientHello +----------+ 1232 + pre_shared_key | Flight 1 | 1233 + key_share* --------> +----------+ 1235 ServerHello 1236 + pre_shared_key +----------+ 1237 + key_share* | Flight 2 | 1238 {EncryptedExtensions} +----------+ 1239 <-------- {Finished} 1240 [Application Data*] 1241 +----------+ 1242 {Finished} --------> | Flight 3 | 1243 [Application Data*] +----------+ 1245 +----------+ 1246 <-------- [ACK] | Flight 4 | 1247 [Application Data*] +----------+ 1249 [Application Data] <-------> [Application Data] 1251 Figure 7: Message flights for resumption and PSK handshake 1252 (without cookie exchange) 1254 Client Server 1256 ClientHello 1257 + early_data 1258 + psk_key_exchange_modes +----------+ 1259 + key_share* | Flight 1 | 1260 + pre_shared_key +----------+ 1261 (Application Data*) --------> 1263 ServerHello 1264 + pre_shared_key 1265 + key_share* +----------+ 1266 {EncryptedExtensions} | Flight 2 | 1267 {Finished} +----------+ 1268 <-------- [Application Data*] 1270 +----------+ 1271 {Finished} --------> | Flight 3 | 1272 [Application Data*] +----------+ 1274 +----------+ 1275 <-------- [ACK] | Flight 4 | 1276 [Application Data*] +----------+ 1278 [Application Data] <-------> [Application Data] 1280 Figure 8: Message flights for the Zero-RTT handshake 1282 Client Server 1284 +----------+ 1285 <-------- [NewSessionTicket] | Flight 1 | 1286 +----------+ 1288 +----------+ 1289 [ACK] --------> | Flight 2 | 1290 +----------+ 1292 Figure 9: Message flights for the new session ticket message 1294 Note: The application data sent by the client is not included in the 1295 timeout and retransmission calculation. 1297 5.7. Timeout and Retransmission 1298 5.7.1. State Machine 1300 DTLS uses a simple timeout and retransmission scheme with the state 1301 machine shown in Figure 10. Because DTLS clients send the first 1302 message (ClientHello), they start in the PREPARING state. DTLS 1303 servers start in the WAITING state, but with empty buffers and no 1304 retransmit timer. 1306 +-----------+ 1307 | PREPARING | 1308 +----------> | | 1309 | | | 1310 | +-----------+ 1311 | | 1312 | | Buffer next flight 1313 | | 1314 | \|/ 1315 | +-----------+ 1316 | | | 1317 | | SENDING |<------------------+ 1318 | | | | 1319 | +-----------+ | 1320 Receive | | | 1321 next | | Send flight or partial | 1322 flight | | flight | 1323 | | | 1324 | | Set retransmit timer | 1325 | \|/ | 1326 | +-----------+ | 1327 | | | | 1328 +------------| WAITING |-------------------+ 1329 | +----->| | Timer expires | 1330 | | +-----------+ | 1331 | | | | | | 1332 | | | | | | 1333 | +----------+ | +--------------------+ 1334 | Receive record | Read retransmit or ACK 1335 Receive | Send ACK | 1336 last | | 1337 flight | | Receive ACK 1338 | | for last flight 1339 \|/ | 1340 | 1341 +-----------+ | 1342 | | <---------+ 1343 | FINISHED | 1344 | | 1345 +-----------+ 1346 | /|\ 1347 | | 1348 | | 1349 +---+ 1351 Server read retransmit 1352 Retransmit ACK 1354 Figure 10: DTLS timeout and retransmission state machine 1356 The state machine has four basic states: PREPARING, SENDING, WAITING, 1357 and FINISHED. 1359 In the PREPARING state, the implementation does whatever computations 1360 are necessary to prepare the next flight of messages. It then 1361 buffers them up for transmission (emptying the buffer first) and 1362 enters the SENDING state. 1364 In the SENDING state, the implementation transmits the buffered 1365 flight of messages. If the implementation has received one or more 1366 ACKs (see Section 7) from the peer, then it SHOULD omit any messages 1367 or message fragments which have already been ACKed. Once the 1368 messages have been sent, the implementation then sets a retransmit 1369 timer and enters the WAITING state. 1371 There are four ways to exit the WAITING state: 1373 1. The retransmit timer expires: the implementation transitions to 1374 the SENDING state, where it retransmits the flight, resets the 1375 retransmit timer, and returns to the WAITING state. 1377 2. The implementation reads an ACK from the peer: upon receiving an 1378 ACK for a partial flight (as mentioned in Section 7.1), the 1379 implementation transitions to the SENDING state, where it 1380 retransmits the unacked portion of the flight, resets the 1381 retransmit timer, and returns to the WAITING state. Upon 1382 receiving an ACK for a complete flight, the implementation 1383 cancels all retransmissions and either remains in WAITING, or, if 1384 the ACK was for the final flight, transitions to FINISHED. 1386 3. The implementation reads a retransmitted flight from the peer: 1387 the implementation transitions to the SENDING state, where it 1388 retransmits the flight, resets the retransmit timer, and returns 1389 to the WAITING state. The rationale here is that the receipt of 1390 a duplicate message is the likely result of timer expiry on the 1391 peer and therefore suggests that part of one's previous flight 1392 was lost. 1394 4. The implementation receives some or all next flight of messages: 1395 if this is the final flight of messages, the implementation 1396 transitions to FINISHED. If the implementation needs to send a 1397 new flight, it transitions to the PREPARING state. Partial reads 1398 (whether partial messages or only some of the messages in the 1399 flight) may also trigger the implementation to send an ACK, as 1400 described in Section 7.1. 1402 Because DTLS clients send the first message (ClientHello), they start 1403 in the PREPARING state. DTLS servers start in the WAITING state, but 1404 with empty buffers and no retransmit timer. 1406 In addition, for at least twice the default MSL defined for 1407 [RFC0793], when in the FINISHED state, the server MUST respond to 1408 retransmission of the client's second flight with a retransmit of its 1409 ACK. 1411 Note that because of packet loss, it is possible for one side to be 1412 sending application data even though the other side has not received 1413 the first side's Finished message. Implementations MUST either 1414 discard or buffer all application data records for the new epoch 1415 until they have received the Finished message for that epoch. 1416 Implementations MAY treat receipt of application data with a new 1417 epoch prior to receipt of the corresponding Finished message as 1418 evidence of reordering or packet loss and retransmit their final 1419 flight immediately, shortcutting the retransmission timer. 1421 5.7.2. Timer Values 1423 Though timer values are the choice of the implementation, mishandling 1424 of the timer can lead to serious congestion problems; for example, if 1425 many instances of a DTLS time out early and retransmit too quickly on 1426 a congested link. Implementations SHOULD use an initial timer value 1427 of 100 msec (the minimum defined in RFC 6298 [RFC6298]) and double 1428 the value at each retransmission, up to no less than the RFC 6298 1429 maximum of 60 seconds. Application specific profiles, such as those 1430 used for the Internet of Things environment, may recommend longer 1431 timer values. Note that a 100 msec timer is recommended rather than 1432 the 3-second RFC 6298 default in order to improve latency for time- 1433 sensitive applications. Because DTLS only uses retransmission for 1434 handshake and not dataflow, the effect on congestion should be 1435 minimal. 1437 Implementations SHOULD retain the current timer value until a 1438 transmission without loss occurs, at which time the value may be 1439 reset to the initial value. After a long period of idleness, no less 1440 than 10 times the current timer value, implementations may reset the 1441 timer to the initial value. 1443 5.7.3. State machine duplication for post-handshake messages 1445 DTLS 1.3 makes use of the following categories of post-handshake 1446 messages: 1448 1. NewSessionTicket 1449 2. KeyUpdate 1451 3. NewConnectionId 1453 4. RequestConnectionId 1455 5. Post-handshake client authentication 1457 Messages of each category can be sent independently, and reliability 1458 is established via independent state machines each of which behaves 1459 as described in Section 5.7.1. For example, if a server sends a 1460 NewSessionTicket and a CertificateRequest message, two independent 1461 state machines will be created. 1463 As explained in the corresponding sections, sending multiple 1464 instances of messages of a given category without having completed 1465 earlier transmissions is allowed for some categories, but not for 1466 others. Specifically, a server MAY send multiple NewSessionTicket 1467 messages at once without awaiting ACKs for earlier NewSessionTicket 1468 first. Likewise, a server MAY send multiple CertificateRequest 1469 messages at once without having completed earlier client 1470 authentication requests before. In contrast, implementations MUST 1471 NOT have send KeyUpdate, NewConnectionId or RequestConnectionId 1472 message if an earlier message of the same type has not yet been 1473 acknowledged. 1475 Note: Except for post-handshake client authentication, which involves 1476 handshake messages in both directions, post-handshake messages are 1477 single-flight, and their respective state machines on the sender side 1478 reduce to waiting for an ACK and retransmitting the original message. 1479 In particular, note that a RequestConnectionId message does not force 1480 the receiver to send a NewConnectionId message in reply, and both 1481 messages are therefore treated independently. 1483 Creating and correctly updating multiple state machines requires 1484 feedback from the handshake logic to the state machine layer, 1485 indicating which message belongs to which state machine. For 1486 example, if a server sends multiple CertificateRequest messages and 1487 receives a Certificate message in response, the corresponding state 1488 machine can only be determined after inspecting the 1489 certificate_request_context field. Similarly, a server sending a 1490 single CertificateRequest and receiving a NewConnectionId message in 1491 response can only decide that the NewConnectionId message should be 1492 treated through an independent state machine after inspecting the 1493 handshake message type. 1495 5.8. CertificateVerify and Finished Messages 1497 CertificateVerify and Finished messages have the same format as in 1498 TLS 1.3. Hash calculations include entire handshake messages, 1499 including DTLS-specific fields: message_seq, fragment_offset, and 1500 fragment_length. However, in order to remove sensitivity to 1501 handshake message fragmentation, the CertificateVerify and the 1502 Finished messages MUST be computed as if each handshake message had 1503 been sent as a single fragment following the algorithm described in 1504 Section 4.4.3 and Section 4.4.4 of [TLS13], respectively. 1506 5.9. Cryptographic Label Prefix 1508 Section 7.1 of [TLS13] specifies that HKDF-Expand-Label uses a label 1509 prefix of "tls13 ". For DTLS 1.3, that label SHALL be "dtls13". 1510 This ensures key separation between DTLS 1.3 and TLS 1.3. Note that 1511 there is no trailing space; this is necessary in order to keep the 1512 overall label size inside of one hash iteration because "DTLS" is one 1513 letter longer than "TLS". 1515 5.10. Alert Messages 1517 Note that Alert messages are not retransmitted at all, even when they 1518 occur in the context of a handshake. However, a DTLS implementation 1519 which would ordinarily issue an alert SHOULD generate a new alert 1520 message if the offending record is received again (e.g., as a 1521 retransmitted handshake message). Implementations SHOULD detect when 1522 a peer is persistently sending bad messages and terminate the local 1523 connection state after such misbehavior is detected. 1525 5.11. Establishing New Associations with Existing Parameters 1527 If a DTLS client-server pair is configured in such a way that 1528 repeated connections happen on the same host/port quartet, then it is 1529 possible that a client will silently abandon one connection and then 1530 initiate another with the same parameters (e.g., after a reboot). 1531 This will appear to the server as a new handshake with epoch=0. In 1532 cases where a server believes it has an existing association on a 1533 given host/port quartet and it receives an epoch=0 ClientHello, it 1534 SHOULD proceed with a new handshake but MUST NOT destroy the existing 1535 association until the client has demonstrated reachability either by 1536 completing a cookie exchange or by completing a complete handshake 1537 including delivering a verifiable Finished message. After a correct 1538 Finished message is received, the server MUST abandon the previous 1539 association to avoid confusion between two valid associations with 1540 overlapping epochs. The reachability requirement prevents off-path/ 1541 blind attackers from destroying associations merely by sending forged 1542 ClientHellos. 1544 Note: it is not always possible to distinguish which association a 1545 given record is from. For instance, if the client performs a 1546 handshake, abandons the connection, and then immediately starts a new 1547 handshake, it may not be possible to tell which connection a given 1548 protected record is for. In these cases, trial decryption MAY be 1549 necessary, though implementations could use CIDs. 1551 6. Example of Handshake with Timeout and Retransmission 1553 The following is an example of a handshake with lost packets and 1554 retransmissions. 1556 Client Server 1557 ------ ------ 1559 Record 0 --------> 1560 ClientHello 1561 (message_seq=0) 1563 X<----- Record 0 1564 (lost) ServerHello 1565 (message_seq=1) 1566 EncryptedExtensions 1567 (message_seq=2) 1568 Certificate 1569 (message_seq=3) 1571 <-------- Record 1 1572 CertificateVerify 1573 (message_seq=4) 1574 Finished 1575 (message_seq=5) 1577 Record 1 --------> 1578 ACK [] 1580 <-------- Record 2 1581 ServerHello 1582 (message_seq=1) 1583 EncryptedExtensions 1584 (message_seq=2) 1585 Certificate 1586 (message_seq=3) 1588 Record 2 --------> 1589 Certificate 1590 (message_seq=1) 1591 CertificateVerify 1592 (message_seq=2) 1593 Finished 1594 (message_seq=3) 1596 <-------- Record 3 1597 ACK [2] 1599 Figure 11: Example DTLS exchange illustrating message loss 1601 6.1. Epoch Values and Rekeying 1603 A recipient of a DTLS message needs to select the correct keying 1604 material in order to process an incoming message. With the 1605 possibility of message loss and re-ordering, an identifier is needed 1606 to determine which cipher state has been used to protect the record 1607 payload. The epoch value fulfills this role in DTLS. In addition to 1608 the TLS 1.3-defined key derivation steps, see Section 7 of [TLS13], a 1609 sender may want to rekey at any time during the lifetime of the 1610 connection. It therefore needs to indicate that it is updating its 1611 sending cryptographic keys. 1613 This version of DTLS assigns dedicated epoch values to messages in 1614 the protocol exchange to allow identification of the correct cipher 1615 state: 1617 * epoch value (0) is used with unencrypted messages. There are 1618 three unencrypted messages in DTLS, namely ClientHello, 1619 ServerHello, and HelloRetryRequest. 1621 * epoch value (1) is used for messages protected using keys derived 1622 from client_early_traffic_secret. Note this epoch is skipped if 1623 the client does not offer early data. 1625 * epoch value (2) is used for messages protected using keys derived 1626 from [sender]_handshake_traffic_secret. Messages transmitted 1627 during the initial handshake, such as EncryptedExtensions, 1628 CertificateRequest, Certificate, CertificateVerify, and Finished 1629 belong to this category. Note, however, post-handshake are 1630 protected under the appropriate application traffic key and are 1631 not included in this category. 1633 * epoch value (3) is used for payloads protected using keys derived 1634 from the initial [sender]_application_traffic_secret_0. This may 1635 include handshake messages, such as post-handshake messages (e.g., 1636 a NewSessionTicket message). 1638 * epoch value (4 to 2^16-1) is used for payloads protected using 1639 keys from the [sender]_application_traffic_secret_N (N>0). 1641 Using these reserved epoch values a receiver knows what cipher state 1642 has been used to encrypt and integrity protect a message. 1643 Implementations that receive a payload with an epoch value for which 1644 no corresponding cipher state can be determined MUST generate a 1645 "unexpected_message" alert. For example, if a client incorrectly 1646 uses epoch value 5 when sending early application data in a 0-RTT 1647 exchange. A server will not be able to compute the appropriate keys 1648 and will therefore have to respond with an alert. 1650 Note that epoch values do not wrap. If a DTLS implementation would 1651 need to wrap the epoch value, it MUST terminate the connection. 1653 The traffic key calculation is described in Section 7.3 of [TLS13]. 1655 Figure 12 illustrates the epoch values in an example DTLS handshake. 1657 Client Server 1658 ------ ------ 1660 ClientHello 1661 (epoch=0) 1662 --------> 1664 <-------- ServerHello 1665 [HelloRetryRequest] 1666 (epoch=0) 1668 ClientHello --------> 1669 (epoch=0) 1671 <-------- ServerHello 1672 (epoch=0) 1673 {EncryptedExtensions} 1674 (epoch=2) 1675 {Certificate} 1676 (epoch=2) 1677 {CertificateVerify} 1678 (epoch=2) 1679 {Finished} 1680 (epoch=2) 1682 {Certificate} --------> 1683 (epoch=2) 1684 {CertificateVerify} 1685 (epoch=2) 1686 {Finished} 1687 (epoch=2) 1689 <-------- [ACK] 1690 (epoch=3) 1692 [Application Data] --------> 1693 (epoch=3) 1695 <-------- [Application Data] 1696 (epoch=3) 1698 Some time later ... 1699 (Post-Handshake Message Exchange) 1701 <-------- [NewSessionTicket] 1702 (epoch=3) 1704 [ACK] --------> 1705 (epoch=3) 1707 Some time later ... 1708 (Rekeying) 1710 <-------- [Application Data] 1711 (epoch=4) 1712 [Application Data] --------> 1713 (epoch=4) 1715 Figure 12: Example DTLS exchange with epoch information 1717 7. ACK Message 1719 The ACK message is used by an endpoint to indicate which handshake 1720 records it has received and processed from the other side. ACK is 1721 not a handshake message but is rather a separate content type, with 1722 code point TBD (proposed, 25). This avoids having ACK being added to 1723 the handshake transcript. Note that ACKs can still be sent in the 1724 same UDP datagram as handshake records. 1726 struct { 1727 RecordNumber record_numbers<0..2^16-1>; 1728 } ACK; 1730 record_numbers: a list of the records containing handshake messages 1731 in the current flight which the endpoint has received and either 1732 processed or buffered, in numerically increasing order. 1734 Implementations MUST NOT acknowledge records containing handshake 1735 messages or fragments which have not been processed or buffered. 1736 Otherwise, deadlock can ensue. As an example, implementations MUST 1737 NOT send ACKs for handshake messages which they discard because they 1738 are not the next expected message. 1740 During the handshake, ACKs only cover the current outstanding flight 1741 (this is possible because DTLS is generally a lockstep protocol). 1742 Thus, an ACK from the server would not cover both the ClientHello and 1743 the client's Certificate. Implementations can accomplish this by 1744 clearing their ACK list upon receiving the start of the next flight. 1746 After the handshake, ACKs SHOULD be sent once for each received and 1747 processed handshake record (potentially subject to some delay) and 1748 MAY cover more than one flight. This includes messages which are 1749 discarded because a previous copy has been received. 1751 During the handshake, ACK records MUST be sent with an epoch that is 1752 equal to or higher than the record which is being acknowledged. Note 1753 that some care is required when processing flights spanning multiple 1754 epochs. For instance, if the client receives only the Server Hello 1755 and Certificate and wishes to ACK them in a single record, it must do 1756 so in epoch 2, as it is required to use an epoch greater than or 1757 equal to 2 and cannot yet send with any greater epoch. 1758 Implementations SHOULD simply use the highest current sending epoch, 1759 which will generally be the highest available. After the handshake, 1760 implementations MUST use the highest available sending epoch. 1762 7.1. Sending ACKs 1764 When an implementation detects a disruption in the receipt of the 1765 current incoming flight, it SHOULD generate an ACK that covers the 1766 messages from that flight which it has received and processed so far. 1767 Implementations have some discretion about which events to treat as 1768 signs of disruption, but it is RECOMMENDED that they generate ACKs 1769 under two circumstances: 1771 * When they receive a message or fragment which is out of order, 1772 either because it is not the next expected message or because it 1773 is not the next piece of the current message. 1775 * When they have received part of a flight and do not immediately 1776 receive the rest of the flight (which may be in the same UDP 1777 datagram). A reasonable approach here is to set a timer for 1/4 1778 the current retransmit timer value when the first record in the 1779 flight is received and then send an ACK when that timer expires. 1781 In general, flights MUST be ACKed unless they are implicitly 1782 acknowledged. In the present specification the following flights are 1783 implicitly acknowledged by the receipt of the next flight, which 1784 generally immediately follows the flight, 1786 1. Handshake flights other than the client's final flight 1788 2. The server's post-handshake CertificateRequest. 1790 ACKs SHOULD NOT be sent for these flights unless generating the 1791 responding flight takes significant time. In this case, 1792 implementations MAY send explicit ACKs for the complete received 1793 flight even though it will eventually also be implicitly acknowledged 1794 through the responding flight. A notable example for this is the 1795 case of post-handshake client authentication in constrained 1796 environments, where generating the CertificateVerify message can take 1797 considerable time on the client. All other flights MUST be ACKed. 1798 Implementations MAY acknowledge the records corresponding to each 1799 transmission of each flight or simply acknowledge the most recent 1800 one. In general, implementations SHOULD ACK as many received packets 1801 as can fit into the ACK record, as this provides the most complete 1802 information and thus reduces the chance of spurious retransmission; 1803 if space is limited, implementations SHOULD favor including records 1804 which have not yet been acknowledged. 1806 Note: While some post-handshake messages follow a request/response 1807 pattern, this does not necessarily imply receipt. For example, a 1808 KeyUpdate sent in response to a KeyUpdate with update_requested does 1809 not implicitly acknowledge that message because the KeyUpdates might 1810 have crossed in flight. 1812 ACKs MUST NOT be sent for other records of any content type other 1813 than handshake or for records which cannot be unprotected. 1815 Note that in some cases it may be necessary to send an ACK which does 1816 not contain any record numbers. For instance, a client might receive 1817 an EncryptedExtensions message prior to receiving a ServerHello. 1818 Because it cannot decrypt the EncryptedExtensions, it cannot safely 1819 acknowledge it (as it might be damaged). If the client does not send 1820 an ACK, the server will eventually retransmit its first flight, but 1821 this might take far longer than the actual round trip time between 1822 client and server. Having the client send an empty ACK shortcuts 1823 this process. 1825 7.2. Receiving ACKs 1827 When an implementation receives an ACK, it SHOULD record that the 1828 messages or message fragments sent in the records being ACKed were 1829 received and omit them from any future retransmissions. Upon receipt 1830 of an ACK that leaves it with only some messages from a flight having 1831 been acknowledged an implementation SHOULD retransmit the 1832 unacknowledged messages or fragments. Note that this requires 1833 implementations to track which messages appear in which records. 1834 Once all the messages in a flight have been acknowledged, the 1835 implementation MUST cancel all retransmissions of that flight. 1836 Implementations MUST treat a record as having been acknowledged if it 1837 appears in any ACK; this prevents spurious retransmission in cases 1838 where a flight is very large and the receiver is forced to elide 1839 acknowledgements for records which have already been ACKed. As noted 1840 above, the receipt of any record responding to a given flight MUST be 1841 taken as an implicit acknowledgement for the entire flight. 1843 7.3. Design Rational 1845 ACK messages are used in two circumstances, namely : 1847 * on sign of disruption, or lack of progress, and 1849 * to indicate complete receipt of the last flight in a handshake. 1851 In the first case the use of the ACK message is optional because the 1852 peer will retransmit in any case and therefore the ACK just allows 1853 for selective retransmission, as opposed to the whole flight 1854 retransmission in previous versions of DTLS. For instance in the 1855 flow shown in Figure 11 if the client does not send the ACK message 1856 when it received and processed record 1 indicating loss of record 0, 1857 the entire flight would be retransmitted. When DTLS 1.3 is used in 1858 deployments with loss networks, such as low-power, long range radio 1859 networks as well as low-power mesh networks, the use of ACKs is 1860 recommended. 1862 The use of the ACK for the second case is mandatory for the proper 1863 functioning of the protocol. For instance, the ACK message sent by 1864 the client in Figure 12, acknowledges receipt and processing of 1865 record 2 (containing the NewSessionTicket message) and if it is not 1866 sent the server will continue retransmission of the NewSessionTicket 1867 indefinitely. 1869 8. Key Updates 1871 As with TLS 1.3, DTLS 1.3 implementations send a KeyUpdate message to 1872 indicate that they are updating their sending keys. As with other 1873 handshake messages with no built-in response, KeyUpdates MUST be 1874 acknowledged. In order to facilitate epoch reconstruction 1875 Section 4.2.2 implementations MUST NOT send with the new keys or send 1876 a new KeyUpdate until the previous KeyUpdate has been acknowledged 1877 (this avoids having too many epochs in active use). 1879 Due to loss and/or re-ordering, DTLS 1.3 implementations may receive 1880 a record with an older epoch than the current one (the requirements 1881 above preclude receiving a newer record). They SHOULD attempt to 1882 process those records with that epoch (see Section 4.2.2 for 1883 information on determining the correct epoch), but MAY opt to discard 1884 such out-of-epoch records. 1886 Due to the possibility of an ACK message for a KeyUpdate being lost 1887 and thereby preventing the sender of the KeyUpdate from updating its 1888 keying material, receivers MUST retain the pre-update keying material 1889 until receipt and successful decryption of a message using the new 1890 keys. 1892 9. Connection ID Updates 1894 If the client and server have negotiated the "connection_id" 1895 extension [I-D.ietf-tls-dtls-connection-id], either side can send a 1896 new CID which it wishes the other side to use in a NewConnectionId 1897 message. 1899 enum { 1900 cid_immediate(0), cid_spare(1), (255) 1901 } ConnectionIdUsage; 1903 opaque ConnectionId<0..2^8-1>; 1905 struct { 1906 ConnectionIds cids<0..2^16-1>; 1907 ConnectionIdUsage usage; 1908 } NewConnectionId; 1910 cid Indicates the set of CIDs which the sender wishes the peer to 1911 use. 1913 usage Indicates whether the new CIDs should be used immediately or 1914 are spare. If usage is set to "cid_immediate", then one of the 1915 new CID MUST be used immediately for all future records. If it is 1916 set to "cid_spare", then either existing or new CID MAY be used. 1918 Endpoints SHOULD use receiver-provided CIDs in the order they were 1919 provided. Endpoints MUST NOT have more than one NewConnectionId 1920 message outstanding. 1922 If the client and server have negotiated the "connection_id" 1923 extension, either side can request a new CID using the 1924 RequestConnectionId message. 1926 struct { 1927 uint8 num_cids; 1928 } RequestConnectionId; 1930 num_cids The number of CIDs desired. 1932 Endpoints SHOULD respond to RequestConnectionId by sending a 1933 NewConnectionId with usage "cid_spare" containing num_cid CIDs soon 1934 as possible. Endpoints MUST NOT send a RequestConnectionId message 1935 when an existing request is still unfulfilled; this implies that 1936 endpoints needs to request new CIDs well in advance. An endpoint MAY 1937 ignore requests, which it considers excessive (though they MUST be 1938 acknowledged as usual). 1940 Endpoints MUST NOT send either of these messages if they did not 1941 negotiate a CID. If an implementation receives these messages when 1942 CIDs were not negotiated, it MUST abort the connection with an 1943 unexpected_message alert. 1945 9.1. Connection ID Example 1947 Below is an example exchange for DTLS 1.3 using a single CID in each 1948 direction. 1950 Note: The connection_id extension is defined in 1951 [I-D.ietf-tls-dtls-connection-id], which is used in ClientHello and 1952 ServerHello messages. 1954 Client Server 1955 ------ ------ 1957 ClientHello 1958 (connection_id=5) 1959 --------> 1961 <-------- HelloRetryRequest 1962 (cookie) 1964 ClientHello --------> 1965 (connection_id=5) 1966 +cookie 1968 <-------- ServerHello 1969 (connection_id=100) 1970 EncryptedExtensions 1971 (cid=5) 1972 Certificate 1973 (cid=5) 1974 CertificateVerify 1975 (cid=5) 1976 Finished 1977 (cid=5) 1979 Certificate --------> 1980 (cid=100) 1981 CertificateVerify 1982 (cid=100) 1983 Finished 1984 (cid=100) 1985 <-------- Ack 1986 (cid=5) 1988 Application Data ========> 1989 (cid=100) 1990 <======== Application Data 1991 (cid=5) 1993 Figure 13: Example DTLS 1.3 Exchange with CIDs 1995 If no CID is negotiated, then the receiver MUST reject any records it 1996 receives that contain a CID. 1998 10. Application Data Protocol 2000 Application data messages are carried by the record layer and are 2001 fragmented and encrypted based on the current connection state. The 2002 messages are treated as transparent data to the record layer. 2004 11. Security Considerations 2006 Security issues are discussed primarily in [TLS13]. 2008 The primary additional security consideration raised by DTLS is that 2009 of denial of service. DTLS includes a cookie exchange designed to 2010 protect against denial of service. However, implementations that do 2011 not use this cookie exchange are still vulnerable to DoS. In 2012 particular, DTLS servers that do not use the cookie exchange may be 2013 used as attack amplifiers even if they themselves are not 2014 experiencing DoS. Therefore, DTLS servers SHOULD use the cookie 2015 exchange unless there is good reason to believe that amplification is 2016 not a threat in their environment. Clients MUST be prepared to do a 2017 cookie exchange with every handshake. 2019 DTLS implementations MUST NOT update their sending address in 2020 response to packets from a different address unless they first 2021 perform some reachability test; no such test is defined in this 2022 specification. Even with such a test, an on-path adversary can also 2023 black-hole traffic or create a reflection attack against third 2024 parties because a DTLS peer has no means to distinguish a genuine 2025 address update event (for example, due to a NAT rebinding) from one 2026 that is malicious. This attack is of concern when there is a large 2027 asymmetry of request/response message sizes. 2029 With the exception of order protection and non-replayability, the 2030 security guarantees for DTLS 1.3 are the same as TLS 1.3. While TLS 2031 always provides order protection and non-replayability, DTLS does not 2032 provide order protection and may not provide replay protection. 2034 Unlike TLS implementations, DTLS implementations SHOULD NOT respond 2035 to invalid records by terminating the connection. 2037 If implementations process out-of-epoch records as recommended in 2038 Section 8, then this creates a denial of service risk since an 2039 adversary could inject records with fake epoch values, forcing the 2040 recipient to compute the next-generation application_traffic_secret 2041 using the HKDF-Expand-Label construct to only find out that the 2042 message was does not pass the AEAD cipher processing. The impact of 2043 this attack is small since the HKDF-Expand-Label only performs 2044 symmetric key hashing operations. Implementations which are 2045 concerned about this form of attack can discard out-of-epoch records. 2047 The security and privacy properties of the CID for DTLS 1.3 builds on 2048 top of what is described in [I-D.ietf-tls-dtls-connection-id]. There 2049 are, however, several improvements: 2051 * The use of the Post-Handshake message allows the client and the 2052 server to update their CIDs and those values are exchanged with 2053 confidentiality protection. 2055 * With multi-homing, an adversary is able to correlate the 2056 communication interaction over the two paths, which adds further 2057 privacy concerns. In order to prevent this, implementations 2058 SHOULD attempt to use fresh CIDs whenever they change local 2059 addresses or ports (though this is not always possible to detect). 2060 The RequestConnectionId message can be used by a peer to ask for 2061 new CIDs to ensure that a pool of suitable CIDs is available. 2063 * Switching CID based on certain events, or even regularly, helps 2064 against tracking by on-path adversaries but the sequence numbers 2065 can still allow linkability. For this reason this specification 2066 defines an algorithm for encrypting sequence numbers, see 2067 Section 4.2.3. Note that sequence number encryption is used for 2068 all encrypted DTLS 1.3 records irrespective of whether a CID is 2069 used or not. Unlike the sequence number, the epoch is not 2070 encrypted. This may improve correlation of packets from a single 2071 connection across different network paths. 2073 * DTLS 1.3 encrypts handshake messages much earlier than in previous 2074 DTLS versions. Therefore, less information identifying the DTLS 2075 client, such as the client certificate, is available to an on-path 2076 adversary. 2078 12. Changes to DTLS 1.2 2080 Since TLS 1.3 introduces a large number of changes to TLS 1.2, the 2081 list of changes from DTLS 1.2 to DTLS 1.3 is equally large. For this 2082 reason this section focuses on the most important changes only. 2084 * New handshake pattern, which leads to a shorter message exchange 2086 * Only AEAD ciphers are supported. Additional data calculation has 2087 been simplified. 2089 * Removed support for weaker and older cryptographic algorithms 2091 * HelloRetryRequest of TLS 1.3 used instead of HelloVerifyRequest 2093 * More flexible ciphersuite negotiation 2094 * New session resumption mechanism 2096 * PSK authentication redefined 2098 * New key derivation hierarchy utilizing a new key derivation 2099 construct 2101 * Improved version negotiation 2103 * Optimized record layer encoding and thereby its size 2105 * Added CID functionality 2107 * Sequence numbers are encrypted. 2109 13. IANA Considerations 2111 IANA is requested to allocate a new value in the "TLS ContentType" 2112 registry for the ACK message, defined in Section 7, with content type 2113 26. The value for the "DTLS-OK" column is "Y". IANA is requested to 2114 reserve the content type range 32-63 so that content types in this 2115 range are not allocated. 2117 IANA is requested to allocate two values in the "TLS Handshake Type" 2118 registry, defined in [TLS13], for RequestConnectionId (TBD), and 2119 NewConnectionId (TBD), as defined in this document. The value for 2120 the "DTLS-OK" columns are "Y". 2122 14. References 2124 14.1. Normative References 2126 [CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 2127 Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, 2128 . 2130 [I-D.ietf-tls-dtls-connection-id] 2131 Rescorla, E., Tschofenig, H., and T. Fossati, "Connection 2132 Identifiers for DTLS 1.2", Work in Progress, Internet- 2133 Draft, draft-ietf-tls-dtls-connection-id-07, 21 October 2134 2019, . 2137 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2138 DOI 10.17487/RFC0768, August 1980, 2139 . 2141 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2142 RFC 793, DOI 10.17487/RFC0793, September 1981, 2143 . 2145 [RFC1191] Mogul, J.C. and S.E. Deering, "Path MTU discovery", 2146 RFC 1191, DOI 10.17487/RFC1191, November 1990, 2147 . 2149 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2150 Requirement Levels", BCP 14, RFC 2119, 2151 DOI 10.17487/RFC2119, March 1997, 2152 . 2154 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2155 Control Message Protocol (ICMPv6) for the Internet 2156 Protocol Version 6 (IPv6) Specification", STD 89, 2157 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2158 . 2160 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 2161 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 2162 . 2164 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 2165 "Computing TCP's Retransmission Timer", RFC 6298, 2166 DOI 10.17487/RFC6298, June 2011, 2167 . 2169 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2170 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2171 May 2017, . 2173 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2174 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2175 . 2177 14.2. Informative References 2179 [AEBounds] Luykx, A. and K. Paterson, "Limits on Authenticated 2180 Encryption Use in TLS", 8 March 2016, 2181 . 2183 [CCM-ANALYSIS] 2184 Jonsson, J., "On the Security of CTR + CBC-MAC", 2185 DOI 10.1007/3-540-36492-7_7, Selected Areas in 2186 Cryptography pp. 76-93, 2003, 2187 . 2189 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 2190 Protocol", RFC 2522, DOI 10.17487/RFC2522, March 1999, 2191 . 2193 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 2194 RFC 4303, DOI 10.17487/RFC4303, December 2005, 2195 . 2197 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2198 Congestion Control Protocol (DCCP)", RFC 4340, 2199 DOI 10.17487/RFC4340, March 2006, 2200 . 2202 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 2203 (TLS) Protocol Version 1.1", RFC 4346, 2204 DOI 10.17487/RFC4346, April 2006, 2205 . 2207 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2208 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 2209 . 2211 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 2212 RFC 4960, DOI 10.17487/RFC4960, September 2007, 2213 . 2215 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 2216 the Datagram Congestion Control Protocol (DCCP)", 2217 RFC 5238, DOI 10.17487/RFC5238, May 2008, 2218 . 2220 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2221 (TLS) Protocol Version 1.2", RFC 5246, 2222 DOI 10.17487/RFC5246, August 2008, 2223 . 2225 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2226 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2227 January 2012, . 2229 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 2230 Kivinen, "Internet Key Exchange Protocol Version 2 2231 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2232 2014, . 2234 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2235 "Recommendations for Secure Use of Transport Layer 2236 Security (TLS) and Datagram Transport Layer Security 2237 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2238 2015, . 2240 [ROBUST] Fischlin, M., Günther, F., and C. Janson, "Robust 2241 Channels: Handling Unreliable Networks in the Record 2242 Layers of QUIC and DTLS", 21 February 2020, 2243 . 2246 Appendix A. Protocol Data Structures and Constant Values 2248 This section provides the normative protocol types and constants 2249 definitions. 2251 A.1. Record Layer 2252 struct { 2253 ContentType type; 2254 ProtocolVersion legacy_record_version; 2255 uint16 epoch = 0 2256 uint48 sequence_number; 2257 uint16 length; 2258 opaque fragment[DTLSPlaintext.length]; 2259 } DTLSPlaintext; 2261 struct { 2262 opaque content[DTLSPlaintext.length]; 2263 ContentType type; 2264 uint8 zeros[length_of_padding]; 2265 } DTLSInnerPlaintext; 2267 struct { 2268 opaque unified_hdr[variable]; 2269 opaque encrypted_record[length]; 2270 } DTLSCiphertext; 2272 0 1 2 3 4 5 6 7 2273 +-+-+-+-+-+-+-+-+ 2274 |0|0|1|C|S|L|E E| 2275 +-+-+-+-+-+-+-+-+ 2276 | Connection ID | Legend: 2277 | (if any, | 2278 / length as / C - Connection ID (CID) present 2279 | negotiated) | S - Sequence number length 2280 +-+-+-+-+-+-+-+-+ L - Length present 2281 | 8 or 16 bit | E - Epoch 2282 |Sequence Number| 2283 +-+-+-+-+-+-+-+-+ 2284 | 16 bit Length | 2285 | (if present) | 2286 +-+-+-+-+-+-+-+-+ 2288 A.2. Handshake Protocol 2290 enum { 2291 hello_request_RESERVED(0), 2292 client_hello(1), 2293 server_hello(2), 2294 hello_verify_request_RESERVED(3), 2295 new_session_ticket(4), 2296 end_of_early_data(5), 2297 hello_retry_request_RESERVED(6), 2298 encrypted_extensions(8), 2299 certificate(11), 2300 server_key_exchange_RESERVED(12), 2301 certificate_request(13), 2302 server_hello_done_RESERVED(14), 2303 certificate_verify(15), 2304 client_key_exchange_RESERVED(16), 2305 finished(20), 2306 key_update(24), 2307 message_hash(254), 2308 (255) 2309 } HandshakeType; 2311 struct { 2312 HandshakeType msg_type; /* handshake type */ 2313 uint24 length; /* bytes in message */ 2314 uint16 message_seq; /* DTLS-required field */ 2315 uint24 fragment_offset; /* DTLS-required field */ 2316 uint24 fragment_length; /* DTLS-required field */ 2317 select (HandshakeType) { 2318 case client_hello: ClientHello; 2319 case server_hello: ServerHello; 2320 case end_of_early_data: EndOfEarlyData; 2321 case encrypted_extensions: EncryptedExtensions; 2322 case certificate_request: CertificateRequest; 2323 case certificate: Certificate; 2324 case certificate_verify: CertificateVerify; 2325 case finished: Finished; 2326 case new_session_ticket: NewSessionTicket; 2327 case key_update: KeyUpdate; 2328 } body; 2329 } Handshake; 2331 uint16 ProtocolVersion; 2332 opaque Random[32]; 2334 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 2336 struct { 2337 ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2 2338 Random random; 2339 opaque legacy_session_id<0..32>; 2340 opaque legacy_cookie<0..2^8-1>; // DTLS 2341 CipherSuite cipher_suites<2..2^16-2>; 2342 opaque legacy_compression_methods<1..2^8-1>; 2343 Extension extensions<8..2^16-1>; 2344 } ClientHello; 2346 A.3. ACKs 2347 struct { 2348 RecordNumber record_numbers<0..2^16-1>; 2349 } ACK; 2351 A.4. Connection ID Management 2353 enum { 2354 cid_immediate(0), cid_spare(1), (255) 2355 } ConnectionIdUsage; 2357 opaque ConnectionId<0..2^8-1>; 2359 struct { 2360 ConnectionIds cids<0..2^16-1>; 2361 ConnectionIdUsage usage; 2362 } NewConnectionId; 2364 struct { 2365 uint8 num_cids; 2366 } RequestConnectionId; 2368 Appendix B. Analysis of Limits on CCM Usage 2370 TLS [TLS13] and [AEBounds] do not specify limits on key usage for 2371 AEAD_AES_128_CCM. However, any AEAD that is used with DTLS requires 2372 limits on use that ensure that both confidentiality and integrity are 2373 preserved. This section documents that analysis for 2374 AEAD_AES_128_CCM. 2376 [CCM-ANALYSIS] is used as the basis of this analysis. The results of 2377 that analysis are used to derive usage limits that are based on those 2378 chosen in [TLS13]. 2380 This analysis uses symbols for multiplication (*), division (/), and 2381 exponentiation (^), plus parentheses for establishing precedence. 2382 The following symbols are also used: 2384 t: The size of the authentication tag in bits. For this cipher, t 2385 is 128. 2387 n: The size of the block function in bits. For this cipher, n is 2388 128. 2390 l: The number of blocks in each packet (see below). 2392 q: The number of genuine packets created and protected by endpoints. 2393 This value is the bound on the number of packets that can be 2394 protected before updating keys. 2396 v: The number of forged packets that endpoints will accept. This 2397 value is the bound on the number of forged packets that an 2398 endpoint can reject before updating keys. 2400 The analysis of AEAD_AES_128_CCM relies on a count of the number of 2401 block operations involved in producing each message. For simplicity, 2402 and to match the analysis of other AEAD functions in [AEBounds], this 2403 analysis assumes a packet length of 2^10 blocks and a packet size 2404 limit of 2^14. 2406 For AEAD_AES_128_CCM, the total number of block cipher operations is 2407 the sum of: the length of the associated data in blocks, the length 2408 of the ciphertext in blocks, the length of the plaintext in blocks, 2409 plus 1. In this analysis, this is simplified to a value of twice the 2410 maximum length of a record in blocks (that is, "2l = 2^11"). This 2411 simplification is based on the associated data being limited to one 2412 block. 2414 B.1. Confidentiality Limits 2416 For confidentiality, Theorem 2 in [CCM-ANALYSIS] establishes that an 2417 attacker gains a distinguishing advantage over an ideal pseudorandom 2418 permutation (PRP) of no more than: 2420 (2l * q)^2 / 2^n 2422 For a target advantage of 2^-60, which matches that used by [TLS13], 2423 this results in the relation: 2425 q <= 2^23 2427 That is, endpoints cannot protect more than 2^23 packets with the 2428 same set of keys without causing an attacker to gain an larger 2429 advantage than the target of 2^-60. 2431 B.2. Integrity Limits 2433 For integrity, Theorem 1 in [CCM-ANALYSIS] establishes that an 2434 attacker gains an advantage over an ideal PRP of no more than: 2436 v / 2^t + (2l * (v + q))^2 / 2^n 2438 The goal is to limit this advantage to 2^-57, to match the target in 2439 [TLS13]. As "t" and "n" are both 128, the first term is negligible 2440 relative to the second, so that term can be removed without a 2441 significant effect on the result. This produces the relation: 2443 v + q <= 2^24.5 2444 Using the previously-established value of 2^23 for "q" and rounding, 2445 this leads to an upper limit on "v" of 2^23.5. That is, endpoints 2446 cannot attempt to authenticate more than 2^23.5 packets with the same 2447 set of keys without causing an attacker to gain an larger advantage 2448 than the target of 2^-57. 2450 B.3. Limits for AEAD_AES_128_CCM_8 2452 The TLS_AES_128_CCM_8_SHA256 cipher suite uses the AEAD_AES_128_CCM_8 2453 function, which uses a short authentication tag (that is, t=64). 2455 The confidentiality limits of AEAD_AES_128_CCM_8 are the same as 2456 those for AEAD_AES_128_CCM, as this does not depend on the tag 2457 length; see Appendix B.1. 2459 The shorter tag length of 64 bits means that the simplification used 2460 in Appendix B.2 does not apply to AEAD_AES_128_CCM_8. If the goal is 2461 to preserve the same margins as other cipher suites, then the limit 2462 on forgeries is largely dictated by the first term of the advantage 2463 formula: 2465 v <= 2^7 2467 As this represents attempts to fail authentication, applying this 2468 limit might be feasible in some environments. However, applying this 2469 limit in an implementation intended for general use exposes 2470 connections to an inexpensive denial of service attack. 2472 This analysis supports the view that TLS_AES_128_CCM_8_SHA256 is not 2473 suitable for general use. Specifically, TLS_AES_128_CCM_8_SHA256 2474 cannot be used without additional measures to prevent forgery of 2475 records, or to mitigate the effect of forgeries. This might require 2476 understanding the constraints that exist in a particular deployment 2477 or application. For instance, it might be possible to set a 2478 different target for the advantage an attacker gains based on an 2479 understanding of the constraints imposed on a specific usage of DTLS. 2481 Appendix C. History 2483 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 2485 IETF Drafts 2487 draft-38 - Ban implicit connection IDs (*) - ACKs are processed as 2488 the union. 2490 draft-37: - Fix the other place where we have ACK. 2492 draft-36: - Some editorial changes. - Changed the content type to not 2493 conflict with existing allocations (*) 2495 draft-35: - I-D.ietf-tls-dtls-connection-id became a normative 2496 reference - Removed duplicate reference to I-D.ietf-tls-dtls- 2497 connection-id. - Fix figure 11 to have the right numbers andno cookie 2498 in message 1. - Clarify when you can ACK. - Clarify additional data 2499 computation. 2501 draft-33: - Key separation between TLS and DTLS. Issue #72. 2503 draft-32: - Editorial improvements and clarifications. 2505 draft-31: - Editorial improvements in text and figures. - Added 2506 normative reference to ChaCha20 and Poly1305. 2508 draft-30: - Changed record format - Added text about end of early 2509 data - Changed format of the Connection ID Update message - Added 2510 Appendix A "Protocol Data Structures and Constant Values" 2512 draft-29: - Added support for sequence number encryption - Update to 2513 new record format - Emphasize that compatibility mode isn't used. 2515 draft-28: - Version bump to align with TLS 1.3 pre-RFC version. 2517 draft-27: - Incorporated unified header format. - Added support for 2518 CIDs. 2520 draft-04 - 26: - Submissions to align with TLS 1.3 draft versions 2522 draft-03 - Only update keys after KeyUpdate is ACKed. 2524 draft-02 - Shorten the protected record header and introduce an 2525 ultra-short version of the record header. - Reintroduce KeyUpdate, 2526 which works properly now that we have ACK. - Clarify the ACK rules. 2528 draft-01 - Restructured the ACK to contain a list of records and also 2529 be a record rather than a handshake message. 2531 draft-00 - First IETF Draft 2533 Personal Drafts draft-01 - Alignment with version -19 of the TLS 1.3 2534 specification 2536 draft-00 2538 * Initial version using TLS 1.3 as a baseline. 2540 * Use of epoch values instead of KeyUpdate message 2542 * Use of cookie extension instead of cookie field in ClientHello and 2543 HelloVerifyRequest messages 2545 * Added ACK message 2547 * Text about sequence number handling 2549 Appendix D. Working Group Information 2551 RFC EDITOR: PLEASE REMOVE THIS SECTION. 2553 The discussion list for the IETF TLS working group is located at the 2554 e-mail address tls@ietf.org (mailto:tls@ietf.org). Information on 2555 the group and information on how to subscribe to the list is at 2556 https://www1.ietf.org/mailman/listinfo/tls 2557 (https://www1.ietf.org/mailman/listinfo/tls) 2559 Archives of the list can be found at: https://www.ietf.org/mail- 2560 archive/web/tls/current/index.html (https://www.ietf.org/mail- 2561 archive/web/tls/current/index.html) 2563 Appendix E. Contributors 2565 Many people have contributed to previous DTLS versions and they are 2566 acknowledged in prior versions of DTLS specifications or in the 2567 referenced specifications. The sequence number encryption concept is 2568 taken from the QUIC specification. We would like to thank the 2569 authors of the QUIC specification for their work. Felix Guenther and 2570 Martin Thomson contributed the analysis in Appendix B. 2572 In addition, we would like to thank: 2574 * David Benjamin 2575 Google 2576 davidben@google.com 2578 * Thomas Fossati 2579 Arm Limited 2580 Thomas.Fossati@arm.com 2582 * Tobias Gondrom 2583 Huawei 2584 tobias.gondrom@gondrom.org 2586 * Felix Guenther 2587 TU Darmstadt 2588 mail@felixguenther.info 2590 * Ilari Liusvaara 2591 Independent 2592 ilariliusvaara@welho.com 2594 * Martin Thomson 2595 Mozilla 2596 martin.thomson@gmail.com 2598 * Christopher A. Wood 2599 Apple Inc. 2600 cawood@apple.com 2602 * Yin Xinxing 2603 Huawei 2604 yinxinxing@huawei.com 2606 * Hanno Becker 2607 Arm Limited 2608 Hanno.Becker@arm.com 2610 Appendix F. Acknowledgements 2612 We would like to thank Jonathan Hammell for his review comments. 2614 Authors' Addresses 2616 Eric Rescorla 2617 RTFM, Inc. 2619 Email: ekr@rtfm.com 2621 Hannes Tschofenig 2622 Arm Limited 2624 Email: hannes.tschofenig@arm.com 2626 Nagendra Modadugu 2627 Google, Inc. 2629 Email: nagendra@cs.stanford.edu