idnits 2.17.1 draft-ietf-tls-dtls13-35.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 (7 March 2020) is 1504 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 2146 -- Looks like a reference, but probably isn't: '2' on line 2148 == Missing Reference: 'ACK' is mentioned on line 1589, but not defined == Missing Reference: 'NewSessionTicket' is mentioned on line 1586, but not defined -- Looks like a reference, but probably isn't: '1' on line 1463 ** 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 (~~), 5 warnings (==), 12 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: 8 September 2020 N. Modadugu 7 Google, Inc. 8 7 March 2020 10 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 11 draft-ietf-tls-dtls13-35 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 8 September 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 . . . . . . . . . . . . . 5 74 3.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 6 75 3.2. Reordering . . . . . . . . . . . . . . . . . . . . . . . 7 76 3.3. Message Size . . . . . . . . . . . . . . . . . . . . . . 7 77 3.4. Replay Detection . . . . . . . . . . . . . . . . . . . . 7 78 4. The DTLS Record Layer . . . . . . . . . . . . . . . . . . . . 7 79 4.1. Determining the Header Format . . . . . . . . . . . . . . 11 80 4.2. Sequence Number and Epoch . . . . . . . . . . . . . . . . 11 81 4.2.1. Processing Guidelines . . . . . . . . . . . . . . . . 12 82 4.2.2. Reconstructing the Sequence Number and Epoch . . . . 12 83 4.2.3. Sequence Number Encryption . . . . . . . . . . . . . 13 84 4.3. Transport Layer Mapping . . . . . . . . . . . . . . . . . 14 85 4.4. PMTU Issues . . . . . . . . . . . . . . . . . . . . . . . 14 86 4.5. Record Payload Protection . . . . . . . . . . . . . . . . 16 87 4.5.1. Anti-Replay . . . . . . . . . . . . . . . . . . . . . 16 88 4.5.2. Handling Invalid Records . . . . . . . . . . . . . . 17 89 5. The DTLS Handshake Protocol . . . . . . . . . . . . . . . . . 17 90 5.1. Denial-of-Service Countermeasures . . . . . . . . . . . . 18 91 5.2. DTLS Handshake Message Format . . . . . . . . . . . . . . 21 92 5.3. ClientHello Message . . . . . . . . . . . . . . . . . . . 22 93 5.4. Handshake Message Fragmentation and Reassembly . . . . . 23 94 5.5. End Of Early Data . . . . . . . . . . . . . . . . . . . . 24 95 5.6. DTLS Handshake Flights . . . . . . . . . . . . . . . . . 24 96 5.7. Timeout and Retransmission . . . . . . . . . . . . . . . 27 97 5.7.1. State Machine . . . . . . . . . . . . . . . . . . . . 28 98 5.7.2. Timer Values . . . . . . . . . . . . . . . . . . . . 31 99 5.8. CertificateVerify and Finished Messages . . . . . . . . . 32 100 5.9. Cryptographic Label Prefix . . . . . . . . . . . . . . . 32 101 5.10. Alert Messages . . . . . . . . . . . . . . . . . . . . . 32 102 5.11. Establishing New Associations with Existing Parameters . 32 103 6. Example of Handshake with Timeout and Retransmission . . . . 33 104 6.1. Epoch Values and Rekeying . . . . . . . . . . . . . . . . 35 105 7. ACK Message . . . . . . . . . . . . . . . . . . . . . . . . . 37 106 7.1. Sending ACKs . . . . . . . . . . . . . . . . . . . . . . 38 107 7.2. Receiving ACKs . . . . . . . . . . . . . . . . . . . . . 39 108 8. Key Updates . . . . . . . . . . . . . . . . . . . . . . . . . 39 109 9. Connection ID Updates . . . . . . . . . . . . . . . . . . . . 40 110 9.1. Connection ID Example . . . . . . . . . . . . . . . . . . 41 111 10. Application Data Protocol . . . . . . . . . . . . . . . . . . 43 112 11. Security Considerations . . . . . . . . . . . . . . . . . . . 43 113 12. Changes to DTLS 1.2 . . . . . . . . . . . . . . . . . . . . . 44 114 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 115 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 116 14.1. Normative References . . . . . . . . . . . . . . . . . . 45 117 14.2. Informative References . . . . . . . . . . . . . . . . . 46 118 Appendix A. Protocol Data Structures and Constant Values . . . . 47 119 A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 47 120 A.2. Handshake Protocol . . . . . . . . . . . . . . . . . . . 48 121 A.3. ACKs . . . . . . . . . . . . . . . . . . . . . . . . . . 49 122 A.4. Connection ID Management . . . . . . . . . . . . . . . . 50 123 Appendix B. History . . . . . . . . . . . . . . . . . . . . . . 50 124 Appendix C. Working Group Information . . . . . . . . . . . . . 51 125 Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 52 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 128 1. Introduction 130 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH 132 The source for this draft is maintained in GitHub. Suggested changes 133 should be submitted as pull requests at https://github.com/tlswg/ 134 dtls13-spec. Instructions are on that page as well. Editorial 135 changes can be managed in GitHub, but any substantive change should 136 be discussed on the TLS mailing list. 138 The primary goal of the TLS protocol is to provide privacy and data 139 integrity between two communicating peers. The TLS protocol is 140 composed of two layers: the TLS Record Protocol and the TLS Handshake 141 Protocol. However, TLS must run over a reliable transport channel - 142 typically TCP [RFC0793]. 144 There are applications that use UDP [RFC0768] as a transport and to 145 offer communication security protection for those applications the 146 Datagram Transport Layer Security (DTLS) protocol has been designed. 147 DTLS is deliberately designed to be as similar to TLS as possible, 148 both to minimize new security invention and to maximize the amount of 149 code and infrastructure reuse. 151 DTLS 1.0 [RFC4347] was originally defined as a delta from TLS 1.1 152 [RFC4346] and DTLS 1.2 [RFC6347] was defined as a series of deltas to 153 TLS 1.2 [RFC5246]. There is no DTLS 1.1; that version number was 154 skipped in order to harmonize version numbers with TLS. This 155 specification describes the most current version of the DTLS protocol 156 based on TLS 1.3 [TLS13]. 158 Implementations that speak both DTLS 1.2 and DTLS 1.3 can 159 interoperate with those that speak only DTLS 1.2 (using DTLS 1.2 of 160 course), just as TLS 1.3 implementations can interoperate with TLS 161 1.2 (see Appendix D of [TLS13] for details). While backwards 162 compatibility with DTLS 1.0 is possible the use of DTLS 1.0 is not 163 recommended as explained in Section 3.1.2 of RFC 7525 [RFC7525]. 165 2. Conventions and Terminology 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 169 "OPTIONAL" in this document are to be interpreted as described in BCP 170 14 [RFC2119] [RFC8174] when, and only when, they appear in all 171 capitals, as shown here. 173 The following terms are used: 175 * client: The endpoint initiating the DTLS connection. 177 * connection: A transport-layer connection between two endpoints. 179 * endpoint: Either the client or server of the connection. 181 * handshake: An initial negotiation between client and server that 182 establishes the parameters of their transactions. 184 * peer: An endpoint. When discussing a particular endpoint, "peer" 185 refers to the endpoint that is remote to the primary subject of 186 discussion. 188 * receiver: An endpoint that is receiving records. 190 * sender: An endpoint that is transmitting records. 192 * session: An association between a client and a server resulting 193 from a handshake. 195 * server: The endpoint which did not initiate the DTLS connection. 197 * CID: Connection ID 199 The reader is assumed to be familiar with the TLS 1.3 specification 200 since this document is defined as a delta from TLS 1.3. As in TLS 201 1.3 the HelloRetryRequest has the same format as a ServerHello 202 message but for convenience we use the term HelloRetryRequest 203 throughout this document as if it were a distinct message. 205 Figures in this document illustrate various combinations of the DTLS 206 protocol exchanges and the symbols have the following meaning: 208 * '+' indicates noteworthy extensions sent in the previously noted 209 message. 211 * '*' indicates optional or situation-dependent messages/extensions 212 that are not always sent. 214 * '{}' indicates messages protected using keys derived from a 215 [sender]_handshake_traffic_secret. 217 * '[]' indicates messages protected using keys derived from 218 traffic_secret_N. 220 3. DTLS Design Rationale and Overview 222 The basic design philosophy of DTLS is to construct "TLS over 223 datagram transport". Datagram transport does not require nor provide 224 reliable or in-order delivery of data. The DTLS protocol preserves 225 this property for application data. Applications such as media 226 streaming, Internet telephony, and online gaming use datagram 227 transport for communication due to the delay-sensitive nature of 228 transported data. The behavior of such applications is unchanged 229 when the DTLS protocol is used to secure communication, since the 230 DTLS protocol does not compensate for lost or reordered data traffic. 232 TLS cannot be used directly in datagram environments for the 233 following five reasons: 235 1. TLS relies on an implicit sequence number on records. If a 236 record is not received, then the recipient will use the wrong 237 sequence number when attempting to remove record protection from 238 subsequent records. DTLS solves this problem by adding sequence 239 numbers. 241 2. The TLS handshake is a lock-step cryptographic handshake. 242 Messages must be transmitted and received in a defined order; any 243 other order is an error. DTLS handshake messages are also 244 assigned sequence numbers to enable reassembly in the correct 245 order in case datagrams are lost or reordered. 247 3. During the handshake, messages are implicitly acknowledged by 248 other handshake messages, but the last flight of messages and 249 post-handshake messages (such as the NewSessionTicket message) do 250 not result in any direct response that would allow the sender to 251 detect loss. DTLS adds an acknowledgment message to enable 252 better loss recovery. 254 4. Handshake messages are potentially larger than can be contained 255 in a single datagram. DTLS adds fields to handshake messages to 256 support fragmentation and reassembly. 258 5. Datagram transport protocols, like UDP, are susceptible to 259 abusive behavior effecting denial of service attacks against 260 nonparticipants. DTLS adds a return-routability check that uses 261 the TLS HelloRetryRequest message (see Section 5.1 for details). 263 3.1. Packet Loss 265 DTLS uses a simple retransmission timer to handle packet loss. 266 Figure 1 demonstrates the basic concept, using the first phase of the 267 DTLS handshake: 269 Client Server 270 ------ ------ 271 ClientHello ------> 273 X<-- HelloRetryRequest 274 (lost) 276 [Timer Expires] 278 ClientHello ------> 279 (retransmit) 281 Figure 1: DTLS retransmission example 283 Once the client has transmitted the ClientHello message, it expects 284 to see a HelloRetryRequest or a ServerHello from the server. 285 However, if the server's message is lost, the client knows that 286 either the ClientHello or the response from the server has been lost 287 and retransmits. When the server receives the retransmission, it 288 knows to retransmit. 290 The server also maintains a retransmission timer and retransmits when 291 that timer expires. 293 Note that timeout and retransmission do not apply to the 294 HelloRetryRequest since this would require creating state on the 295 server. The HelloRetryRequest is designed to be small enough that it 296 will not itself be fragmented, thus avoiding concerns about 297 interleaving multiple HelloRetryRequests. 299 3.2. Reordering 301 In DTLS, each handshake message is assigned a specific sequence 302 number. When a peer receives a handshake message, it can quickly 303 determine whether that message is the next message it expects. If it 304 is, then it processes it. If not, it queues it for future handling 305 once all previous messages have been received. 307 3.3. Message Size 309 TLS and DTLS handshake messages can be quite large (in theory up to 310 2^24-1 bytes, in practice many kilobytes). By contrast, UDP 311 datagrams are often limited to less than 1500 bytes if IP 312 fragmentation is not desired. In order to compensate for this 313 limitation, each DTLS handshake message may be fragmented over 314 several DTLS records, each of which is intended to fit in a single 315 UDP datagram. Each DTLS handshake message contains both a fragment 316 offset and a fragment length. Thus, a recipient in possession of all 317 bytes of a handshake message can reassemble the original unfragmented 318 message. 320 3.4. Replay Detection 322 DTLS optionally supports record replay detection. The technique used 323 is the same as in IPsec AH/ESP, by maintaining a bitmap window of 324 received records. Records that are too old to fit in the window and 325 records that have previously been received are silently discarded. 326 The replay detection feature is optional, since packet duplication is 327 not always malicious, but can also occur due to routing errors. 328 Applications may conceivably detect duplicate packets and accordingly 329 modify their data transmission strategy. 331 4. The DTLS Record Layer 333 The DTLS record layer is different from the TLS 1.3 record layer. 335 1. The DTLSCiphertext structure omits the superfluous version number 336 and type fields. 338 2. DTLS adds an epoch and sequence number to the TLS record header. 339 This sequence number allows the recipient to correctly verify the 340 DTLS MAC. However, the number of bits used for the epoch and 341 sequence number fields in the DTLSCiphertext structure have been 342 reduced from those in previous versions. 344 3. The DTLSCiphertext structure has a variable length header. 346 Note that the DTLS 1.3 record layer is different from the DTLS 1.2 347 record layer. 349 DTLSPlaintext records are used to send unprotected records and 350 DTLSCiphertext records are used to send protected records. 352 The DTLS record formats are shown below. Unless explicitly stated 353 the meaning of the fields is unchanged from previous TLS / DTLS 354 versions. 356 struct { 357 ContentType type; 358 ProtocolVersion legacy_record_version; 359 uint16 epoch = 0 // DTLS field 360 uint48 sequence_number; // DTLS field 361 uint16 length; 362 opaque fragment[DTLSPlaintext.length]; 363 } DTLSPlaintext; 365 struct { 366 opaque content[DTLSPlaintext.length]; 367 ContentType type; 368 uint8 zeros[length_of_padding]; 369 } DTLSInnerPlaintext; 371 struct { 372 opaque unified_hdr[variable]; 373 opaque encrypted_record[length]; 374 } DTLSCiphertext; 376 Figure 2: DTLS 1.3 Record Format 378 unified_hdr: The unified_hdr is a field of variable length, as shown 379 in Figure 3. 381 encrypted_record: Identical to the encrypted_record field in a TLS 382 1.3 record. 384 The DTLSCiphertext header is tightly bit-packed, as shown below: 386 0 1 2 3 4 5 6 7 387 +-+-+-+-+-+-+-+-+ 388 |0|0|1|C|S|L|E E| 389 +-+-+-+-+-+-+-+-+ 390 | Connection ID | Legend: 391 | (if any, | 392 / length as / C - Connection ID (CID) present 393 | negotiated) | S - Sequence number length 394 +-+-+-+-+-+-+-+-+ L - Length present 395 | 8 or 16 bit | E - Epoch 396 |Sequence Number| 397 +-+-+-+-+-+-+-+-+ 398 | 16 bit Length | 399 | (if present) | 400 +-+-+-+-+-+-+-+-+ 402 Figure 3: DTLS 1.3 CipherText Header 404 Fixed Bits: The three high bits of the first byte of the 405 DTLSCiphertext header are set to 001. 407 C: The C bit (0x10) is set if the Connection ID is present. 409 S: The S bit (0x08) indicates the size of the sequence number. 0 410 means an 8-bit sequence number, 1 means 16-bit. 412 L: The L bit (0x04) is set if the length is present. 414 E: The two low bits (0x03) include the low order two bits of the 415 epoch. 417 Connection ID: Variable length CID. The CID concept is described in 418 [I-D.ietf-tls-dtls-connection-id]. An example can be found in 419 Section 9.1. 421 Sequence Number: The low order 8 or 16 bits of the record sequence 422 number. This value is 16 bits if the S bit is set to 1, and 8 423 bits if the S bit is 0. 425 Length: Identical to the length field in a TLS 1.3 record. 427 As with previous versions of DTLS, multiple DTLSPlaintext and 428 DTLSCiphertext records can be included in the same underlying 429 transport datagram. 431 Figure 4 illustrates different record layer header types. 433 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 434 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 435 | Content Type | |0|0|1|1|1|1|E E| |0|0|1|0|0|0|E E| 436 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 437 | 16 bit | | 16 bit | |8-bit Seq. No. | 438 | Version | |Sequence Number| +-+-+-+-+-+-+-+-+ 439 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | | 440 | 16 bit | | | | Encrypted | 441 | Epoch | / Connection ID / / Record / 442 +-+-+-+-+-+-+-+-+ | | | | 443 | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 444 | | | 16 bit | 445 | 48 bit | | Length | DTLSCiphertext 446 |Sequence Number| +-+-+-+-+-+-+-+-+ Structure 447 | | | | (minimal) 448 | | | Encrypted | 449 +-+-+-+-+-+-+-+-+ / Record / 450 | 16 bit | | | 451 | Length | +-+-+-+-+-+-+-+-+ 452 +-+-+-+-+-+-+-+-+ 453 | | DTLSCiphertext 454 | | Structure 455 / Fragment / (full) 456 | | 457 +-+-+-+-+-+-+-+-+ 459 DTLSPlaintext 460 Structure 462 Figure 4: Header Examples 464 The length field MAY be omitted by clearing the L bit, which means 465 that the record consumes the entire rest of the datagram in the lower 466 level transport. In this case it is not possible to have multiple 467 DTLSCiphertext format records without length fields in the same 468 datagram. Omitting the length field MUST only be used for the last 469 record in a datagram. 471 Implementations which send multiple records in the same datagram 472 SHOULD omit the connection id from all but the first record; 473 receiving implementations MUST assume that any subsequent records 474 without connection IDs belong to the same assocatiation. Sending 475 implementations MUST NOT mix records from multiple DTLS associations 476 in the same datagram. If the second or later record has a connection 477 ID which does not correspond to the same association used for 478 previous records, the rest of the datagram MUST be discarded. 480 When expanded, the epoch and sequence number can be combined into an 481 unpacked RecordNumber structure, as shown below: 483 struct { 484 uint16 epoch; 485 uint48 sequence_number; 486 } RecordNumber; 488 This 64-bit value is used in the ACK message as well as in the 489 "record_sequence_number" input to the AEAD function. 491 The entire header value shown in Figure 4 (but prior to record number 492 encryption) is used as as the additional data value for the AEAD 493 function. For instance, if the minimal variant is used, the AAD is 2 494 octets long. Note that this design is different from the additional 495 data calculation for DTLS 1.2 and for DTLS 1.2 with Connection ID. 497 4.1. Determining the Header Format 499 Implementations can distinguish the two header formats by examining 500 the first byte: 502 * If the first byte is alert(21), handshake(22), or ack(proposed, 503 25), the record MUST be interpreted as a DTLSPlaintext record. 505 * If the first byte is any other value, then receivers MUST check to 506 see if the leading bits of the first byte are 001. If so, the 507 implementation MUST process the record as DTLSCiphertext; the true 508 content type will be inside the protected portion. 510 * Otherwise, the record MUST be rejected as if it had failed 511 deprotection, as described in Section 4.5.2. 513 4.2. Sequence Number and Epoch 515 DTLS uses an explicit or partly explicit sequence number, rather than 516 an implicit one, carried in the sequence_number field of the record. 517 Sequence numbers are maintained separately for each epoch, with each 518 sequence_number initially being 0 for each epoch. 520 The epoch number is initially zero and is incremented each time 521 keying material changes and a sender aims to rekey. More details are 522 provided in Section 6.1. 524 4.2.1. Processing Guidelines 526 Because DTLS records could be reordered, a record from epoch M may be 527 received after epoch N (where N > M) has begun. In general, 528 implementations SHOULD discard records from earlier epochs, but if 529 packet loss causes noticeable problems implementations MAY choose to 530 retain keying material from previous epochs for up to the default MSL 531 specified for TCP [RFC0793] to allow for packet reordering. (Note 532 that the intention here is that implementers use the current guidance 533 from the IETF for MSL, as specified in [RFC0793] or successors not 534 that they attempt to interrogate the MSL that the system TCP stack is 535 using.) 537 Conversely, it is possible for records that are protected with the 538 new epoch to be received prior to the completion of a handshake. For 539 instance, the server may send its Finished message and then start 540 transmitting data. Implementations MAY either buffer or discard such 541 records, though when DTLS is used over reliable transports (e.g., 542 SCTP [RFC4960]), they SHOULD be buffered and processed once the 543 handshake completes. Note that TLS's restrictions on when records 544 may be sent still apply, and the receiver treats the records as if 545 they were sent in the right order. 547 Implementations MUST send retransmissions of lost messages using the 548 same epoch and keying material as the original transmission. 550 Implementations MUST either abandon an association or re-key prior to 551 allowing the sequence number to wrap. 553 Implementations MUST NOT allow the epoch to wrap, but instead MUST 554 establish a new association, terminating the old association. 556 4.2.2. Reconstructing the Sequence Number and Epoch 558 When receiving protected DTLS records message, the recipient does not 559 have a full epoch or sequence number value and so there is some 560 opportunity for ambiguity. Because the full epoch and sequence 561 number are used to compute the per-record nonce, failure to 562 reconstruct these values leads to failure to deprotect the record, 563 and so implementations MAY use a mechanism of their choice to 564 determine the full values. This section provides an algorithm which 565 is comparatively simple and which implementations are RECOMMENDED to 566 follow. 568 If the epoch bits match those of the current epoch, then 569 implementations SHOULD reconstruct the sequence number by computing 570 the full sequence number which is numerically closest to one plus the 571 sequence number of the highest successfully deprotected record. 573 During the handshake phase, the epoch bits unambiguously indicate the 574 correct key to use. After the handshake is complete, if the epoch 575 bits do not match those from the current epoch implementations SHOULD 576 use the most recent past epoch which has matching bits, and then 577 reconstruct the sequence number as described above. 579 4.2.3. Sequence Number Encryption 581 In DTLS 1.3, when records are encrypted, record sequence numbers are 582 also encrypted. The basic pattern is that the underlying encryption 583 algorithm used with the AEAD algorithm is used to generate a mask 584 which is then XORed with the sequence number. 586 When the AEAD is based on AES, then the Mask is generated by 587 computing AES-ECB on the first 16 bytes of the ciphertext: 589 Mask = AES-ECB(sn_key, Ciphertext[0..15]) 591 When the AEAD is based on ChaCha20, then the mask is generated by 592 treating the first 4 bytes of the ciphertext as the block counter and 593 the next 12 bytes as the nonce, passing them to the ChaCha20 block 594 function (Section 2.3 of [CHACHA]): 596 Mask = ChaCha20(sn_key, Ciphertext[0..3], Ciphertext[4..15]) 598 The sn_key is computed as follows: 600 [sender]_sn_key = HKDF-Expand-Label(Secret, "sn" , "", key_length) 602 [sender] denotes the sending side. The Secret value to be used is 603 described in Section 7.3 of [TLS13]. 605 The encrypted sequence number is computed by XORing the leading bytes 606 of the Mask with the sequence number. Decryption is accomplished by 607 the same process. 609 This procedure requires the ciphertext length be at least 16 bytes. 610 Receivers MUST reject shorter records as if they had failed 611 deprotection, as described in Section 4.5.2. Senders MUST pad short 612 plaintexts out (using the conventional record padding mechanism) in 613 order to make a suitable-length ciphertext. Note most of the DTLS 614 AEAD algorithms have a 16-byte authentication tag and need no 615 padding. However, some algorithms such as TLS_AES_128_CCM_8_SHA256 616 have a shorter authentication tag and may require padding for short 617 inputs. 619 Note that sequence number encryption is only applied to the 620 DTLSCiphertext structure and not to the DTLSPlaintext structure, 621 which also contains a sequence number. 623 4.3. Transport Layer Mapping 625 DTLS messages MAY be fragmented into multiple DTLS records. Each 626 DTLS record MUST fit within a single datagram. In order to avoid IP 627 fragmentation, clients of the DTLS record layer SHOULD attempt to 628 size records so that they fit within any PMTU estimates obtained from 629 the record layer. 631 Multiple DTLS records MAY be placed in a single datagram. Records 632 are encoded consecutively. The length field from DTLS records 633 containing that field can be used to determine the boundaries between 634 records. The final record in a datagram can omit the length field. 635 The first byte of the datagram payload MUST be the beginning of a 636 record. Records MUST NOT span datagrams. 638 DTLS records, as defined in this document, do not contain any 639 association identifiers and applications must arrange to multiplex 640 between associations. With UDP, the host/port number is used to look 641 up the appropriate security association for incoming records. 642 However, the CID extension defined in 643 [I-D.ietf-tls-dtls-connection-id] adds an association identifier to 644 DTLS records. 646 Some transports, such as DCCP [RFC4340], provide their own sequence 647 numbers. When carried over those transports, both the DTLS and the 648 transport sequence numbers will be present. Although this introduces 649 a small amount of inefficiency, the transport layer and DTLS sequence 650 numbers serve different purposes; therefore, for conceptual 651 simplicity, it is superior to use both sequence numbers. 653 Some transports provide congestion control for traffic carried over 654 them. If the congestion window is sufficiently narrow, DTLS 655 handshake retransmissions may be held rather than transmitted 656 immediately, potentially leading to timeouts and spurious 657 retransmission. When DTLS is used over such transports, care should 658 be taken not to overrun the likely congestion window. [RFC5238] 659 defines a mapping of DTLS to DCCP that takes these issues into 660 account. 662 4.4. PMTU Issues 664 In general, DTLS's philosophy is to leave PMTU discovery to the 665 application. However, DTLS cannot completely ignore PMTU for three 666 reasons: 668 * The DTLS record framing expands the datagram size, thus lowering 669 the effective PMTU from the application's perspective. 671 * In some implementations, the application may not directly talk to 672 the network, in which case the DTLS stack may absorb ICMP 673 [RFC1191] "Datagram Too Big" indications or ICMPv6 [RFC4443] 674 "Packet Too Big" indications. 676 * The DTLS handshake messages can exceed the PMTU. 678 In order to deal with the first two issues, the DTLS record layer 679 SHOULD behave as described below. 681 If PMTU estimates are available from the underlying transport 682 protocol, they should be made available to upper layer protocols. In 683 particular: 685 * For DTLS over UDP, the upper layer protocol SHOULD be allowed to 686 obtain the PMTU estimate maintained in the IP layer. 688 * For DTLS over DCCP, the upper layer protocol SHOULD be allowed to 689 obtain the current estimate of the PMTU. 691 * For DTLS over TCP or SCTP, which automatically fragment and 692 reassemble datagrams, there is no PMTU limitation. However, the 693 upper layer protocol MUST NOT write any record that exceeds the 694 maximum record size of 2^14 bytes. 696 Note that DTLS does not defend against spoofed ICMP messages; 697 implementations SHOULD ignore any such messages that indicate PMTUs 698 below the IPv4 and IPv6 minimums of 576 and 1280 bytes respectively 700 The DTLS record layer SHOULD allow the upper layer protocol to 701 discover the amount of record expansion expected by the DTLS 702 processing. 704 If there is a transport protocol indication (either via ICMP or via a 705 refusal to send the datagram as in Section 14 of [RFC4340]), then the 706 DTLS record layer MUST inform the upper layer protocol of the error. 708 The DTLS record layer SHOULD NOT interfere with upper layer protocols 709 performing PMTU discovery, whether via [RFC1191] or [RFC4821] 710 mechanisms. In particular: 712 * Where allowed by the underlying transport protocol, the upper 713 layer protocol SHOULD be allowed to set the state of the DF bit 714 (in IPv4) or prohibit local fragmentation (in IPv6). 716 * If the underlying transport protocol allows the application to 717 request PMTU probing (e.g., DCCP), the DTLS record layer SHOULD 718 honor this request. 720 The final issue is the DTLS handshake protocol. From the perspective 721 of the DTLS record layer, this is merely another upper layer 722 protocol. However, DTLS handshakes occur infrequently and involve 723 only a few round trips; therefore, the handshake protocol PMTU 724 handling places a premium on rapid completion over accurate PMTU 725 discovery. In order to allow connections under these circumstances, 726 DTLS implementations SHOULD follow the following rules: 728 * If the DTLS record layer informs the DTLS handshake layer that a 729 message is too big, it SHOULD immediately attempt to fragment it, 730 using any existing information about the PMTU. 732 * If repeated retransmissions do not result in a response, and the 733 PMTU is unknown, subsequent retransmissions SHOULD back off to a 734 smaller record size, fragmenting the handshake message as 735 appropriate. This standard does not specify an exact number of 736 retransmits to attempt before backing off, but 2-3 seems 737 appropriate. 739 4.5. Record Payload Protection 741 Like TLS, DTLS transmits data as a series of protected records. The 742 rest of this section describes the details of that format. 744 4.5.1. Anti-Replay 746 Each DTLS record contains a sequence number to provide replay 747 protection. Sequence number verification SHOULD be performed using 748 the following sliding window procedure, borrowed from Section 3.4.3 749 of [RFC4303]. 751 The received record counter for a session MUST be initialized to zero 752 when that session is established. For each received record, the 753 receiver MUST verify that the record contains a sequence number that 754 does not duplicate the sequence number of any other record received 755 during the lifetime of the session. This check SHOULD happen after 756 deprotecting the record; otherwise the record discard might itself 757 serve as a timing channel for the record number. Note that 758 decompressing the records number is still a potential timing channel 759 for the record number, though a less powerful one than whether it was 760 deprotected. 762 Duplicates are rejected through the use of a sliding receive window. 763 (How the window is implemented is a local matter, but the following 764 text describes the functionality that the implementation must 765 exhibit.) The receiver SHOULD pick a window large enough to handle 766 any plausible reordering, which depends on the data rate. (The 767 receiver does not notify the sender of the window size.) 769 The "right" edge of the window represents the highest validated 770 sequence number value received on the session. Records that contain 771 sequence numbers lower than the "left" edge of the window are 772 rejected. Records falling within the window are checked against a 773 list of received records within the window. An efficient means for 774 performing this check, based on the use of a bit mask, is described 775 in Section 3.4.3 of [RFC4303]. If the received record falls within 776 the window and is new, or if the record is to the right of the 777 window, then the record is new. 779 The window MUST NOT be updated until the record has been deprotected 780 successfully. 782 4.5.2. Handling Invalid Records 784 Unlike TLS, DTLS is resilient in the face of invalid records (e.g., 785 invalid formatting, length, MAC, etc.). In general, invalid records 786 SHOULD be silently discarded, thus preserving the association; 787 however, an error MAY be logged for diagnostic purposes. 788 Implementations which choose to generate an alert instead, MUST 789 generate error alerts to avoid attacks where the attacker repeatedly 790 probes the implementation to see how it responds to various types of 791 error. Note that if DTLS is run over UDP, then any implementation 792 which does this will be extremely susceptible to denial-of-service 793 (DoS) attacks because UDP forgery is so easy. Thus, this practice is 794 NOT RECOMMENDED for such transports, both to increase the reliability 795 of DTLS service and to avoid the risk of spoofing attacks sending 796 traffic to unrelated third parties. 798 If DTLS is being carried over a transport that is resistant to 799 forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts 800 because an attacker will have difficulty forging a datagram that will 801 not be rejected by the transport layer. 803 5. The DTLS Handshake Protocol 805 DTLS 1.3 re-uses the TLS 1.3 handshake messages and flows, with the 806 following changes: 808 1. To handle message loss, reordering, and fragmentation 809 modifications to the handshake header are necessary. 811 2. Retransmission timers are introduced to handle message loss. 813 3. A new ACK content type has been added for reliable message 814 delivery of handshake messages. 816 Note that TLS 1.3 already supports a cookie extension, which is used 817 to prevent denial-of-service attacks. This DoS prevention mechanism 818 is described in more detail below since UDP-based protocols are more 819 vulnerable to amplification attacks than a connection-oriented 820 transport like TCP that performs return-routability checks as part of 821 the connection establishment. 823 DTLS implementations do not use the TLS 1.3 "compatibility mode" 824 described in Section D.4 of [TLS13]. DTLS servers MUST NOT echo the 825 "session_id" value from the client and endpoints MUST NOT send 826 ChangeCipherSpec messages. 828 With these exceptions, the DTLS message formats, flows, and logic are 829 the same as those of TLS 1.3. 831 5.1. Denial-of-Service Countermeasures 833 Datagram security protocols are extremely susceptible to a variety of 834 DoS attacks. Two attacks are of particular concern: 836 1. An attacker can consume excessive resources on the server by 837 transmitting a series of handshake initiation requests, causing 838 the server to allocate state and potentially to perform expensive 839 cryptographic operations. 841 2. An attacker can use the server as an amplifier by sending 842 connection initiation messages with a forged source of the 843 victim. The server then sends its response to the victim 844 machine, thus flooding it. Depending on the selected parameters 845 this response message can be quite large, as it is the case for a 846 Certificate message. 848 In order to counter both of these attacks, DTLS borrows the stateless 849 cookie technique used by Photuris [RFC2522] and IKE [RFC7296]. When 850 the client sends its ClientHello message to the server, the server 851 MAY respond with a HelloRetryRequest message. The HelloRetryRequest 852 message, as well as the cookie extension, is defined in TLS 1.3. The 853 HelloRetryRequest message contains a stateless cookie generated using 854 the technique of [RFC2522]. The client MUST retransmit the 855 ClientHello with the cookie added as an extension. The server then 856 verifies the cookie and proceeds with the handshake only if it is 857 valid. This mechanism forces the attacker/client to be able to 858 receive the cookie, which makes DoS attacks with spoofed IP addresses 859 difficult. This mechanism does not provide any defense against DoS 860 attacks mounted from valid IP addresses. 862 The DTLS 1.3 specification changes the way how cookies are exchanged 863 compared to DTLS 1.2. DTLS 1.3 re-uses the HelloRetryRequest message 864 and conveys the cookie to the client via an extension. The client 865 receiving the cookie uses the same extension to place the cookie 866 subsequently into a ClientHello message. DTLS 1.2 on the other hand 867 used a separate message, namely the HelloVerifyRequest, to pass a 868 cookie to the client and did not utilize the extension mechanism. 869 For backwards compatibility reasons, the cookie field in the 870 ClientHello is present in DTLS 1.3 but is ignored by a DTLS 1.3 871 compliant server implementation. 873 The exchange is shown in Figure 5. Note that the figure focuses on 874 the cookie exchange; all other extensions are omitted. 876 Client Server 877 ------ ------ 878 ClientHello ------> 880 <----- HelloRetryRequest 881 + cookie 883 ClientHello ------> 884 + cookie 886 [Rest of handshake] 888 Figure 5: DTLS exchange with HelloRetryRequest containing the 889 "cookie" extension 891 The cookie extension is defined in Section 4.2.2 of [TLS13]. When 892 sending the initial ClientHello, the client does not have a cookie 893 yet. In this case, the cookie extension is omitted and the 894 legacy_cookie field in the ClientHello message MUST be set to a zero 895 length vector (i.e., a single zero byte length field). 897 When responding to a HelloRetryRequest, the client MUST create a new 898 ClientHello message following the description in Section 4.1.2 of 899 [TLS13]. 901 If the HelloRetryRequest message is used, the initial ClientHello and 902 the HelloRetryRequest are included in the calculation of the 903 transcript hash. The computation of the message hash for the 904 HelloRetryRequest is done according to the description in 905 Section 4.4.1 of [TLS13]. 907 The handshake transcript is not reset with the second ClientHello and 908 a stateless server-cookie implementation requires the transcript of 909 the HelloRetryRequest to be stored in the cookie or the internal 910 state of the hash algorithm, since only the hash of the transcript is 911 required for the handshake to complete. 913 When the second ClientHello is received, the server can verify that 914 the cookie is valid and that the client can receive packets at the 915 given IP address. If the client's apparent IP address is embedded in 916 the cookie, this prevents an attacker from generating an acceptable 917 ClientHello apparently from another user. 919 One potential attack on this scheme is for the attacker to collect a 920 number of cookies from different addresses where it controls 921 endpoints and then reuse them to attack the server. The server can 922 defend against this attack by changing the secret value frequently, 923 thus invalidating those cookies. If the server wishes to allow 924 legitimate clients to handshake through the transition (e.g., a 925 client received a cookie with Secret 1 and then sent the second 926 ClientHello after the server has changed to Secret 2), the server can 927 have a limited window during which it accepts both secrets. 928 [RFC7296] suggests adding a key identifier to cookies to detect this 929 case. An alternative approach is simply to try verifying with both 930 secrets. It is RECOMMENDED that servers implement a key rotation 931 scheme that allows the server to manage keys with overlapping 932 lifetime. 934 Alternatively, the server can store timestamps in the cookie and 935 reject cookies that were generated outside a certain interval of 936 time. 938 DTLS servers SHOULD perform a cookie exchange whenever a new 939 handshake is being performed. If the server is being operated in an 940 environment where amplification is not a problem, the server MAY be 941 configured not to perform a cookie exchange. The default SHOULD be 942 that the exchange is performed, however. In addition, the server MAY 943 choose not to do a cookie exchange when a session is resumed. 944 Clients MUST be prepared to do a cookie exchange with every 945 handshake. 947 If a server receives a ClientHello with an invalid cookie, it MUST 948 NOT terminate the handshake with an "illegal_parameter" alert. This 949 allows the client to restart the connection from scratch without a 950 cookie. 952 As described in Section 4.1.4 of [TLS13], clients MUST abort the 953 handshake with an "unexpected_message" alert in response to any 954 second HelloRetryRequest which was sent in the same connection (i.e., 955 where the ClientHello was itself in response to a HelloRetryRequest). 957 5.2. DTLS Handshake Message Format 959 In order to support message loss, reordering, and message 960 fragmentation, DTLS modifies the TLS 1.3 handshake header: 962 enum { 963 client_hello(1), 964 server_hello(2), 965 new_session_ticket(4), 966 end_of_early_data(5), 967 encrypted_extensions(8), 968 certificate(11), 969 certificate_request(13), 970 certificate_verify(15), 971 finished(20), 972 key_update(24), 973 message_hash(254), 974 (255) 975 } HandshakeType; 977 struct { 978 HandshakeType msg_type; /* handshake type */ 979 uint24 length; /* bytes in message */ 980 uint16 message_seq; /* DTLS-required field */ 981 uint24 fragment_offset; /* DTLS-required field */ 982 uint24 fragment_length; /* DTLS-required field */ 983 select (HandshakeType) { 984 case client_hello: ClientHello; 985 case server_hello: ServerHello; 986 case end_of_early_data: EndOfEarlyData; 987 case encrypted_extensions: EncryptedExtensions; 988 case certificate_request: CertificateRequest; 989 case certificate: Certificate; 990 case certificate_verify: CertificateVerify; 991 case finished: Finished; 992 case new_session_ticket: NewSessionTicket; 993 case key_update: KeyUpdate; 994 } body; 995 } Handshake; 997 The first message each side transmits in each association always has 998 message_seq = 0. Whenever a new message is generated, the 999 message_seq value is incremented by one. When a message is 1000 retransmitted, the old message_seq value is re-used, i.e., not 1001 incremented. From the perspective of the DTLS record layer, the 1002 retransmission is a new record. This record will have a new 1003 DTLSPlaintext.sequence_number value. 1005 Note: In DTLS 1.2 the message_seq was reset to zero in case of a 1006 rehandshake (i.e., renegotiation). On the surface, a rehandshake in 1007 DTLS 1.2 shares similarities with a post-handshake message exchange 1008 in DTLS 1.3. However, in DTLS 1.3 the message_seq is not reset to 1009 allow distinguishing a retransmission from a previously sent post- 1010 handshake message from a newly sent post-handshake message. 1012 DTLS implementations maintain (at least notionally) a 1013 next_receive_seq counter. This counter is initially set to zero. 1014 When a handshake message is received, if its message_seq value 1015 matches next_receive_seq, next_receive_seq is incremented and the 1016 message is processed. If the sequence number is less than 1017 next_receive_seq, the message MUST be discarded. If the sequence 1018 number is greater than next_receive_seq, the implementation SHOULD 1019 queue the message but MAY discard it. (This is a simple space/ 1020 bandwidth tradeoff). 1022 In addition to the handshake messages that are deprecated by the TLS 1023 1.3 specification, DTLS 1.3 furthermore deprecates the 1024 HelloVerifyRequest message originally defined in DTLS 1.0. DTLS 1025 1.3-compliant implements MUST NOT use the HelloVerifyRequest to 1026 execute a return-routability check. A dual-stack DTLS 1.2/DTLS 1.3 1027 client MUST, however, be prepared to interact with a DTLS 1.2 server. 1029 5.3. ClientHello Message 1031 The format of the ClientHello used by a DTLS 1.3 client differs from 1032 the TLS 1.3 ClientHello format as shown below. 1034 uint16 ProtocolVersion; 1035 opaque Random[32]; 1037 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 1039 struct { 1040 ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2 1041 Random random; 1042 opaque legacy_session_id<0..32>; 1043 opaque legacy_cookie<0..2^8-1>; // DTLS 1044 CipherSuite cipher_suites<2..2^16-2>; 1045 opaque legacy_compression_methods<1..2^8-1>; 1046 Extension extensions<8..2^16-1>; 1047 } ClientHello; 1049 legacy_version: In previous versions of DTLS, this field was used 1050 for version negotiation and represented the highest version number 1051 supported by the client. Experience has shown that many servers 1052 do not properly implement version negotiation, leading to "version 1053 intolerance" in which the server rejects an otherwise acceptable 1054 ClientHello with a version number higher than it supports. In 1055 DTLS 1.3, the client indicates its version preferences in the 1056 "supported_versions" extension (see Section 4.2.1 of [TLS13]) and 1057 the legacy_version field MUST be set to {254, 253}, which was the 1058 version number for DTLS 1.2. The version fields for DTLS 1.0 and 1059 DTLS 1.2 are 0xfeff and 0xfefd (to match the wire versions) but 1060 the version field for DTLS 1.3 is 0x0304. 1062 random: Same as for TLS 1.3. 1064 legacy_session_id: Same as for TLS 1.3. 1066 legacy_cookie: A DTLS 1.3-only client MUST set the legacy_cookie 1067 field to zero length. If a DTLS 1.3 ClientHello is received with 1068 any other value in this field, the server MUST abort the handshake 1069 with an "illegal_parameter" alert. 1071 cipher_suites: Same as for TLS 1.3. 1073 legacy_compression_methods: Same as for TLS 1.3. 1075 extensions: Same as for TLS 1.3. 1077 5.4. Handshake Message Fragmentation and Reassembly 1079 Each DTLS message MUST fit within a single transport layer datagram. 1080 However, handshake messages are potentially bigger than the maximum 1081 record size. Therefore, DTLS provides a mechanism for fragmenting a 1082 handshake message over a number of records, each of which can be 1083 transmitted separately, thus avoiding IP fragmentation. 1085 When transmitting the handshake message, the sender divides the 1086 message into a series of N contiguous data ranges. The ranges MUST 1087 NOT overlap. The sender then creates N handshake messages, all with 1088 the same message_seq value as the original handshake message. Each 1089 new message is labeled with the fragment_offset (the number of bytes 1090 contained in previous fragments) and the fragment_length (the length 1091 of this fragment). The length field in all messages is the same as 1092 the length field of the original message. An unfragmented message is 1093 a degenerate case with fragment_offset=0 and fragment_length=length. 1094 Each range MUST be delivered in a single UDP datagram. 1096 When a DTLS implementation receives a handshake message fragment, it 1097 MUST buffer it until it has the entire handshake message. DTLS 1098 implementations MUST be able to handle overlapping fragment ranges. 1099 This allows senders to retransmit handshake messages with smaller 1100 fragment sizes if the PMTU estimate changes. 1102 Note that as with TLS, multiple handshake messages may be placed in 1103 the same DTLS record, provided that there is room and that they are 1104 part of the same flight. Thus, there are two acceptable ways to pack 1105 two DTLS messages into the same datagram: in the same record or in 1106 separate records. 1108 5.5. End Of Early Data 1110 The DTLS 1.3 handshake has one important difference from the TLS 1.3 1111 handshake: the EndOfEarlyData message is omitted both from the wire 1112 and the handshake transcript: because DTLS records have epochs, 1113 EndOfEarlyData is not necessary to determine when the early data is 1114 complete, and because DTLS is lossy, attackers can trivially mount 1115 the deletion attacks that EndOfEarlyData prevents in TLS. Servers 1116 SHOULD aggressively age out the epoch 1 keys upon receiving the first 1117 epoch 2 record and SHOULD NOT accept epoch 1 data after the first 1118 epoch 3 record is received. (See Section 6.1 for the definitions of 1119 each epoch.) 1121 5.6. DTLS Handshake Flights 1123 DTLS messages are grouped into a series of message flights, according 1124 to the diagrams below. 1126 Client Server 1128 ClientHello +----------+ 1129 + key_share* | Flight 1 | 1130 + pre_shared_key* --------> +----------+ 1132 +----------+ 1133 <-------- HelloRetryRequest | Flight 2 | 1134 + cookie +----------+ 1136 ClientHello +----------+ 1137 + key_share* | Flight 3 | 1138 + pre_shared_key* --------> +----------+ 1139 + cookie 1141 ServerHello 1142 + key_share* 1143 + pre_shared_key* +----------+ 1144 {EncryptedExtensions} | Flight 4 | 1145 {CertificateRequest*} +----------+ 1146 {Certificate*} 1147 {CertificateVerify*} 1148 <-------- {Finished} 1149 [Application Data*] 1151 {Certificate*} +----------+ 1152 {CertificateVerify*} | Flight 5 | 1153 {Finished} --------> +----------+ 1154 [Application Data] 1156 +----------+ 1157 <-------- [ACK] | Flight 6 | 1158 [Application Data*] +----------+ 1160 [Application Data] <-------> [Application Data] 1162 Figure 6: Message flights for a full DTLS Handshake (with cookie 1163 exchange) 1165 ClientHello +----------+ 1166 + pre_shared_key | Flight 1 | 1167 + key_share* --------> +----------+ 1169 ServerHello 1170 + pre_shared_key +----------+ 1171 + key_share* | Flight 2 | 1172 {EncryptedExtensions} +----------+ 1173 <-------- {Finished} 1174 [Application Data*] 1175 +----------+ 1176 {Finished} --------> | Flight 3 | 1177 [Application Data*] +----------+ 1179 +----------+ 1180 <-------- [ACK] | Flight 4 | 1181 [Application Data*] +----------+ 1183 [Application Data] <-------> [Application Data] 1185 Figure 7: Message flights for resumption and PSK handshake 1186 (without cookie exchange) 1188 Client Server 1190 ClientHello 1191 + early_data 1192 + psk_key_exchange_modes +----------+ 1193 + key_share* | Flight 1 | 1194 + pre_shared_key +----------+ 1195 (Application Data*) --------> 1197 ServerHello 1198 + pre_shared_key 1199 + key_share* +----------+ 1200 {EncryptedExtensions} | Flight 2 | 1201 {Finished} +----------+ 1202 <-------- [Application Data*] 1204 +----------+ 1205 {Finished} --------> | Flight 3 | 1206 [Application Data*] +----------+ 1208 +----------+ 1209 <-------- [ACK] | Flight 4 | 1210 [Application Data*] +----------+ 1212 [Application Data] <-------> [Application Data] 1214 Figure 8: Message flights for the Zero-RTT handshake 1216 Client Server 1218 +----------+ 1219 <-------- [NewSessionTicket] | Flight 1 | 1220 +----------+ 1222 +----------+ 1223 [ACK] --------> | Flight 2 | 1224 +----------+ 1226 Figure 9: Message flights for the new session ticket message 1228 Note: The application data sent by the client is not included in the 1229 timeout and retransmission calculation. 1231 5.7. Timeout and Retransmission 1232 5.7.1. State Machine 1234 DTLS uses a simple timeout and retransmission scheme with the state 1235 machine shown in Figure 10. Because DTLS clients send the first 1236 message (ClientHello), they start in the PREPARING state. DTLS 1237 servers start in the WAITING state, but with empty buffers and no 1238 retransmit timer. 1240 +-----------+ 1241 | PREPARING | 1242 +----------> | | 1243 | | | 1244 | +-----------+ 1245 | | 1246 | | Buffer next flight 1247 | | 1248 | \|/ 1249 | +-----------+ 1250 | | | 1251 | | SENDING |<------------------+ 1252 | | | | 1253 | +-----------+ | 1254 Receive | | | 1255 next | | Send flight or partial | 1256 flight | | flight | 1257 | +---------------+ | 1258 | | | Set retransmit timer | 1259 | | \|/ | 1260 | | +-----------+ | 1261 | | | | | 1262 +--)---------| WAITING |-------------------+ 1263 | | +----->| | Timer expires | 1264 | | | +-----------+ | 1265 | | | | | | | 1266 | | | | | | | 1267 | | +----------+ | +--------------------+ 1268 | | Receive record | Read retransmit or ACK 1269 Receive | | Send ACK | 1270 last | | | 1271 flight | | | Receive ACK 1272 | | | for last flight 1273 \|/\|/ | 1274 | 1275 +-----------+ | 1276 | | <---------+ 1277 | FINISHED | 1278 | | 1279 +-----------+ 1280 | /|\ 1281 | | 1282 | | 1283 +---+ 1285 Server read retransmit 1286 Retransmit ACK 1288 Figure 10: DTLS timeout and retransmission state machine 1290 The state machine has four basic states: PREPARING, SENDING, WAITING, 1291 and FINISHED. 1293 In the PREPARING state, the implementation does whatever computations 1294 are necessary to prepare the next flight of messages. It then 1295 buffers them up for transmission (emptying the buffer first) and 1296 enters the SENDING state. 1298 In the SENDING state, the implementation transmits the buffered 1299 flight of messages. If the implementation has received one or more 1300 ACKs (see Section 7) from the peer, then it SHOULD omit any messages 1301 or message fragments which have already been ACKed. Once the 1302 messages have been sent, the implementation then enters the FINISHED 1303 state if this is the last flight in the handshake. Or, if the 1304 implementation expects to receive more messages, it sets a retransmit 1305 timer and then enters the WAITING state. 1307 There are four ways to exit the WAITING state: 1309 1. The retransmit timer expires: the implementation transitions to 1310 the SENDING state, where it retransmits the flight, resets the 1311 retransmit timer, and returns to the WAITING state. 1313 2. The implementation reads an ACK from the peer: upon receiving an 1314 ACK for a partial flight (as mentioned in Section 7.1), the 1315 implementation transitions to the SENDING state, where it 1316 retransmits the unacked portion of the flight, resets the 1317 retransmit timer, and returns to the WAITING state. Upon 1318 receiving an ACK for a complete flight, the implementation 1319 cancels all retransmissions and either remains in WAITING, or, if 1320 the ACK was for the final flight, transitions to FINISHED. 1322 3. The implementation reads a retransmitted flight from the peer: 1323 the implementation transitions to the SENDING state, where it 1324 retransmits the flight, resets the retransmit timer, and returns 1325 to the WAITING state. The rationale here is that the receipt of 1326 a duplicate message is the likely result of timer expiry on the 1327 peer and therefore suggests that part of one's previous flight 1328 was lost. 1330 4. The implementation receives some or all next flight of messages: 1331 if this is the final flight of messages, the implementation 1332 transitions to FINISHED. If the implementation needs to send a 1333 new flight, it transitions to the PREPARING state. Partial reads 1334 (whether partial messages or only some of the messages in the 1335 flight) may also trigger the implementation to send an ACK, as 1336 described in Section 7.1. 1338 Because DTLS clients send the first message (ClientHello), they start 1339 in the PREPARING state. DTLS servers start in the WAITING state, but 1340 with empty buffers and no retransmit timer. 1342 In addition, for at least twice the default Maximum Segment Lifetime 1343 (MSL) defined for [RFC0793], when in the FINISHED state, the server 1344 MUST respond to retransmission of the client's second flight with a 1345 retransmit of its ACK. 1347 Note that because of packet loss, it is possible for one side to be 1348 sending application data even though the other side has not received 1349 the first side's Finished message. Implementations MUST either 1350 discard or buffer all application data records for the new epoch 1351 until they have received the Finished message for that epoch. 1352 Implementations MAY treat receipt of application data with a new 1353 epoch prior to receipt of the corresponding Finished message as 1354 evidence of reordering or packet loss and retransmit their final 1355 flight immediately, shortcutting the retransmission timer. 1357 5.7.2. Timer Values 1359 Though timer values are the choice of the implementation, mishandling 1360 of the timer can lead to serious congestion problems; for example, if 1361 many instances of a DTLS time out early and retransmit too quickly on 1362 a congested link. Implementations SHOULD use an initial timer value 1363 of 100 msec (the minimum defined in RFC 6298 [RFC6298]) and double 1364 the value at each retransmission, up to no less than the RFC 6298 1365 maximum of 60 seconds. Application specific profiles, such as those 1366 used for the Internet of Things environment, may recommend longer 1367 timer values. Note that a 100 msec timer is recommended rather than 1368 the 3-second RFC 6298 default in order to improve latency for time- 1369 sensitive applications. Because DTLS only uses retransmission for 1370 handshake and not dataflow, the effect on congestion should be 1371 minimal. 1373 Implementations SHOULD retain the current timer value until a 1374 transmission without loss occurs, at which time the value may be 1375 reset to the initial value. After a long period of idleness, no less 1376 than 10 times the current timer value, implementations may reset the 1377 timer to the initial value. 1379 5.8. CertificateVerify and Finished Messages 1381 CertificateVerify and Finished messages have the same format as in 1382 TLS 1.3. Hash calculations include entire handshake messages, 1383 including DTLS-specific fields: message_seq, fragment_offset, and 1384 fragment_length. However, in order to remove sensitivity to 1385 handshake message fragmentation, the CertificateVerify and the 1386 Finished messages MUST be computed as if each handshake message had 1387 been sent as a single fragment following the algorithm described in 1388 Section 4.4.3 and Section 4.4.4 of [TLS13], respectively. 1390 5.9. Cryptographic Label Prefix 1392 Section 7.1 of [TLS13] specifies that HKDF-Expand-Label uses a label 1393 prefix of "tls13 ". For DTLS 1.3, that label SHALL be "dtls13". 1394 This ensures key separation between DTLS 1.3 and TLS 1.3. Note that 1395 there is no trailing space; this is necessary in order to keep the 1396 overall label size inside of one hash iteration because "DTLS" is one 1397 letter longer than "TLS". 1399 5.10. Alert Messages 1401 Note that Alert messages are not retransmitted at all, even when they 1402 occur in the context of a handshake. However, a DTLS implementation 1403 which would ordinarily issue an alert SHOULD generate a new alert 1404 message if the offending record is received again (e.g., as a 1405 retransmitted handshake message). Implementations SHOULD detect when 1406 a peer is persistently sending bad messages and terminate the local 1407 connection state after such misbehavior is detected. 1409 5.11. Establishing New Associations with Existing Parameters 1411 If a DTLS client-server pair is configured in such a way that 1412 repeated connections happen on the same host/port quartet, then it is 1413 possible that a client will silently abandon one connection and then 1414 initiate another with the same parameters (e.g., after a reboot). 1415 This will appear to the server as a new handshake with epoch=0. In 1416 cases where a server believes it has an existing association on a 1417 given host/port quartet and it receives an epoch=0 ClientHello, it 1418 SHOULD proceed with a new handshake but MUST NOT destroy the existing 1419 association until the client has demonstrated reachability either by 1420 completing a cookie exchange or by completing a complete handshake 1421 including delivering a verifiable Finished message. After a correct 1422 Finished message is received, the server MUST abandon the previous 1423 association to avoid confusion between two valid associations with 1424 overlapping epochs. The reachability requirement prevents off-path/ 1425 blind attackers from destroying associations merely by sending forged 1426 ClientHellos. 1428 Note: it is not always possible to distinguish which association a 1429 given record is from. For instance, if the client performs a 1430 handshake, abandons the connection, and then immediately starts a new 1431 handshake, it may not be possible to tell which connection a given 1432 protected record is for. In these cases, trial decryption MAY be 1433 necessary, though implementations could also use some sort of CID, 1434 such as the one specified in [I-D.ietf-tls-dtls-connection-id]. 1436 6. Example of Handshake with Timeout and Retransmission 1438 The following is an example of a handshake with lost packets and 1439 retransmissions. 1441 Client Server 1442 ------ ------ 1444 Record 0 --------> 1445 ClientHello 1446 (message_seq=0) 1448 X<----- Record 0 1449 (lost) ServerHello 1450 (message_seq=1) 1451 EncryptedExtensions 1452 (message_seq=2) 1453 Certificate 1454 (message_seq=3) 1456 <-------- Record 1 1457 CertificateVerify 1458 (message_seq=4) 1459 Finished 1460 (message_seq=5) 1462 Record 1 --------> 1463 ACK [1] 1465 <-------- Record 2 1466 ServerHello 1467 (message_seq=1) 1468 EncryptedExtensions 1469 (message_seq=2) 1470 Certificate 1471 (message_seq=3) 1473 Record 2 --------> 1474 Certificate 1475 (message_seq=1) 1476 CertificateVerify 1477 (message_seq=2) 1478 Finished 1479 (message_seq=3) 1481 <-------- Record 3 1482 ACK [2] 1484 Figure 11: Example DTLS exchange illustrating message loss 1486 6.1. Epoch Values and Rekeying 1488 A recipient of a DTLS message needs to select the correct keying 1489 material in order to process an incoming message. With the 1490 possibility of message loss and re-order an identifier is needed to 1491 determine which cipher state has been used to protect the record 1492 payload. The epoch value fulfills this role in DTLS. In addition to 1493 the key derivation steps described in Section 7 of [TLS13] triggered 1494 by the states during the handshake a sender may want to rekey at any 1495 time during the lifetime of the connection and has to have a way to 1496 indicate that it is updating its sending cryptographic keys. 1498 This version of DTLS assigns dedicated epoch values to messages in 1499 the protocol exchange to allow identification of the correct cipher 1500 state: 1502 * epoch value (0) is used with unencrypted messages. There are 1503 three unencrypted messages in DTLS, namely ClientHello, 1504 ServerHello, and HelloRetryRequest. 1506 * epoch value (1) is used for messages protected using keys derived 1507 from client_early_traffic_secret. Note this epoch is skipped if 1508 the client does not offer early data. 1510 * epoch value (2) is used for messages protected using keys derived 1511 from [sender]_handshake_traffic_secret. Messages transmitted 1512 during the initial handshake, such as EncryptedExtensions, 1513 CertificateRequest, Certificate, CertificateVerify, and Finished 1514 belong to this category. Note, however, post-handshake are 1515 protected under the appropriate application traffic key and are 1516 not included in this category. 1518 * epoch value (3) is used for payloads protected using keys derived 1519 from the initial [sender]_application_traffic_secret_0. This may 1520 include handshake messages, such as post-handshake messages (e.g., 1521 a NewSessionTicket message). 1523 * epoch value (4 to 2^16-1) is used for payloads protected using 1524 keys from the [sender]_application_traffic_secret_N (N>0). 1526 Using these reserved epoch values a receiver knows what cipher state 1527 has been used to encrypt and integrity protect a message. 1528 Implementations that receive a payload with an epoch value for which 1529 no corresponding cipher state can be determined MUST generate a 1530 "unexpected_message" alert. For example, client incorrectly uses 1531 epoch value 5 when sending early application data in a 0-RTT 1532 exchange. A server will not be able to compute the appropriate keys 1533 and will therefore have to respond with an alert. 1535 Note that epoch values do not wrap. If a DTLS implementation would 1536 need to wrap the epoch value, it MUST terminate the connection. 1538 The traffic key calculation is described in Section 7.3 of [TLS13]. 1540 Figure 12 illustrates the epoch values in an example DTLS handshake. 1542 Client Server 1543 ------ ------ 1545 ClientHello 1546 (epoch=0) 1547 --------> 1549 <-------- HelloRetryRequest 1550 (epoch=0) 1552 ClientHello --------> 1553 (epoch=0) 1555 <-------- ServerHello 1556 (epoch=0) 1557 {EncryptedExtensions} 1558 (epoch=2) 1559 {Certificate} 1560 (epoch=2) 1561 {CertificateVerify} 1562 (epoch=2) 1563 {Finished} 1564 (epoch=2) 1566 {Certificate} --------> 1567 (epoch=2) 1568 {CertificateVerify} 1569 (epoch=2) 1570 {Finished} 1571 (epoch=2) 1573 <-------- [ACK] 1574 (epoch=3) 1576 [Application Data] --------> 1577 (epoch=3) 1579 <-------- [Application Data] 1580 (epoch=3) 1582 Some time later ... 1584 (Post-Handshake Message Exchange) 1586 <-------- [NewSessionTicket] 1587 (epoch=3) 1589 [ACK] --------> 1590 (epoch=3) 1592 Some time later ... 1593 (Rekeying) 1595 <-------- [Application Data] 1596 (epoch=4) 1597 [Application Data] --------> 1598 (epoch=4) 1600 Figure 12: Example DTLS exchange with epoch information 1602 7. ACK Message 1604 The ACK message is used by an endpoint to indicate handshake- 1605 containing the TLS records it has received from the other side. ACK 1606 is not a handshake message but is rather a separate content type, 1607 with code point TBD (proposed, 25). This avoids having ACK being 1608 added to the handshake transcript. Note that ACKs can still be sent 1609 in the same UDP datagram as handshake records. 1611 struct { 1612 RecordNumber record_numbers<0..2^16-1>; 1613 } ACK; 1615 record_numbers: a list of the records containing handshake messages 1616 in the current flight which the endpoint has received and either 1617 processed or buffered, in numerically increasing order. 1619 Implementations MUST NOT acknowledge records containing non- 1620 duplicative handshake messages or fragments which have not been 1621 processed or buffered. Otherwise, deadlock can ensue. 1623 During the handshake, ACKs only cover the current outstanding flight 1624 (this is possible because DTLS is generally a lockstep protocol). 1625 Thus, an ACK from the server would not cover both the ClientHello and 1626 the client's Certificate. Implementations can accomplish this by 1627 clearing their ACK list upon receiving the start of the next flight. 1629 After the handshake, ACKs SHOULD be sent once for each received and 1630 processed record (potentially subject to some delay) and MAY cover 1631 more than one flight. 1633 ACK records MUST be sent with an epoch that is equal to or higher 1634 than the record which is being acknowledged. Implementations SHOULD 1635 simply use the current key. 1637 7.1. Sending ACKs 1639 When an implementation receives a partial flight, it SHOULD generate 1640 an ACK that covers the messages from that flight which it has 1641 received so far. Implementations have some discretion about when to 1642 generate ACKs, but it is RECOMMENDED that they do so under two 1643 circumstances: 1645 * When they receive a message or fragment which is out of order, 1646 either because it is not the next expected message or because it 1647 is not the next piece of the current message. Implementations 1648 MUST NOT send ACKs for handshake messages which they discard as 1649 out-of-order, because otherwise those messages will not be 1650 retransmitted. 1652 * When they have received part of a flight and do not immediately 1653 receive the rest of the flight (which may be in the same UDP 1654 datagram). A reasonable approach here is to set a timer for 1/4 1655 the current retransmit timer value when the first record in the 1656 flight is received and then send an ACK when that timer expires. 1658 In addition, implementations MUST send ACKs upon receiving all of any 1659 flight which they do not respond to with their own messages. 1660 Specifically, this means the client's final flight of the main 1661 handshake, the server's transmission of the NewSessionTicket, and 1662 KeyUpdate messages. ACKs SHOULD NOT be sent for other complete 1663 flights because they are implicitly acknowledged by the receipt of 1664 the next flight, which generally immediately follows the flight. 1665 Each NewSessionTicket or KeyUpdate is an individual flight; in 1666 particular, a KeyUpdate sent in response to a KeyUpdate with 1667 update_requested does not implicitly acknowledge that message. 1668 Implementations MAY acknowledge the records corresponding to each 1669 transmission of that flight or simply acknowledge the most recent 1670 one. 1672 ACKs MUST NOT be sent for other records of any content type other 1673 than handshake or for records which cannot be unprotected. 1675 Note that in some cases it may be necessary to send an ACK which does 1676 not contain any record numbers. For instance, a client might receive 1677 an EncryptedExtensions message prior to receiving a ServerHello. 1678 Because it cannot decrypt the EncryptedExtensions, it cannot safely 1679 acknowledge it (as it might be damaged). If the client does not send 1680 an ACK, the server will eventually retransmit its first flight, but 1681 this might take far longer than the actual round trip time between 1682 client and server. Having the client send an empty ACK shortcuts 1683 this process. 1685 7.2. Receiving ACKs 1687 When an implementation receives an ACK, it SHOULD record that the 1688 messages or message fragments sent in the records being ACKed were 1689 received and omit them from any future retransmissions. Upon receipt 1690 of an ACK for only some messages from a flight, an implementation 1691 SHOULD retransmit the remaining messages or fragments. Note that 1692 this requires implementations to track which messages appear in which 1693 records. Once all the messages in a flight have been acknowledged, 1694 the implementation MUST cancel all retransmissions of that flight. 1695 As noted above, the receipt of any record responding to a given 1696 flight MUST be taken as an implicit acknowledgement for the entire 1697 flight. 1699 8. Key Updates 1701 As with TLS 1.3, DTLS 1.3 implementations send a KeyUpdate message to 1702 indicate that they are updating their sending keys. As with other 1703 handshake messages with no built-in response, KeyUpdates MUST be 1704 acknowledged. In order to facilitate epoch reconstruction 1705 Section 4.2.2 implementations MUST NOT send with the new keys or send 1706 a new KeyUpdate until the previous KeyUpdate has been acknowledged 1707 (this avoids having too many epochs in active use). 1709 Due to loss and/or re-ordering, DTLS 1.3 implementations may receive 1710 a record with an older epoch than the current one (the requirements 1711 above preclude receiving a newer record). They SHOULD attempt to 1712 process those records with that epoch (see Section 4.2.2 for 1713 information on determining the correct epoch), but MAY opt to discard 1714 such out-of-epoch records. 1716 Although KeyUpdate MUST be acknowledged, it is possible for the ACK 1717 to be lost, in which case the sender of the KeyUpdate will retransmit 1718 it. Implementations MUST retain the ability to ACK the KeyUpdate for 1719 up to 2MSL. It is RECOMMENDED that they do so by retaining the pre- 1720 update keying material, but they MAY do so by responding to messages 1721 which appear to be out-of-epoch with a canned ACK message; in this 1722 case, implementations SHOULD rate limit how often they send such 1723 ACKs. 1725 9. Connection ID Updates 1727 If the client and server have negotiated the "connection_id" 1728 extension [I-D.ietf-tls-dtls-connection-id], either side can send a 1729 new CID which it wishes the other side to use in a NewConnectionId 1730 message. 1732 enum { 1733 cid_immediate(0), cid_spare(1), (255) 1734 } ConnectionIdUsage; 1736 opaque ConnectionId<0..2^8-1>; 1738 struct { 1739 ConnectionIds cids<0..2^16-1>; 1740 ConnectionIdUsage usage; 1741 } NewConnectionId; 1743 cid Indicates the set of CIDs which the sender wishes the peer to 1744 use. 1746 usage Indicates whether the new CIDs should be used immediately or 1747 are spare. If usage is set to "cid_immediate", then one of the 1748 new CID MUST be used immediately for all future records. If it is 1749 set to "cid_spare", then either existing or new CID MAY be used. 1751 Endpoints SHOULD use receiver-provided CIDs in the order they were 1752 provided. Endpoints MUST NOT have more than one NewConnectionId 1753 message outstanding. 1755 If the client and server have negotiated the "connection_id" 1756 extension, either side can request a new CID using the 1757 RequestConnectionId message. 1759 struct { 1760 uint8 num_cids; 1761 } RequestConnectionId; 1763 num_cids The number of CIDs desired. 1765 Endpoints SHOULD respond to RequestConnectionId by sending a 1766 NewConnectionId with usage "cid_spare" containing num_cid CIDs soon 1767 as possible. Endpoints MUST NOT send a RequestConnectionId message 1768 when an existing request is still unfulfilled; this implies that 1769 endpoints needs to request new CIDs well in advance. An endpoint MAY 1770 ignore requests, which it considers excessive (though they MUST be 1771 acknowledged as usual). 1773 Endpoints MUST NOT send either of these messages if they did not 1774 negotiate a CID. If an implementation receives these messages when 1775 CIDs were not negotiated, it MUST abort the connection with an 1776 unexpected_message alert. 1778 9.1. Connection ID Example 1780 Below is an example exchange for DTLS 1.3 using a single CID in each 1781 direction. 1783 Note: The connection_id extension is defined in 1784 [I-D.ietf-tls-dtls-connection-id], which is used in ClientHello and 1785 ServerHello messages. 1787 Client Server 1788 ------ ------ 1790 ClientHello 1791 (connection_id=5) 1792 --------> 1794 <-------- HelloRetryRequest 1795 (cookie) 1797 ClientHello --------> 1798 (connection_id=5) 1799 +cookie 1801 <-------- ServerHello 1802 (connection_id=100) 1803 EncryptedExtensions 1804 (cid=5) 1805 Certificate 1806 (cid=5) 1807 CertificateVerify 1808 (cid=5) 1809 Finished 1810 (cid=5) 1812 Certificate --------> 1813 (cid=100) 1814 CertificateVerify 1815 (cid=100) 1816 Finished 1817 (cid=100) 1818 <-------- Ack 1819 (cid=5) 1821 Application Data ========> 1822 (cid=100) 1823 <======== Application Data 1824 (cid=5) 1826 Figure 13: Example DTLS 1.3 Exchange with CIDs 1828 If no CID is negotiated, then the receiver MUST reject any records it 1829 receives that contain a CID. 1831 10. Application Data Protocol 1833 Application data messages are carried by the record layer and are 1834 fragmented and encrypted based on the current connection state. The 1835 messages are treated as transparent data to the record layer. 1837 11. Security Considerations 1839 Security issues are discussed primarily in [TLS13]. 1841 The primary additional security consideration raised by DTLS is that 1842 of denial of service. DTLS includes a cookie exchange designed to 1843 protect against denial of service. However, implementations that do 1844 not use this cookie exchange are still vulnerable to DoS. In 1845 particular, DTLS servers that do not use the cookie exchange may be 1846 used as attack amplifiers even if they themselves are not 1847 experiencing DoS. Therefore, DTLS servers SHOULD use the cookie 1848 exchange unless there is good reason to believe that amplification is 1849 not a threat in their environment. Clients MUST be prepared to do a 1850 cookie exchange with every handshake. 1852 DTLS implementations MUST NOT update their sending address in 1853 response to packets from a different address unless they first 1854 perform some reachability test; no such test is defined in this 1855 specification. Even with such a test, An on-path adversary can also 1856 black-hole traffic or create a reflection attack against third 1857 parties because a DTLS peer has no means to distinguish a genuine 1858 address update event (for example, due to a NAT rebinding) from one 1859 that is malicious. This attack is of concern when there is a large 1860 asymmetry of request/response message sizes. 1862 With the exception of order protection and non-replayability, the 1863 security guarantees for DTLS 1.3 are the same as TLS 1.3. While TLS 1864 always provides order protection and non-replayability, DTLS does not 1865 provide order protection and may not provide replay protection. 1867 Unlike TLS implementations, DTLS implementations SHOULD NOT respond 1868 to invalid records by terminating the connection. 1870 If implementations process out-of-epoch records as recommended in 1871 Section 8, then this creates a denial of service risk since an 1872 adversary could inject records with fake epoch values, forcing the 1873 recipient to compute the next-generation application_traffic_secret 1874 using the HKDF-Expand-Label construct to only find out that the 1875 message was does not pass the AEAD cipher processing. The impact of 1876 this attack is small since the HKDF-Expand-Label only performs 1877 symmetric key hashing operations. Implementations which are 1878 concerned about this form of attack can discard out-of-epoch records. 1880 The security and privacy properties of the CID for DTLS 1.3 builds on 1881 top of what is described in [I-D.ietf-tls-dtls-connection-id]. There 1882 are, however, several improvements: 1884 * The use of the Post-Handshake message allows the client and the 1885 server to update their CIDs and those values are exchanged with 1886 confidentiality protection. 1888 * With multi-homing, an adversary is able to correlate the 1889 communication interaction over the two paths, which adds further 1890 privacy concerns. In order to prevent this, implementations 1891 SHOULD attempt to use fresh CIDs whenever they change local 1892 addresses or ports (though this is not always possible to detect). 1893 The RequestConnectionId message can be used by a peer to ask for 1894 new CIDs to ensure that a pool of suitable CIDs is available. 1896 * Switching CID based on certain events, or even regularly, helps 1897 against tracking by on-path adversaries but the sequence numbers 1898 can still allow linkability. For this reason this specification 1899 defines an algorithm for encrypting sequence numbers, see 1900 Section 4.2.3. Note that sequence number encryption is used for 1901 all encrypted DTLS 1.3 records irrespectively of the use of a CID. 1903 * DTLS 1.3 encrypts handshake messages much earlier than in previous 1904 DTLS versions. Therefore, less information identifying the DTLS 1905 client, such as the client certificate, is available to an on-path 1906 adversary. 1908 12. Changes to DTLS 1.2 1910 Since TLS 1.3 introduces a large number of changes to TLS 1.2, the 1911 list of changes from DTLS 1.2 to DTLS 1.3 is equally large. For this 1912 reason this section focuses on the most important changes only. 1914 * New handshake pattern, which leads to a shorter message exchange 1916 * Only AEAD ciphers are supported. Additional data calculation has 1917 been simplified. 1919 * Removed support for weaker and older cryptographic algorithms 1921 * HelloRetryRequest of TLS 1.3 used instead of HelloVerifyRequest 1923 * More flexible ciphersuite negotiation 1925 * New session resumption mechanism 1927 * PSK authentication redefined 1928 * New key derivation hierarchy utilizing a new key derivation 1929 construct 1931 * Improved version negotiation 1933 * Optimized record layer encoding and thereby its size 1935 * Added CID functionality 1937 * Sequence numbers are encrypted. 1939 13. IANA Considerations 1941 IANA is requested to allocate a new value in the "TLS ContentType" 1942 registry for the ACK message, defined in Section 7, with content type 1943 25. The value for the "DTLS-OK" column is "Y". IANA is requested to 1944 reserve the content type range 32-63 so that content types in this 1945 range are not allocated. 1947 IANA is requested to allocate two values in the "TLS Handshake Type" 1948 registry, defined in [TLS13], for RequestConnectionId (TBD), and 1949 NewConnectionId (TBD), as defined in this document. The value for 1950 the "DTLS-OK" columns are "Y". 1952 14. References 1954 14.1. Normative References 1956 [CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 1957 Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, 1958 . 1960 [I-D.ietf-tls-dtls-connection-id] 1961 Rescorla, E., Tschofenig, H., and T. Fossati, "Connection 1962 Identifiers for DTLS 1.2", Work in Progress, Internet- 1963 Draft, draft-ietf-tls-dtls-connection-id-07, 21 October 1964 2019, . 1967 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1968 DOI 10.17487/RFC0768, August 1980, 1969 . 1971 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1972 RFC 793, DOI 10.17487/RFC0793, September 1981, 1973 . 1975 [RFC1191] Mogul, J.C. and S.E. Deering, "Path MTU discovery", 1976 RFC 1191, DOI 10.17487/RFC1191, November 1990, 1977 . 1979 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1980 Requirement Levels", BCP 14, RFC 2119, 1981 DOI 10.17487/RFC2119, March 1997, 1982 . 1984 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1985 Control Message Protocol (ICMPv6) for the Internet 1986 Protocol Version 6 (IPv6) Specification", STD 89, 1987 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1988 . 1990 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1991 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1992 . 1994 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 1995 "Computing TCP's Retransmission Timer", RFC 6298, 1996 DOI 10.17487/RFC6298, June 2011, 1997 . 1999 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2000 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2001 May 2017, . 2003 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2004 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2005 . 2007 14.2. Informative References 2009 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 2010 Protocol", RFC 2522, DOI 10.17487/RFC2522, March 1999, 2011 . 2013 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 2014 RFC 4303, DOI 10.17487/RFC4303, December 2005, 2015 . 2017 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2018 Congestion Control Protocol (DCCP)", RFC 4340, 2019 DOI 10.17487/RFC4340, March 2006, 2020 . 2022 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 2023 (TLS) Protocol Version 1.1", RFC 4346, 2024 DOI 10.17487/RFC4346, April 2006, 2025 . 2027 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2028 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 2029 . 2031 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 2032 RFC 4960, DOI 10.17487/RFC4960, September 2007, 2033 . 2035 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 2036 the Datagram Congestion Control Protocol (DCCP)", 2037 RFC 5238, DOI 10.17487/RFC5238, May 2008, 2038 . 2040 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2041 (TLS) Protocol Version 1.2", RFC 5246, 2042 DOI 10.17487/RFC5246, August 2008, 2043 . 2045 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2046 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2047 January 2012, . 2049 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 2050 Kivinen, "Internet Key Exchange Protocol Version 2 2051 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2052 2014, . 2054 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2055 "Recommendations for Secure Use of Transport Layer 2056 Security (TLS) and Datagram Transport Layer Security 2057 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2058 2015, . 2060 Appendix A. Protocol Data Structures and Constant Values 2062 This section provides the normative protocol types and constants 2063 definitions. 2065 A.1. Record Layer 2066 struct { 2067 ContentType type; 2068 ProtocolVersion legacy_record_version; 2069 uint16 epoch = 0 // DTLS field 2070 uint48 sequence_number; // DTLS field 2071 uint16 length; 2072 opaque fragment[DTLSPlaintext.length]; 2073 } DTLSPlaintext; 2075 struct { 2076 opaque content[DTLSPlaintext.length]; 2077 ContentType type; 2078 uint8 zeros[length_of_padding]; 2079 } DTLSInnerPlaintext; 2081 struct { 2082 opaque unified_hdr[variable]; 2083 opaque encrypted_record[length]; 2084 } DTLSCiphertext; 2086 0 1 2 3 4 5 6 7 2087 +-+-+-+-+-+-+-+-+ 2088 |0|0|1|C|S|L|E E| 2089 +-+-+-+-+-+-+-+-+ 2090 | Connection ID | Legend: 2091 | (if any, | 2092 / length as / C - Connection ID (CID) present 2093 | negotiated) | S - Sequence number length 2094 +-+-+-+-+-+-+-+-+ L - Length present 2095 | 8 or 16 bit | E - Epoch 2096 |Sequence Number| 2097 +-+-+-+-+-+-+-+-+ 2098 | 16 bit Length | 2099 | (if present) | 2100 +-+-+-+-+-+-+-+-+ 2102 A.2. Handshake Protocol 2104 enum { 2105 hello_request_RESERVED(0), 2106 client_hello(1), 2107 server_hello(2), 2108 hello_verify_request_RESERVED(3), 2109 new_session_ticket(4), 2110 end_of_early_data(5), 2111 hello_retry_request_RESERVED(6), 2112 encrypted_extensions(8), 2113 certificate(11), 2114 server_key_exchange_RESERVED(12), 2115 certificate_request(13), 2116 server_hello_done_RESERVED(14), 2117 certificate_verify(15), 2118 client_key_exchange_RESERVED(16), 2119 finished(20), 2120 key_update(24), 2121 message_hash(254), 2122 (255) 2123 } HandshakeType; 2125 struct { 2126 HandshakeType msg_type; /* handshake type */ 2127 uint24 length; /* bytes in message */ 2128 uint16 message_seq; /* DTLS-required field */ 2129 uint24 fragment_offset; /* DTLS-required field */ 2130 uint24 fragment_length; /* DTLS-required field */ 2131 select (HandshakeType) { 2132 case client_hello: ClientHello; 2133 case server_hello: ServerHello; 2134 case end_of_early_data: EndOfEarlyData; 2135 case encrypted_extensions: EncryptedExtensions; 2136 case certificate_request: CertificateRequest; 2137 case certificate: Certificate; 2138 case certificate_verify: CertificateVerify; 2139 case finished: Finished; 2140 case new_session_ticket: NewSessionTicket; 2141 case key_update: KeyUpdate; 2142 } body; 2143 } Handshake; 2145 uint16 ProtocolVersion; 2146 opaque Random[32]; 2148 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 2150 struct { 2151 ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2 2152 Random random; 2153 opaque legacy_session_id<0..32>; 2154 opaque legacy_cookie<0..2^8-1>; // DTLS 2155 CipherSuite cipher_suites<2..2^16-2>; 2156 opaque legacy_compression_methods<1..2^8-1>; 2157 Extension extensions<8..2^16-1>; 2158 } ClientHello; 2160 A.3. ACKs 2161 struct { 2162 RecordNumber record_numbers<0..2^16-1>; 2163 } ACK; 2165 A.4. Connection ID Management 2167 enum { 2168 cid_immediate(0), cid_spare(1), (255) 2169 } ConnectionIdUsage; 2171 opaque ConnectionId<0..2^8-1>; 2173 struct { 2174 ConnectionIds cids<0..2^16-1>; 2175 ConnectionIdUsage usage; 2176 } NewConnectionId; 2178 struct { 2179 uint8 num_cids; 2180 } RequestConnectionId; 2182 Appendix B. History 2184 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 2186 IETF Drafts 2188 draft-35: - I-D.ietf-tls-dtls-connection-id became a normative 2189 reference - Removed duplicate reference to I-D.ietf-tls-dtls- 2190 connection-id. - Fix figure 11 to have the right numbers andno cookie 2191 in message 1. - Clarify when you can ACK. - Clarify additional data 2192 computation. 2194 draft-33: - Key separation between TLS and DTLS. Issue #72. 2196 draft-32: - Editorial improvements and clarifications. 2198 draft-31: - Editorial improvements in text and figures. - Added 2199 normative reference to ChaCha20 and Poly1305. 2201 draft-30: - Changed record format - Added text about end of early 2202 data - Changed format of the Connection ID Update message - Added 2203 Appendix A "Protocol Data Structures and Constant Values" 2205 draft-29: - Added support for sequence number encryption - Update to 2206 new record format - Emphasize that compatibility mode isn't used. 2208 draft-28: - Version bump to align with TLS 1.3 pre-RFC version. 2210 draft-27: - Incorporated unified header format. - Added support for 2211 CIDs. 2213 draft-04 - 26: - Submissions to align with TLS 1.3 draft versions 2215 draft-03 - Only update keys after KeyUpdate is ACKed. 2217 draft-02 - Shorten the protected record header and introduce an 2218 ultra-short version of the record header. - Reintroduce KeyUpdate, 2219 which works properly now that we have ACK. - Clarify the ACK rules. 2221 draft-01 - Restructured the ACK to contain a list of records and also 2222 be a record rather than a handshake message. 2224 draft-00 - First IETF Draft 2226 Personal Drafts draft-01 - Alignment with version -19 of the TLS 1.3 2227 specification 2229 draft-00 2231 * Initial version using TLS 1.3 as a baseline. 2233 * Use of epoch values instead of KeyUpdate message 2235 * Use of cookie extension instead of cookie field in ClientHello and 2236 HelloVerifyRequest messages 2238 * Added ACK message 2240 * Text about sequence number handling 2242 Appendix C. Working Group Information 2244 The discussion list for the IETF TLS working group is located at the 2245 e-mail address tls@ietf.org (mailto:tls@ietf.org). Information on 2246 the group and information on how to subscribe to the list is at 2247 https://www1.ietf.org/mailman/listinfo/tls 2248 (https://www1.ietf.org/mailman/listinfo/tls) 2250 Archives of the list can be found at: https://www.ietf.org/mail- 2251 archive/web/tls/current/index.html (https://www.ietf.org/mail- 2252 archive/web/tls/current/index.html) 2254 Appendix D. Contributors 2256 Many people have contributed to previous DTLS versions and they are 2257 acknowledged in prior versions of DTLS specifications or in the 2258 referenced specifications. The sequence number encryption concept is 2259 taken from the QUIC specification. We would like to thank the 2260 authors of the QUIC specification for their work. 2262 In addition, we would like to thank: 2264 * David Benjamin 2265 Google 2266 davidben@google.com 2268 * Thomas Fossati 2269 Arm Limited 2270 Thomas.Fossati@arm.com 2272 * Tobias Gondrom 2273 Huawei 2274 tobias.gondrom@gondrom.org 2276 * Ilari Liusvaara 2277 Independent 2278 ilariliusvaara@welho.com 2280 * Martin Thomson 2281 Mozilla 2282 martin.thomson@gmail.com 2284 * Christopher A. Wood 2285 Apple Inc. 2286 cawood@apple.com 2288 * Yin Xinxing 2289 Huawei 2290 yinxinxing@huawei.com 2292 * Hanno Becker 2293 Arm Limited 2294 Hanno.Becker@arm.com 2296 Authors' Addresses 2298 Eric Rescorla 2299 RTFM, Inc. 2301 Email: ekr@rtfm.com 2302 Hannes Tschofenig 2303 Arm Limited 2305 Email: hannes.tschofenig@arm.com 2307 Nagendra Modadugu 2308 Google, Inc. 2310 Email: nagendra@cs.stanford.edu