idnits 2.17.1 draft-ietf-tls-dtls13-34.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document 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 (November 19, 2019) is 1620 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 2140 -- Looks like a reference, but probably isn't: '2' on line 2236 == Missing Reference: 'ACK' is mentioned on line 1582, but not defined == Missing Reference: 'NewSessionTicket' is mentioned on line 1579, but not defined -- Looks like a reference, but probably isn't: '1' on line 2234 -- Looks like a reference, but probably isn't: '3' on line 2239 ** Downref: Normative reference to an Informational RFC: RFC 8439 (ref. 'CHACHA') ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-13) exists of draft-ietf-tls-dtls-connection-id-07 == Outdated reference: A later version (-13) exists of draft-ietf-tls-dtls-connection-id-07 -- Duplicate reference: draft-ietf-tls-dtls-connection-id, mentioned in 'I-D.ietf-tls-dtls-connection-id', was also mentioned in 'DTLS-CID'. -- 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: 2 errors (**), 0 flaws (~~), 6 warnings (==), 14 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: May 22, 2020 N. Modadugu 7 Google, Inc. 8 November 19, 2019 10 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 11 draft-ietf-tls-dtls13-34 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 May 22, 2020. 43 Copyright Notice 45 Copyright (c) 2019 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 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 74 3. DTLS Design Rationale and Overview . . . . . . . . . . . . . 5 75 3.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 6 76 3.2. Reordering . . . . . . . . . . . . . . . . . . . . . . . 7 77 3.3. Message Size . . . . . . . . . . . . . . . . . . . . . . 7 78 3.4. Replay Detection . . . . . . . . . . . . . . . . . . . . 7 79 4. The DTLS Record Layer . . . . . . . . . . . . . . . . . . . . 7 80 4.1. Determining the Header Format . . . . . . . . . . . . . . 11 81 4.2. Sequence Number and Epoch . . . . . . . . . . . . . . . . 11 82 4.2.1. Processing Guidelines . . . . . . . . . . . . . . . . 11 83 4.2.2. Reconstructing the Sequence Number and Epoch . . . . 12 84 4.2.3. Sequence Number Encryption . . . . . . . . . . . . . 13 85 4.3. Transport Layer Mapping . . . . . . . . . . . . . . . . . 14 86 4.4. PMTU Issues . . . . . . . . . . . . . . . . . . . . . . . 14 87 4.5. Record Payload Protection . . . . . . . . . . . . . . . . 16 88 4.5.1. Anti-Replay . . . . . . . . . . . . . . . . . . . . . 16 89 4.5.2. Handling Invalid Records . . . . . . . . . . . . . . 17 90 5. The DTLS Handshake Protocol . . . . . . . . . . . . . . . . . 17 91 5.1. Denial-of-Service Countermeasures . . . . . . . . . . . . 18 92 5.2. DTLS Handshake Message Format . . . . . . . . . . . . . . 21 93 5.3. ClientHello Message . . . . . . . . . . . . . . . . . . . 22 94 5.4. Handshake Message Fragmentation and Reassembly . . . . . 23 95 5.5. End Of Early Data . . . . . . . . . . . . . . . . . . . . 24 96 5.6. DTLS Handshake Flights . . . . . . . . . . . . . . . . . 24 97 5.7. Timeout and Retransmission . . . . . . . . . . . . . . . 28 98 5.7.1. State Machine . . . . . . . . . . . . . . . . . . . . 28 99 5.7.2. Timer Values . . . . . . . . . . . . . . . . . . . . 30 100 5.8. CertificateVerify and Finished Messages . . . . . . . . . 31 101 5.9. Cryptographic Label Prefix . . . . . . . . . . . . . . . 31 102 5.10. Alert Messages . . . . . . . . . . . . . . . . . . . . . 31 103 5.11. Establishing New Associations with Existing Parameters . 31 104 6. Example of Handshake with Timeout and Retransmission . . . . 32 105 6.1. Epoch Values and Rekeying . . . . . . . . . . . . . . . . 34 106 7. ACK Message . . . . . . . . . . . . . . . . . . . . . . . . . 36 107 7.1. Sending ACKs . . . . . . . . . . . . . . . . . . . . . . 37 108 7.2. Receiving ACKs . . . . . . . . . . . . . . . . . . . . . 38 109 8. Key Updates . . . . . . . . . . . . . . . . . . . . . . . . . 38 110 9. Connection ID Updates . . . . . . . . . . . . . . . . . . . . 38 111 9.1. Connection ID Example . . . . . . . . . . . . . . . . . . 40 112 10. Application Data Protocol . . . . . . . . . . . . . . . . . . 42 113 11. Security Considerations . . . . . . . . . . . . . . . . . . . 42 114 12. Changes to DTLS 1.2 . . . . . . . . . . . . . . . . . . . . . 43 115 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 116 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 117 14.1. Normative References . . . . . . . . . . . . . . . . . . 44 118 14.2. Informative References . . . . . . . . . . . . . . . . . 45 119 Appendix A. Protocol Data Structures and Constant Values . . . . 47 120 A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 47 121 A.2. Handshake Protocol . . . . . . . . . . . . . . . . . . . 47 122 A.3. ACKs . . . . . . . . . . . . . . . . . . . . . . . . . . 49 123 A.4. Connection ID Management . . . . . . . . . . . . . . . . 49 124 Appendix B. History . . . . . . . . . . . . . . . . . . . . . . 49 125 Appendix C. Working Group Information . . . . . . . . . . . . . 50 126 Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 51 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 129 1. Introduction 131 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH 133 The source for this draft is maintained in GitHub. Suggested changes 134 should be submitted as pull requests at https://github.com/tlswg/ 135 dtls13-spec. Instructions are on that page as well. Editorial 136 changes can be managed in GitHub, but any substantive change should 137 be discussed on the TLS mailing list. 139 The primary goal of the TLS protocol is to provide privacy and data 140 integrity between two communicating peers. The TLS protocol is 141 composed of two layers: the TLS Record Protocol and the TLS Handshake 142 Protocol. However, TLS must run over a reliable transport channel - 143 typically TCP [RFC0793]. 145 There are applications that use UDP [RFC0768] as a transport and to 146 offer communication security protection for those applications the 147 Datagram Transport Layer Security (DTLS) protocol has been designed. 148 DTLS is deliberately designed to be as similar to TLS as possible, 149 both to minimize new security invention and to maximize the amount of 150 code and infrastructure reuse. 152 DTLS 1.0 [RFC4347] was originally defined as a delta from TLS 1.1 153 [RFC4346] and DTLS 1.2 [RFC6347] was defined as a series of deltas to 154 TLS 1.2 [RFC5246]. There is no DTLS 1.1; that version number was 155 skipped in order to harmonize version numbers with TLS. This 156 specification describes the most current version of the DTLS protocol 157 based on TLS 1.3 [TLS13]. 159 Implementations that speak both DTLS 1.2 and DTLS 1.3 can 160 interoperate with those that speak only DTLS 1.2 (using DTLS 1.2 of 161 course), just as TLS 1.3 implementations can interoperate with TLS 162 1.2 (see Appendix D of [TLS13] for details). While backwards 163 compatibility with DTLS 1.0 is possible the use of DTLS 1.0 is not 164 recommended as explained in Section 3.1.2 of RFC 7525 [RFC7525]. 166 2. Conventions and Terminology 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 170 "OPTIONAL" in this document are to be interpreted as described in BCP 171 14 [RFC2119] [RFC8174] when, and only when, they appear in all 172 capitals, as shown here. 174 The following terms are used: 176 - client: The endpoint initiating the DTLS connection. 178 - connection: A transport-layer connection between two endpoints. 180 - endpoint: Either the client or server of the connection. 182 - handshake: An initial negotiation between client and server that 183 establishes the parameters of their transactions. 185 - peer: An endpoint. When discussing a particular endpoint, "peer" 186 refers to the endpoint that is remote to the primary subject of 187 discussion. 189 - receiver: An endpoint that is receiving records. 191 - sender: An endpoint that is transmitting records. 193 - session: An association between a client and a server resulting 194 from a handshake. 196 - server: The endpoint which did not initiate the DTLS connection. 198 - CID: Connection ID 200 The reader is assumed to be familiar with the TLS 1.3 specification 201 since this document is defined as a delta from TLS 1.3. As in TLS 202 1.3 the HelloRetryRequest has the same format as a ServerHello 203 message but for convenience we use the term HelloRetryRequest 204 throughout this document as if it were a distinct message. 206 Figures in this document illustrate various combinations of the DTLS 207 protocol exchanges and the symbols have the following meaning: 209 - '+' indicates noteworthy extensions sent in the previously noted 210 message. 212 - '*' indicates optional or situation-dependent messages/extensions 213 that are not always sent. 215 - '{}' indicates messages protected using keys derived from a 216 [sender]_handshake_traffic_secret. 218 - '[]' indicates messages protected using keys derived from 219 traffic_secret_N. 221 3. DTLS Design Rationale and Overview 223 The basic design philosophy of DTLS is to construct "TLS over 224 datagram transport". Datagram transport does not require nor provide 225 reliable or in-order delivery of data. The DTLS protocol preserves 226 this property for application data. Applications such as media 227 streaming, Internet telephony, and online gaming use datagram 228 transport for communication due to the delay-sensitive nature of 229 transported data. The behavior of such applications is unchanged 230 when the DTLS protocol is used to secure communication, since the 231 DTLS protocol does not compensate for lost or reordered data traffic. 233 TLS cannot be used directly in datagram environments for the 234 following five reasons: 236 1. TLS relies on an implicit sequence number on records. If a 237 record is not received, then the recipient will use the wrong 238 sequence number when attempting to remove record protection from 239 subsequent records. DTLS solves this problem by adding sequence 240 numbers. 242 2. The TLS handshake is a lock-step cryptographic handshake. 243 Messages must be transmitted and received in a defined order; any 244 other order is an error. DTLS handshake messages are also 245 assigned sequence numbers to enable reassembly in the correct 246 order in case datagrams are lost or reordered. 248 3. During the handshake, messages are implicitly acknowledged by 249 other handshake messages, but the last flight of messages and 250 post-handshake messages (such as the NewSessionTicket message) do 251 not result in any direct response that would allow the sender to 252 detect loss. DTLS adds an acknowledgment message to enable 253 better loss recovery. 255 4. Handshake messages are potentially larger than can be contained 256 in a single datagram. DTLS adds fields to handshake messages to 257 support fragmentation and reassembly. 259 5. Datagram transport protocols, like UDP, are susceptible to 260 abusive behavior effecting denial of service attacks against 261 nonparticipants. DTLS adds a return-routability check that uses 262 the TLS HelloRetryRequest message (see Section 5.1 for details). 264 3.1. Packet Loss 266 DTLS uses a simple retransmission timer to handle packet loss. 267 Figure 1 demonstrates the basic concept, using the first phase of the 268 DTLS handshake: 270 Client Server 271 ------ ------ 272 ClientHello ------> 274 X<-- HelloRetryRequest 275 (lost) 277 [Timer Expires] 279 ClientHello ------> 280 (retransmit) 282 Figure 1: DTLS retransmission example 284 Once the client has transmitted the ClientHello message, it expects 285 to see a HelloRetryRequest or a ServerHello from the server. 286 However, if the server's message is lost, the client knows that 287 either the ClientHello or the response from the server has been lost 288 and retransmits. When the server receives the retransmission, it 289 knows to retransmit. 291 The server also maintains a retransmission timer and retransmits when 292 that timer expires. 294 Note that timeout and retransmission do not apply to the 295 HelloRetryRequest since this would require creating state on the 296 server. The HelloRetryRequest is designed to be small enough that it 297 will not itself be fragmented, thus avoiding concerns about 298 interleaving multiple HelloRetryRequests. 300 3.2. Reordering 302 In DTLS, each handshake message is assigned a specific sequence 303 number. When a peer receives a handshake message, it can quickly 304 determine whether that message is the next message it expects. If it 305 is, then it processes it. If not, it queues it for future handling 306 once all previous messages have been received. 308 3.3. Message Size 310 TLS and DTLS handshake messages can be quite large (in theory up to 311 2^24-1 bytes, in practice many kilobytes). By contrast, UDP 312 datagrams are often limited to less than 1500 bytes if IP 313 fragmentation is not desired. In order to compensate for this 314 limitation, each DTLS handshake message may be fragmented over 315 several DTLS records, each of which is intended to fit in a single 316 UDP datagram. Each DTLS handshake message contains both a fragment 317 offset and a fragment length. Thus, a recipient in possession of all 318 bytes of a handshake message can reassemble the original unfragmented 319 message. 321 3.4. Replay Detection 323 DTLS optionally supports record replay detection. The technique used 324 is the same as in IPsec AH/ESP, by maintaining a bitmap window of 325 received records. Records that are too old to fit in the window and 326 records that have previously been received are silently discarded. 327 The replay detection feature is optional, since packet duplication is 328 not always malicious, but can also occur due to routing errors. 329 Applications may conceivably detect duplicate packets and accordingly 330 modify their data transmission strategy. 332 4. The DTLS Record Layer 334 The DTLS record layer is different from the TLS 1.3 record layer. 336 1. The DTLSCiphertext structure omits the superfluous version number 337 and type fields. 339 2. DTLS adds an epoch and sequence number to the TLS record header. 340 This sequence number allows the recipient to correctly verify the 341 DTLS MAC. However, the number of bits used for the epoch and 342 sequence number fields in the DTLSCiphertext structure have been 343 reduced from those in previous versions. 345 3. The DTLSCiphertext structure has a variable length header. 347 Note that the DTLS 1.3 record layer is different from the DTLS 1.2 348 record layer. 350 DTLSPlaintext records are used to send unprotected records and 351 DTLSCiphertext records are used to send protected records. 353 The DTLS record formats are shown below. Unless explicitly stated 354 the meaning of the fields is unchanged from previous TLS / DTLS 355 versions. 357 struct { 358 ContentType type; 359 ProtocolVersion legacy_record_version; 360 uint16 epoch = 0 // DTLS field 361 uint48 sequence_number; // DTLS field 362 uint16 length; 363 opaque fragment[DTLSPlaintext.length]; 364 } DTLSPlaintext; 366 struct { 367 opaque content[DTLSPlaintext.length]; 368 ContentType type; 369 uint8 zeros[length_of_padding]; 370 } DTLSInnerPlaintext; 372 struct { 373 opaque unified_hdr[variable]; 374 opaque encrypted_record[length]; 375 } DTLSCiphertext; 377 Figure 2: DTLS 1.3 Record Format 379 unified_hdr: The unified_hdr is a field of variable length, as shown 380 in Figure 3. 382 encrypted_record: Identical to the encrypted_record field in a TLS 383 1.3 record. 385 The DTLSCiphertext header is tightly bit-packed, as shown below: 387 0 1 2 3 4 5 6 7 388 +-+-+-+-+-+-+-+-+ 389 |0|0|1|C|S|L|E E| 390 +-+-+-+-+-+-+-+-+ 391 | Connection ID | Legend: 392 | (if any, | 393 / length as / C - Connection ID (CID) present 394 | negotiated) | S - Sequence number length 395 +-+-+-+-+-+-+-+-+ L - Length present 396 | 8 or 16 bit | E - Epoch 397 |Sequence Number| 398 +-+-+-+-+-+-+-+-+ 399 | 16 bit Length | 400 | (if present) | 401 +-+-+-+-+-+-+-+-+ 403 Figure 3: DTLS 1.3 CipherText Header 405 Fixed Bits: The three high bits of the first byte of the 406 DTLSCiphertext header are set to 001. 408 C: The C bit (0x10) is set if the Connection ID is present. 410 S: The S bit (0x08) indicates the size of the sequence number. 0 411 means an 8-bit sequence number, 1 means 16-bit. 413 L: The L bit (0x04) is set if the length is present. 415 E: The two low bits (0x03) include the low order two bits of the 416 epoch. 418 Connection ID: Variable length CID. The CID concept is described in 419 [DTLS-CID]. An example can be found in 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 above is used as it appears on the wire 492 as the additional data value for the AEAD function. Note that this 493 design is different from the additional data calculation for DTLS 1.2 494 and for DTLS 1.2 with Connection ID. 496 4.1. Determining the Header Format 498 Implementations can distinguish the two header formats by examining 499 the first byte: 501 - If the first byte is alert(21), handshake(22), or ack(proposed, 502 25), the record MUST be interpreted as a DTLSPlaintext record. 504 - If the first byte is any other value, then receivers MUST check to 505 see if the leading bits of the first byte are 001. If so, the 506 implementation MUST process the record as DTLSCiphertext; the true 507 content type will be inside the protected portion. 509 - Otherwise, the record MUST be rejected as if it had failed 510 deprotection, as described in Section 4.5.2. 512 4.2. Sequence Number and Epoch 514 DTLS uses an explicit or partly explicit sequence number, rather than 515 an implicit one, carried in the sequence_number field of the record. 516 Sequence numbers are maintained separately for each epoch, with each 517 sequence_number initially being 0 for each epoch. 519 The epoch number is initially zero and is incremented each time 520 keying material changes and a sender aims to rekey. More details are 521 provided in Section 6.1. 523 4.2.1. Processing Guidelines 525 Because DTLS records could be reordered, a record from epoch M may be 526 received after epoch N (where N > M) has begun. In general, 527 implementations SHOULD discard records from earlier epochs, but if 528 packet loss causes noticeable problems implementations MAY choose to 529 retain keying material from previous epochs for up to the default MSL 530 specified for TCP [RFC0793] to allow for packet reordering. (Note 531 that the intention here is that implementers use the current guidance 532 from the IETF for MSL, as specified in [RFC0793] or successors not 533 that they attempt to interrogate the MSL that the system TCP stack is 534 using.) 536 Conversely, it is possible for records that are protected with the 537 new epoch to be received prior to the completion of a handshake. For 538 instance, the server may send its Finished message and then start 539 transmitting data. Implementations MAY either buffer or discard such 540 records, though when DTLS is used over reliable transports (e.g., 541 SCTP [RFC4960]), they SHOULD be buffered and processed once the 542 handshake completes. Note that TLS's restrictions on when records 543 may be sent still apply, and the receiver treats the records as if 544 they were sent in the right order. 546 Implementations MUST send retransmissions of lost messages using the 547 same epoch and keying material as the original transmission. 549 Implementations MUST either abandon an association or re-key prior to 550 allowing the sequence number to wrap. 552 Implementations MUST NOT allow the epoch to wrap, but instead MUST 553 establish a new association, terminating the old association. 555 4.2.2. Reconstructing the Sequence Number and Epoch 557 When receiving protected DTLS records message, the recipient does not 558 have a full epoch or sequence number value and so there is some 559 opportunity for ambiguity. Because the full epoch and sequence 560 number are used to compute the per-record nonce, failure to 561 reconstruct these values leads to failure to deprotect the record, 562 and so implementations MAY use a mechanism of their choice to 563 determine the full values. This section provides an algorithm which 564 is comparatively simple and which implementations are RECOMMENDED to 565 follow. 567 If the epoch bits match those of the current epoch, then 568 implementations SHOULD reconstruct the sequence number by computing 569 the full sequence number which is numerically closest to one plus the 570 sequence number of the highest successfully deprotected record. 572 During the handshake phase, the epoch bits unambiguously indicate the 573 correct key to use. After the handshake is complete, if the epoch 574 bits do not match those from the current epoch implementations SHOULD 575 use the most recent past epoch which has matching bits, and then 576 reconstruct the sequence number as described above. 578 4.2.3. Sequence Number Encryption 580 In DTLS 1.3, when records are encrypted, record sequence numbers are 581 also encrypted. The basic pattern is that the underlying encryption 582 algorithm used with the AEAD algorithm is used to generate a mask 583 which is then XORed with the sequence number. 585 When the AEAD is based on AES, then the Mask is generated by 586 computing AES-ECB on the first 16 bytes of the ciphertext: 588 Mask = AES-ECB(sn_key, Ciphertext[0..15]) 590 When the AEAD is based on ChaCha20, then the mask is generated by 591 treating the first 4 bytes of the ciphertext as the block counter and 592 the next 12 bytes as the nonce, passing them to the ChaCha20 block 593 function (Section 2.3 of [CHACHA]): 595 Mask = ChaCha20(sn_key, Ciphertext[0..3], Ciphertext[4..15]) 597 The sn_key is computed as follows: 599 [sender]_sn_key = HKDF-Expand-Label(Secret, "sn" , "", key_length) 601 [sender] denotes the sending side. The Secret value to be used is 602 described in Section 7.3 of [TLS13]. 604 The encrypted sequence number is computed by XORing the leading bytes 605 of the Mask with the sequence number. Decryption is accomplished by 606 the same process. 608 This procedure requires the ciphertext length be at least 16 bytes. 609 Receivers MUST reject shorter records as if they had failed 610 deprotection, as described in Section 4.5.2. Senders MUST pad short 611 plaintexts out (using the conventional record padding mechanism) in 612 order to make a suitable-length ciphertext. Note most of the DTLS 613 AEAD algorithms have a 16-byte authentication tag and need no 614 padding. However, some algorithms such as TLS_AES_128_CCM_8_SHA256 615 have a shorter authentication tag and may require padding for short 616 inputs. 618 Note that sequence number encryption is only applied to the 619 DTLSCiphertext structure and not to the DTLSPlaintext structure, 620 which also contains a sequence number. 622 4.3. Transport Layer Mapping 624 DTLS messages MAY be fragmented into multiple DTLS records. Each 625 DTLS record MUST fit within a single datagram. In order to avoid IP 626 fragmentation, clients of the DTLS record layer SHOULD attempt to 627 size records so that they fit within any PMTU estimates obtained from 628 the record layer. 630 Multiple DTLS records MAY be placed in a single datagram. Records 631 are encoded consecutively. The length field from DTLS records 632 containing that field can be used to determine the boundaries between 633 records. The final record in a datagram can omit the length field. 634 The first byte of the datagram payload MUST be the beginning of a 635 record. Records MUST NOT span datagrams. 637 DTLS records, as defined in this document, do not contain any 638 association identifiers and applications must arrange to multiplex 639 between associations. With UDP, the host/port number is used to look 640 up the appropriate security association for incoming records. 641 However, the CID extension defined in [DTLS-CID] adds an association 642 identifier to DTLS records. 644 Some transports, such as DCCP [RFC4340], provide their own sequence 645 numbers. When carried over those transports, both the DTLS and the 646 transport sequence numbers will be present. Although this introduces 647 a small amount of inefficiency, the transport layer and DTLS sequence 648 numbers serve different purposes; therefore, for conceptual 649 simplicity, it is superior to use both sequence numbers. 651 Some transports provide congestion control for traffic carried over 652 them. If the congestion window is sufficiently narrow, DTLS 653 handshake retransmissions may be held rather than transmitted 654 immediately, potentially leading to timeouts and spurious 655 retransmission. When DTLS is used over such transports, care should 656 be taken not to overrun the likely congestion window. [RFC5238] 657 defines a mapping of DTLS to DCCP that takes these issues into 658 account. 660 4.4. PMTU Issues 662 In general, DTLS's philosophy is to leave PMTU discovery to the 663 application. However, DTLS cannot completely ignore PMTU for three 664 reasons: 666 - The DTLS record framing expands the datagram size, thus lowering 667 the effective PMTU from the application's perspective. 669 - In some implementations, the application may not directly talk to 670 the network, in which case the DTLS stack may absorb ICMP 671 [RFC1191] "Datagram Too Big" indications or ICMPv6 [RFC4443] 672 "Packet Too Big" indications. 674 - The DTLS handshake messages can exceed the PMTU. 676 In order to deal with the first two issues, the DTLS record layer 677 SHOULD behave as described below. 679 If PMTU estimates are available from the underlying transport 680 protocol, they should be made available to upper layer protocols. In 681 particular: 683 - For DTLS over UDP, the upper layer protocol SHOULD be allowed to 684 obtain the PMTU estimate maintained in the IP layer. 686 - For DTLS over DCCP, the upper layer protocol SHOULD be allowed to 687 obtain the current estimate of the PMTU. 689 - For DTLS over TCP or SCTP, which automatically fragment and 690 reassemble datagrams, there is no PMTU limitation. However, the 691 upper layer protocol MUST NOT write any record that exceeds the 692 maximum record size of 2^14 bytes. 694 Note that DTLS does not defend against spoofed ICMP messages; 695 implementations SHOULD ignore any such messages that indicate PMTUs 696 below the IPv4 and IPv6 minimums of 576 and 1280 bytes respectively 698 The DTLS record layer SHOULD allow the upper layer protocol to 699 discover the amount of record expansion expected by the DTLS 700 processing. 702 If there is a transport protocol indication (either via ICMP or via a 703 refusal to send the datagram as in Section 14 of [RFC4340]), then the 704 DTLS record layer MUST inform the upper layer protocol of the error. 706 The DTLS record layer SHOULD NOT interfere with upper layer protocols 707 performing PMTU discovery, whether via [RFC1191] or [RFC4821] 708 mechanisms. In particular: 710 - Where allowed by the underlying transport protocol, the upper 711 layer protocol SHOULD be allowed to set the state of the DF bit 712 (in IPv4) or prohibit local fragmentation (in IPv6). 714 - If the underlying transport protocol allows the application to 715 request PMTU probing (e.g., DCCP), the DTLS record layer SHOULD 716 honor this request. 718 The final issue is the DTLS handshake protocol. From the perspective 719 of the DTLS record layer, this is merely another upper layer 720 protocol. However, DTLS handshakes occur infrequently and involve 721 only a few round trips; therefore, the handshake protocol PMTU 722 handling places a premium on rapid completion over accurate PMTU 723 discovery. In order to allow connections under these circumstances, 724 DTLS implementations SHOULD follow the following rules: 726 - If the DTLS record layer informs the DTLS handshake layer that a 727 message is too big, it SHOULD immediately attempt to fragment it, 728 using any existing information about the PMTU. 730 - If repeated retransmissions do not result in a response, and the 731 PMTU is unknown, subsequent retransmissions SHOULD back off to a 732 smaller record size, fragmenting the handshake message as 733 appropriate. This standard does not specify an exact number of 734 retransmits to attempt before backing off, but 2-3 seems 735 appropriate. 737 4.5. Record Payload Protection 739 Like TLS, DTLS transmits data as a series of protected records. The 740 rest of this section describes the details of that format. 742 4.5.1. Anti-Replay 744 Each DTLS record contains a sequence number to provide replay 745 protection. Sequence number verification SHOULD be performed using 746 the following sliding window procedure, borrowed from Section 3.4.3 747 of [RFC4303]. 749 The received record counter for a session MUST be initialized to zero 750 when that session is established. For each received record, the 751 receiver MUST verify that the record contains a sequence number that 752 does not duplicate the sequence number of any other record received 753 during the lifetime of the session. This check SHOULD happen after 754 deprotecting the record; otherwise the record discard might itself 755 serve as a timing channel for the record number. Note that 756 decompressing the records number is still a potential timing channel 757 for the record number, though a less powerful one than whether it was 758 deprotected. 760 Duplicates are rejected through the use of a sliding receive window. 761 (How the window is implemented is a local matter, but the following 762 text describes the functionality that the implementation must 763 exhibit.) The receiver SHOULD pick a window large enough to handle 764 any plausible reordering, which depends on the data rate. (The 765 receiver does not notify the sender of the window size.) 766 The "right" edge of the window represents the highest validated 767 sequence number value received on the session. Records that contain 768 sequence numbers lower than the "left" edge of the window are 769 rejected. Records falling within the window are checked against a 770 list of received records within the window. An efficient means for 771 performing this check, based on the use of a bit mask, is described 772 in Section 3.4.3 of [RFC4303]. If the received record falls within 773 the window and is new, or if the record is to the right of the 774 window, then the record is new. 776 The window MUST NOT be updated until the record has been deprotected 777 successfully. 779 4.5.2. Handling Invalid Records 781 Unlike TLS, DTLS is resilient in the face of invalid records (e.g., 782 invalid formatting, length, MAC, etc.). In general, invalid records 783 SHOULD be silently discarded, thus preserving the association; 784 however, an error MAY be logged for diagnostic purposes. 785 Implementations which choose to generate an alert instead, MUST 786 generate error alerts to avoid attacks where the attacker repeatedly 787 probes the implementation to see how it responds to various types of 788 error. Note that if DTLS is run over UDP, then any implementation 789 which does this will be extremely susceptible to denial-of-service 790 (DoS) attacks because UDP forgery is so easy. Thus, this practice is 791 NOT RECOMMENDED for such transports, both to increase the reliability 792 of DTLS service and to avoid the risk of spoofing attacks sending 793 traffic to unrelated third parties. 795 If DTLS is being carried over a transport that is resistant to 796 forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts 797 because an attacker will have difficulty forging a datagram that will 798 not be rejected by the transport layer. 800 5. The DTLS Handshake Protocol 802 DTLS 1.3 re-uses the TLS 1.3 handshake messages and flows, with the 803 following changes: 805 1. To handle message loss, reordering, and fragmentation 806 modifications to the handshake header are necessary. 808 2. Retransmission timers are introduced to handle message loss. 810 3. A new ACK content type has been added for reliable message 811 delivery of handshake messages. 813 Note that TLS 1.3 already supports a cookie extension, which is used 814 to prevent denial-of-service attacks. This DoS prevention mechanism 815 is described in more detail below since UDP-based protocols are more 816 vulnerable to amplification attacks than a connection-oriented 817 transport like TCP that performs return-routability checks as part of 818 the connection establishment. 820 DTLS implementations do not use the TLS 1.3 "compatibility mode" 821 described in Section D.4 of [TLS13]. DTLS servers MUST NOT echo the 822 "session_id" value from the client and endpoints MUST NOT send 823 ChangeCipherSpec messages. 825 With these exceptions, the DTLS message formats, flows, and logic are 826 the same as those of TLS 1.3. 828 5.1. Denial-of-Service Countermeasures 830 Datagram security protocols are extremely susceptible to a variety of 831 DoS attacks. Two attacks are of particular concern: 833 1. An attacker can consume excessive resources on the server by 834 transmitting a series of handshake initiation requests, causing 835 the server to allocate state and potentially to perform expensive 836 cryptographic operations. 838 2. An attacker can use the server as an amplifier by sending 839 connection initiation messages with a forged source of the 840 victim. The server then sends its response to the victim 841 machine, thus flooding it. Depending on the selected parameters 842 this response message can be quite large, as it is the case for a 843 Certificate message. 845 In order to counter both of these attacks, DTLS borrows the stateless 846 cookie technique used by Photuris [RFC2522] and IKE [RFC7296]. When 847 the client sends its ClientHello message to the server, the server 848 MAY respond with a HelloRetryRequest message. The HelloRetryRequest 849 message, as well as the cookie extension, is defined in TLS 1.3. The 850 HelloRetryRequest message contains a stateless cookie generated using 851 the technique of [RFC2522]. The client MUST retransmit the 852 ClientHello with the cookie added as an extension. The server then 853 verifies the cookie and proceeds with the handshake only if it is 854 valid. This mechanism forces the attacker/client to be able to 855 receive the cookie, which makes DoS attacks with spoofed IP addresses 856 difficult. This mechanism does not provide any defense against DoS 857 attacks mounted from valid IP addresses. 859 The DTLS 1.3 specification changes the way how cookies are exchanged 860 compared to DTLS 1.2. DTLS 1.3 re-uses the HelloRetryRequest message 861 and conveys the cookie to the client via an extension. The client 862 receiving the cookie uses the same extension to place the cookie 863 subsequently into a ClientHello message. DTLS 1.2 on the other hand 864 used a separate message, namely the HelloVerifyRequest, to pass a 865 cookie to the client and did not utilize the extension mechanism. 866 For backwards compatibility reasons, the cookie field in the 867 ClientHello is present in DTLS 1.3 but is ignored by a DTLS 1.3 868 compliant server implementation. 870 The exchange is shown in Figure 5. Note that the figure focuses on 871 the cookie exchange; all other extensions are omitted. 873 Client Server 874 ------ ------ 875 ClientHello ------> 877 <----- HelloRetryRequest 878 + cookie 880 ClientHello ------> 881 + cookie 883 [Rest of handshake] 885 Figure 5: DTLS exchange with HelloRetryRequest containing the 886 "cookie" extension 888 The cookie extension is defined in Section 4.2.2 of [TLS13]. When 889 sending the initial ClientHello, the client does not have a cookie 890 yet. In this case, the cookie extension is omitted and the 891 legacy_cookie field in the ClientHello message SHOULD be set to a 892 zero length vector (i.e., a single zero byte length field) and MUST 893 be ignored by a server negotiating DTLS 1.3. 895 When responding to a HelloRetryRequest, the client MUST create a new 896 ClientHello message following the description in Section 4.1.2 of 897 [TLS13]. 899 If the HelloRetryRequest message is used, the initial ClientHello and 900 the HelloRetryRequest are included in the calculation of the 901 transcript hash. The computation of the message hash for the 902 HelloRetryRequest is done according to the description in 903 Section 4.4.1 of [TLS13]. 905 The handshake transcript is not reset with the second ClientHello and 906 a stateless server-cookie implementation requires the transcript of 907 the HelloRetryRequest to be stored in the cookie or the internal 908 state of the hash algorithm, since only the hash of the transcript is 909 required for the handshake to complete. 911 When the second ClientHello is received, the server can verify that 912 the cookie is valid and that the client can receive packets at the 913 given IP address. If the client's apparent IP address is embedded in 914 the cookie, this prevents an attacker from generating an acceptable 915 ClientHello apparently from another user. 917 One potential attack on this scheme is for the attacker to collect a 918 number of cookies from different addresses where it controls 919 endpoints and then reuse them to attack the server. The server can 920 defend against this attack by changing the secret value frequently, 921 thus invalidating those cookies. If the server wishes to allow 922 legitimate clients to handshake through the transition (e.g., a 923 client received a cookie with Secret 1 and then sent the second 924 ClientHello after the server has changed to Secret 2), the server can 925 have a limited window during which it accepts both secrets. 926 [RFC7296] suggests adding a key identifier to cookies to detect this 927 case. An alternative approach is simply to try verifying with both 928 secrets. It is RECOMMENDED that servers implement a key rotation 929 scheme that allows the server to manage keys with overlapping 930 lifetime. 932 Alternatively, the server can store timestamps in the cookie and 933 reject cookies that were generated outside a certain interval of 934 time. 936 DTLS servers SHOULD perform a cookie exchange whenever a new 937 handshake is being performed. If the server is being operated in an 938 environment where amplification is not a problem, the server MAY be 939 configured not to perform a cookie exchange. The default SHOULD be 940 that the exchange is performed, however. In addition, the server MAY 941 choose not to do a cookie exchange when a session is resumed. 942 Clients MUST be prepared to do a cookie exchange with every 943 handshake. 945 If a server receives a ClientHello with an invalid cookie, it MUST 946 NOT terminate the handshake with an "illegal_parameter" alert. This 947 allows the client to restart the connection from scratch without a 948 cookie. 950 As described in Section 4.1.4 of [TLS13], clients MUST abort the 951 handshake with an "unexpected_message" alert in response to any 952 second HelloRetryRequest which was sent in the same connection (i.e., 953 where the ClientHello was itself in response to a HelloRetryRequest). 955 5.2. DTLS Handshake Message Format 957 In order to support message loss, reordering, and message 958 fragmentation, DTLS modifies the TLS 1.3 handshake header: 960 enum { 961 client_hello(1), 962 server_hello(2), 963 new_session_ticket(4), 964 end_of_early_data(5), 965 encrypted_extensions(8), 966 certificate(11), 967 certificate_request(13), 968 certificate_verify(15), 969 finished(20), 970 key_update(24), 971 message_hash(254), 972 (255) 973 } HandshakeType; 975 struct { 976 HandshakeType msg_type; /* handshake type */ 977 uint24 length; /* bytes in message */ 978 uint16 message_seq; /* DTLS-required field */ 979 uint24 fragment_offset; /* DTLS-required field */ 980 uint24 fragment_length; /* DTLS-required field */ 981 select (HandshakeType) { 982 case client_hello: ClientHello; 983 case server_hello: ServerHello; 984 case end_of_early_data: EndOfEarlyData; 985 case encrypted_extensions: EncryptedExtensions; 986 case certificate_request: CertificateRequest; 987 case certificate: Certificate; 988 case certificate_verify: CertificateVerify; 989 case finished: Finished; 990 case new_session_ticket: NewSessionTicket; 991 case key_update: KeyUpdate; 992 } body; 993 } Handshake; 995 The first message each side transmits in each association always has 996 message_seq = 0. Whenever a new message is generated, the 997 message_seq value is incremented by one. When a message is 998 retransmitted, the old message_seq value is re-used, i.e., not 999 incremented. From the perspective of the DTLS record layer, the 1000 retransmission is a new record. This record will have a new 1001 DTLSPlaintext.sequence_number value. 1003 DTLS implementations maintain (at least notionally) a 1004 next_receive_seq counter. This counter is initially set to zero. 1005 When a handshake message is received, if its message_seq value 1006 matches next_receive_seq, next_receive_seq is incremented and the 1007 message is processed. If the sequence number is less than 1008 next_receive_seq, the message MUST be discarded. If the sequence 1009 number is greater than next_receive_seq, the implementation SHOULD 1010 queue the message but MAY discard it. (This is a simple space/ 1011 bandwidth tradeoff). 1013 In addition to the handshake messages that are deprecated by the TLS 1014 1.3 specification, DTLS 1.3 furthermore deprecates the 1015 HelloVerifyRequest message originally defined in DTLS 1.0. DTLS 1016 1.3-compliant implements MUST NOT use the HelloVerifyRequest to 1017 execute a return-routability check. A dual-stack DTLS 1.2/DTLS 1.3 1018 client MUST, however, be prepared to interact with a DTLS 1.2 server. 1020 5.3. ClientHello Message 1022 The format of the ClientHello used by a DTLS 1.3 client differs from 1023 the TLS 1.3 ClientHello format as shown below. 1025 uint16 ProtocolVersion; 1026 opaque Random[32]; 1028 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 1030 struct { 1031 ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2 1032 Random random; 1033 opaque legacy_session_id<0..32>; 1034 opaque legacy_cookie<0..2^8-1>; // DTLS 1035 CipherSuite cipher_suites<2..2^16-2>; 1036 opaque legacy_compression_methods<1..2^8-1>; 1037 Extension extensions<8..2^16-1>; 1038 } ClientHello; 1040 legacy_version: In previous versions of DTLS, this field was used 1041 for version negotiation and represented the highest version number 1042 supported by the client. Experience has shown that many servers 1043 do not properly implement version negotiation, leading to "version 1044 intolerance" in which the server rejects an otherwise acceptable 1045 ClientHello with a version number higher than it supports. In 1046 DTLS 1.3, the client indicates its version preferences in the 1047 "supported_versions" extension (see Section 4.2.1 of [TLS13]) and 1048 the legacy_version field MUST be set to {254, 253}, which was the 1049 version number for DTLS 1.2. The version fields for DTLS 1.0 and 1050 DTLS 1.2 are 0xfeff and 0xfefd (to match the wire versions) but 1051 the version field for DTLS 1.3 is 0x0304. 1053 random: Same as for TLS 1.3. 1055 legacy_session_id: Same as for TLS 1.3. 1057 legacy_cookie: A DTLS 1.3-only client MUST set the legacy_cookie 1058 field to zero length. If a DTLS 1.3 ClientHello is received with 1059 any other value in this field, the server MUST abort the handshake 1060 with an "illegal_parameter" alert. 1062 cipher_suites: Same as for TLS 1.3. 1064 legacy_compression_methods: Same as for TLS 1.3. 1066 extensions: Same as for TLS 1.3. 1068 5.4. Handshake Message Fragmentation and Reassembly 1070 Each DTLS message MUST fit within a single transport layer datagram. 1071 However, handshake messages are potentially bigger than the maximum 1072 record size. Therefore, DTLS provides a mechanism for fragmenting a 1073 handshake message over a number of records, each of which can be 1074 transmitted separately, thus avoiding IP fragmentation. 1076 When transmitting the handshake message, the sender divides the 1077 message into a series of N contiguous data ranges. The ranges MUST 1078 NOT overlap. The sender then creates N handshake messages, all with 1079 the same message_seq value as the original handshake message. Each 1080 new message is labeled with the fragment_offset (the number of bytes 1081 contained in previous fragments) and the fragment_length (the length 1082 of this fragment). The length field in all messages is the same as 1083 the length field of the original message. An unfragmented message is 1084 a degenerate case with fragment_offset=0 and fragment_length=length. 1085 Each range MUST be delivered in a single UDP datagram. 1087 When a DTLS implementation receives a handshake message fragment, it 1088 MUST buffer it until it has the entire handshake message. DTLS 1089 implementations MUST be able to handle overlapping fragment ranges. 1090 This allows senders to retransmit handshake messages with smaller 1091 fragment sizes if the PMTU estimate changes. 1093 Note that as with TLS, multiple handshake messages may be placed in 1094 the same DTLS record, provided that there is room and that they are 1095 part of the same flight. Thus, there are two acceptable ways to pack 1096 two DTLS messages into the same datagram: in the same record or in 1097 separate records. 1099 5.5. End Of Early Data 1101 The DTLS 1.3 handshake has one important difference from the TLS 1.3 1102 handshake: the EndOfEarlyData message is omitted both from the wire 1103 and the handshake transcript: because DTLS records have epochs, 1104 EndOfEarlyData is not necessary to determine when the early data is 1105 complete, and because DTLS is lossy, attackers can trivially mount 1106 the deletion attacks that EndOfEarlyData prevents in TLS. Servers 1107 SHOULD aggressively age out the epoch 1 keys upon receiving the first 1108 epoch 2 record and SHOULD NOT accept epoch 1 data after the first 1109 epoch 3 record is received. (See Section 6.1 for the definitions of 1110 each epoch.) 1112 5.6. DTLS Handshake Flights 1114 DTLS messages are grouped into a series of message flights, according 1115 to the diagrams below. 1117 Client Server 1119 ClientHello +----------+ 1120 + key_share* | Flight 1 | 1121 + pre_shared_key* --------> +----------+ 1123 +----------+ 1124 <-------- HelloRetryRequest | Flight 2 | 1125 + cookie +----------+ 1127 ClientHello +----------+ 1128 + key_share* | Flight 3 | 1129 + pre_shared_key* --------> +----------+ 1130 + cookie 1132 ServerHello 1133 + key_share* 1134 + pre_shared_key* +----------+ 1135 {EncryptedExtensions} | Flight 4 | 1136 {CertificateRequest*} +----------+ 1137 {Certificate*} 1138 {CertificateVerify*} 1139 <-------- {Finished} 1140 [Application Data*] 1142 {Certificate*} +----------+ 1143 {CertificateVerify*} | Flight 5 | 1144 {Finished} --------> +----------+ 1145 [Application Data] 1147 +----------+ 1148 <-------- [ACK] | Flight 6 | 1149 [Application Data*] +----------+ 1151 [Application Data] <-------> [Application Data] 1153 Figure 6: Message flights for a full DTLS Handshake (with cookie 1154 exchange) 1156 ClientHello +----------+ 1157 + pre_shared_key | Flight 1 | 1158 + key_share* --------> +----------+ 1160 ServerHello 1161 + pre_shared_key +----------+ 1162 + key_share* | Flight 2 | 1163 {EncryptedExtensions} +----------+ 1164 <-------- {Finished} 1165 [Application Data*] 1166 +----------+ 1167 {Finished} --------> | Flight 3 | 1168 [Application Data*] +----------+ 1170 +----------+ 1171 <-------- [ACK] | Flight 4 | 1172 [Application Data*] +----------+ 1174 [Application Data] <-------> [Application Data] 1176 Figure 7: Message flights for resumption and PSK handshake (without 1177 cookie exchange) 1179 Client Server 1181 ClientHello 1182 + early_data 1183 + psk_key_exchange_modes +----------+ 1184 + key_share* | Flight 1 | 1185 + pre_shared_key +----------+ 1186 (Application Data*) --------> 1188 ServerHello 1189 + pre_shared_key 1190 + key_share* +----------+ 1191 {EncryptedExtensions} | Flight 2 | 1192 {Finished} +----------+ 1193 <-------- [Application Data*] 1195 +----------+ 1196 {Finished} --------> | Flight 3 | 1197 [Application Data*] +----------+ 1199 +----------+ 1200 <-------- [ACK] | Flight 4 | 1201 [Application Data*] +----------+ 1203 [Application Data] <-------> [Application Data] 1205 Figure 8: Message flights for the Zero-RTT handshake 1207 Client Server 1209 +----------+ 1210 <-------- [NewSessionTicket] | Flight 1 | 1211 +----------+ 1213 +----------+ 1214 [ACK] --------> | Flight 2 | 1215 +----------+ 1217 Figure 9: Message flights for the new session ticket message 1219 Note: The application data sent by the client is not included in the 1220 timeout and retransmission calculation. 1222 5.7. Timeout and Retransmission 1224 5.7.1. State Machine 1226 DTLS uses a simple timeout and retransmission scheme with the state 1227 machine shown in Figure 10. Because DTLS clients send the first 1228 message (ClientHello), they start in the PREPARING state. DTLS 1229 servers start in the WAITING state, but with empty buffers and no 1230 retransmit timer. 1232 +-----------+ 1233 | PREPARING | 1234 +----------> | | 1235 | | | 1236 | +-----------+ 1237 | | 1238 | | Buffer next flight 1239 | | 1240 | \|/ 1241 | +-----------+ 1242 | | | 1243 | | SENDING |<------------------+ 1244 | | | | 1245 | +-----------+ | 1246 Receive | | | 1247 next | | Send flight or partial | 1248 flight | | flight | 1249 | +---------------+ | 1250 | | | Set retransmit timer | 1251 | | \|/ | 1252 | | +-----------+ | 1253 | | | | | 1254 +--)---------| WAITING |-------------------+ 1255 | | +----->| | Timer expires | 1256 | | | +-----------+ | 1257 | | | | | | | 1258 | | | | | | | 1259 | | +----------+ | +--------------------+ 1260 | | Receive record | Read retransmit or ACK 1261 Receive | | Send ACK | 1262 last | | | 1263 flight | | | Receive ACK 1264 | | | for last flight 1265 \|/\|/ | 1266 | 1267 +-----------+ | 1268 | | <---------+ 1269 | FINISHED | 1270 | | 1271 +-----------+ 1272 | /|\ 1273 | | 1274 | | 1275 +---+ 1277 Server read retransmit 1278 Retransmit ACK 1280 Figure 10: DTLS timeout and retransmission state machine 1282 The state machine has four basic states: PREPARING, SENDING, WAITING, 1283 and FINISHED. 1285 In the PREPARING state, the implementation does whatever computations 1286 are necessary to prepare the next flight of messages. It then 1287 buffers them up for transmission (emptying the buffer first) and 1288 enters the SENDING state. 1290 In the SENDING state, the implementation transmits the buffered 1291 flight of messages. If the implementation has received one or more 1292 ACKs (see Section 7) from the peer, then it SHOULD omit any messages 1293 or message fragments which have already been ACKed. Once the 1294 messages have been sent, the implementation then enters the FINISHED 1295 state if this is the last flight in the handshake. Or, if the 1296 implementation expects to receive more messages, it sets a retransmit 1297 timer and then enters the WAITING state. 1299 There are four ways to exit the WAITING state: 1301 1. The retransmit timer expires: the implementation transitions to 1302 the SENDING state, where it retransmits the flight, resets the 1303 retransmit timer, and returns to the WAITING state. 1305 2. The implementation reads an ACK from the peer: upon receiving an 1306 ACK for a partial flight (as mentioned in Section 7.1), the 1307 implementation transitions to the SENDING state, where it 1308 retransmits the unacked portion of the flight, resets the 1309 retransmit timer, and returns to the WAITING state. Upon 1310 receiving an ACK for a complete flight, the implementation 1311 cancels all retransmissions and either remains in WAITING, or, if 1312 the ACK was for the final flight, transitions to FINISHED. 1314 3. The implementation reads a retransmitted flight from the peer: 1315 the implementation transitions to the SENDING state, where it 1316 retransmits the flight, resets the retransmit timer, and returns 1317 to the WAITING state. The rationale here is that the receipt of 1318 a duplicate message is the likely result of timer expiry on the 1319 peer and therefore suggests that part of one's previous flight 1320 was lost. 1322 4. The implementation receives some or all next flight of messages: 1323 if this is the final flight of messages, the implementation 1324 transitions to FINISHED. If the implementation needs to send a 1325 new flight, it transitions to the PREPARING state. Partial reads 1326 (whether partial messages or only some of the messages in the 1327 flight) may also trigger the implementation to send an ACK, as 1328 described in Section 7.1. 1330 Because DTLS clients send the first message (ClientHello), they start 1331 in the PREPARING state. DTLS servers start in the WAITING state, but 1332 with empty buffers and no retransmit timer. 1334 In addition, for at least twice the default Maximum Segment Lifetime 1335 (MSL) defined for [RFC0793], when in the FINISHED state, the server 1336 MUST respond to retransmission of the client's second flight with a 1337 retransmit of its ACK. 1339 Note that because of packet loss, it is possible for one side to be 1340 sending application data even though the other side has not received 1341 the first side's Finished message. Implementations MUST either 1342 discard or buffer all application data records for the new epoch 1343 until they have received the Finished message for that epoch. 1344 Implementations MAY treat receipt of application data with a new 1345 epoch prior to receipt of the corresponding Finished message as 1346 evidence of reordering or packet loss and retransmit their final 1347 flight immediately, shortcutting the retransmission timer. 1349 5.7.2. Timer Values 1351 Though timer values are the choice of the implementation, mishandling 1352 of the timer can lead to serious congestion problems; for example, if 1353 many instances of a DTLS time out early and retransmit too quickly on 1354 a congested link. Implementations SHOULD use an initial timer value 1355 of 100 msec (the minimum defined in RFC 6298 [RFC6298]) and double 1356 the value at each retransmission, up to no less than the RFC 6298 1357 maximum of 60 seconds. Application specific profiles, such as those 1358 used for the Internet of Things environment, may recommend longer 1359 timer values. Note that a 100 msec timer is recommended rather than 1360 the 3-second RFC 6298 default in order to improve latency for time- 1361 sensitive applications. Because DTLS only uses retransmission for 1362 handshake and not dataflow, the effect on congestion should be 1363 minimal. 1365 Implementations SHOULD retain the current timer value until a 1366 transmission without loss occurs, at which time the value may be 1367 reset to the initial value. After a long period of idleness, no less 1368 than 10 times the current timer value, implementations may reset the 1369 timer to the initial value. 1371 5.8. CertificateVerify and Finished Messages 1373 CertificateVerify and Finished messages have the same format as in 1374 TLS 1.3. Hash calculations include entire handshake messages, 1375 including DTLS-specific fields: message_seq, fragment_offset, and 1376 fragment_length. However, in order to remove sensitivity to 1377 handshake message fragmentation, the CertificateVerify and the 1378 Finished messages MUST be computed as if each handshake message had 1379 been sent as a single fragment following the algorithm described in 1380 Section 4.4.3 and Section 4.4.4 of [TLS13], respectively. 1382 5.9. Cryptographic Label Prefix 1384 Section 7.1 of [TLS13] specifies that HKDF-Expand-Label uses a label 1385 prefix of "tls13 ". For DTLS 1.3, that label SHALL be "dtls13". 1386 This ensures key separation between DTLS 1.3 and TLS 1.3. Note that 1387 there is no trailing space; this is necessary in order to keep the 1388 overall label size inside of one hash iteration because "DTLS" is one 1389 letter longer than "TLS". 1391 5.10. Alert Messages 1393 Note that Alert messages are not retransmitted at all, even when they 1394 occur in the context of a handshake. However, a DTLS implementation 1395 which would ordinarily issue an alert SHOULD generate a new alert 1396 message if the offending record is received again (e.g., as a 1397 retransmitted handshake message). Implementations SHOULD detect when 1398 a peer is persistently sending bad messages and terminate the local 1399 connection state after such misbehavior is detected. 1401 5.11. Establishing New Associations with Existing Parameters 1403 If a DTLS client-server pair is configured in such a way that 1404 repeated connections happen on the same host/port quartet, then it is 1405 possible that a client will silently abandon one connection and then 1406 initiate another with the same parameters (e.g., after a reboot). 1407 This will appear to the server as a new handshake with epoch=0. In 1408 cases where a server believes it has an existing association on a 1409 given host/port quartet and it receives an epoch=0 ClientHello, it 1410 SHOULD proceed with a new handshake but MUST NOT destroy the existing 1411 association until the client has demonstrated reachability either by 1412 completing a cookie exchange or by completing a complete handshake 1413 including delivering a verifiable Finished message. After a correct 1414 Finished message is received, the server MUST abandon the previous 1415 association to avoid confusion between two valid associations with 1416 overlapping epochs. The reachability requirement prevents off-path/ 1417 blind attackers from destroying associations merely by sending forged 1418 ClientHellos. 1420 Note: it is not always possible to distinguish which association a 1421 given record is from. For instance, if the client performs a 1422 handshake, abandons the connection, and then immediately starts a new 1423 handshake, it may not be possible to tell which connection a given 1424 protected record is for. In these cases, trial decryption MAY be 1425 necessary, though implementations could also use some sort of CID, 1426 such as the one specified in [I-D.ietf-tls-dtls-connection-id]. 1428 6. Example of Handshake with Timeout and Retransmission 1430 The following is an example of a handshake with lost packets and 1431 retransmissions. 1433 Client Server 1434 ------ ------ 1436 Record 0 --------> 1437 ClientHello 1438 (message_seq=0) 1439 +cookie 1441 X<----- Record 0 1442 (lost) ServerHello 1443 (message_seq=1) 1444 EncryptedExtensions 1445 (message_seq=2) 1446 Certificate 1447 (message_seq=3) 1449 <-------- Record 1 1450 CertificateVerify 1451 (message_seq=4) 1452 Finished 1453 (message_seq=5) 1455 Record 1 --------> 1456 ACK [1] 1458 <-------- Record 2 1459 ServerHello 1460 (message_seq=1) 1461 EncryptedExtensions 1462 (message_seq=2) 1463 Certificate 1464 (message_seq=3) 1466 Record 2 --------> 1467 Certificate 1468 (message_seq=2) 1469 CertificateVerify 1470 (message_seq=3) 1471 Finished 1472 (message_seq=4) 1474 <-------- Record 3 1475 ACK [2] 1477 Figure 11: Example DTLS exchange illustrating message loss 1479 6.1. Epoch Values and Rekeying 1481 A recipient of a DTLS message needs to select the correct keying 1482 material in order to process an incoming message. With the 1483 possibility of message loss and re-order an identifier is needed to 1484 determine which cipher state has been used to protect the record 1485 payload. The epoch value fulfills this role in DTLS. In addition to 1486 the key derivation steps described in Section 7 of [TLS13] triggered 1487 by the states during the handshake a sender may want to rekey at any 1488 time during the lifetime of the connection and has to have a way to 1489 indicate that it is updating its sending cryptographic keys. 1491 This version of DTLS assigns dedicated epoch values to messages in 1492 the protocol exchange to allow identification of the correct cipher 1493 state: 1495 - epoch value (0) is used with unencrypted messages. There are 1496 three unencrypted messages in DTLS, namely ClientHello, 1497 ServerHello, and HelloRetryRequest. 1499 - epoch value (1) is used for messages protected using keys derived 1500 from client_early_traffic_secret. Note this epoch is skipped if 1501 the client does not offer early data. 1503 - epoch value (2) is used for messages protected using keys derived 1504 from [sender]_handshake_traffic_secret. Messages transmitted 1505 during the initial handshake, such as EncryptedExtensions, 1506 CertificateRequest, Certificate, CertificateVerify, and Finished 1507 belong to this category. Note, however, post-handshake are 1508 protected under the appropriate application traffic key and are 1509 not included in this category. 1511 - epoch value (3) is used for payloads protected using keys derived 1512 from the initial [sender]_application_traffic_secret_0. This may 1513 include handshake messages, such as post-handshake messages (e.g., 1514 a NewSessionTicket message). 1516 - epoch value (4 to 2^16-1) is used for payloads protected using 1517 keys from the [sender]_application_traffic_secret_N (N>0). 1519 Using these reserved epoch values a receiver knows what cipher state 1520 has been used to encrypt and integrity protect a message. 1521 Implementations that receive a payload with an epoch value for which 1522 no corresponding cipher state can be determined MUST generate a 1523 "unexpected_message" alert. For example, client incorrectly uses 1524 epoch value 5 when sending early application data in a 0-RTT 1525 exchange. A server will not be able to compute the appropriate keys 1526 and will therefore have to respond with an alert. 1528 Note that epoch values do not wrap. If a DTLS implementation would 1529 need to wrap the epoch value, it MUST terminate the connection. 1531 The traffic key calculation is described in Section 7.3 of [TLS13]. 1533 Figure 12 illustrates the epoch values in an example DTLS handshake. 1535 Client Server 1536 ------ ------ 1538 ClientHello 1539 (epoch=0) 1540 --------> 1542 <-------- HelloRetryRequest 1543 (epoch=0) 1545 ClientHello --------> 1546 (epoch=0) 1548 <-------- ServerHello 1549 (epoch=0) 1550 {EncryptedExtensions} 1551 (epoch=2) 1552 {Certificate} 1553 (epoch=2) 1554 {CertificateVerify} 1555 (epoch=2) 1556 {Finished} 1557 (epoch=2) 1559 {Certificate} --------> 1560 (epoch=2) 1561 {CertificateVerify} 1562 (epoch=2) 1563 {Finished} 1564 (epoch=2) 1566 <-------- [ACK] 1567 (epoch=3) 1569 [Application Data] --------> 1570 (epoch=3) 1572 <-------- [Application Data] 1573 (epoch=3) 1575 Some time later ... 1577 (Post-Handshake Message Exchange) 1579 <-------- [NewSessionTicket] 1580 (epoch=3) 1582 [ACK] --------> 1583 (epoch=3) 1585 Some time later ... 1586 (Rekeying) 1588 <-------- [Application Data] 1589 (epoch=4) 1590 [Application Data] --------> 1591 (epoch=4) 1593 Figure 12: Example DTLS exchange with epoch information 1595 7. ACK Message 1597 The ACK message is used by an endpoint to indicate handshake- 1598 containing the TLS records it has received from the other side. ACK 1599 is not a handshake message but is rather a separate content type, 1600 with code point TBD (proposed, 25). This avoids having ACK being 1601 added to the handshake transcript. Note that ACKs can still be sent 1602 in the same UDP datagram as handshake records. 1604 struct { 1605 RecordNumber record_numbers<0..2^16-1>; 1606 } ACK; 1608 record_numbers: a list of the records containing handshake messages 1609 in the current flight which the endpoint has received, in 1610 numerically increasing order. ACKs only cover the current 1611 outstanding flight (this is possible because DTLS is generally a 1612 lockstep protocol). Thus, an ACK from the server would not cover 1613 both the ClientHello and the client's Certificate. 1614 Implementations can accomplish this by clearing their ACK list 1615 upon receiving the start of the next flight. 1617 ACK records MUST be sent with an epoch that is equal to or higher 1618 than the record which is being acknowledged. Implementations SHOULD 1619 simply use the current key. 1621 7.1. Sending ACKs 1623 When an implementation receives a partial flight, it SHOULD generate 1624 an ACK that covers the messages from that flight which it has 1625 received so far. Implementations have some discretion about when to 1626 generate ACKs, but it is RECOMMENDED that they do so under two 1627 circumstances: 1629 - When they receive a message or fragment which is out of order, 1630 either because it is not the next expected message or because it 1631 is not the next piece of the current message. Implementations 1632 MUST NOT send ACKs for handshake messages which they discard as 1633 out-of-order, because otherwise those messages will not be 1634 retransmitted. 1636 - When they have received part of a flight and do not immediately 1637 receive the rest of the flight (which may be in the same UDP 1638 datagram). A reasonable approach here is to set a timer for 1/4 1639 the current retransmit timer value when the first record in the 1640 flight is received and then send an ACK when that timer expires. 1642 In addition, implementations MUST send ACKs upon receiving all of any 1643 flight which they do not respond to with their own messages. 1644 Specifically, this means the client's final flight of the main 1645 handshake, the server's transmission of the NewSessionTicket, and 1646 KeyUpdate messages. ACKs SHOULD NOT be sent for other complete 1647 flights because they are implicitly acknowledged by the receipt of 1648 the next flight, which generally immediately follows the flight. 1649 Each NewSessionTicket or KeyUpdate is an individual flight; in 1650 particular, a KeyUpdate sent in response to a KeyUpdate with 1651 update_requested does not implicitly acknowledge that message. 1652 Implementations MAY acknowledge the records corresponding to each 1653 transmission of that flight or simply acknowledge the most recent 1654 one. 1656 ACKs MUST NOT be sent for other records of any content type other 1657 than handshake or for records which cannot be unprotected. 1659 Note that in some cases it may be necessary to send an ACK which does 1660 not contain any record numbers. For instance, a client might receive 1661 an EncryptedExtensions message prior to receiving a ServerHello. 1662 Because it cannot decrypt the EncryptedExtensions, it cannot safely 1663 acknowledge it (as it might be damaged). If the client does not send 1664 an ACK, the server will eventually retransmit its first flight, but 1665 this might take far longer than the actual round trip time between 1666 client and server. Having the client send an empty ACK shortcuts 1667 this process. 1669 7.2. Receiving ACKs 1671 When an implementation receives an ACK, it SHOULD record that the 1672 messages or message fragments sent in the records being ACKed were 1673 received and omit them from any future retransmissions. Upon receipt 1674 of an ACK for only some messages from a flight, an implementation 1675 SHOULD retransmit the remaining messages or fragments. Note that 1676 this requires implementations to track which messages appear in which 1677 records. Once all the messages in a flight have been acknowledged, 1678 the implementation MUST cancel all retransmissions of that flight. 1679 As noted above, the receipt of any record responding to a given 1680 flight MUST be taken as an implicit acknowledgement for the entire 1681 flight. 1683 8. Key Updates 1685 As with TLS 1.3, DTLS 1.3 implementations send a KeyUpdate message to 1686 indicate that they are updating their sending keys. As with other 1687 handshake messages with no built-in response, KeyUpdates MUST be 1688 acknowledged. In order to facilitate epoch reconstruction 1689 Section 4.2.2 implementations MUST NOT send with the new keys or send 1690 a new KeyUpdate until the previous KeyUpdate has been acknowledged 1691 (this avoids having too many epochs in active use). 1693 Due to loss and/or re-ordering, DTLS 1.3 implementations may receive 1694 a record with an older epoch than the current one (the requirements 1695 above preclude receiving a newer record). They SHOULD attempt to 1696 process those records with that epoch (see Section 4.2.2 for 1697 information on determining the correct epoch), but MAY opt to discard 1698 such out-of-epoch records. 1700 Although KeyUpdate MUST be acknowledged, it is possible for the ACK 1701 to be lost, in which case the sender of the KeyUpdate will retransmit 1702 it. Implementations MUST retain the ability to ACK the KeyUpdate for 1703 up to 2MSL. It is RECOMMENDED that they do so by retaining the pre- 1704 update keying material, but they MAY do so by responding to messages 1705 which appear to be out-of-epoch with a canned ACK message; in this 1706 case, implementations SHOULD rate limit how often they send such 1707 ACKs. 1709 9. Connection ID Updates 1711 If the client and server have negotiated the "connection_id" 1712 extension [DTLS-CID], either side can send a new CID which it wishes 1713 the other side to use in a NewConnectionId message. 1715 enum { 1716 cid_immediate(0), cid_spare(1), (255) 1717 } ConnectionIdUsage; 1719 opaque ConnectionId<0..2^8-1>; 1721 struct { 1722 ConnectionIds cids<0..2^16-1>; 1723 ConnectionIdUsage usage; 1724 } NewConnectionId; 1726 cid Indicates the set of CIDs which the sender wishes the peer to 1727 use. 1729 usage Indicates whether the new CIDs should be used immediately or 1730 are spare. If usage is set to "cid_immediate", then one of the 1731 new CID MUST be used immediately for all future records. If it is 1732 set to "cid_spare", then either existing or new CID MAY be used. 1734 Endpoints SHOULD use receiver-provided CIDs in the order they were 1735 provided. Endpoints MUST NOT have more than one NewConnectionId 1736 message outstanding. 1738 If the client and server have negotiated the "connection_id" 1739 extension, either side can request a new CID using the 1740 RequestConnectionId message. 1742 struct { 1743 uint8 num_cids; 1744 } RequestConnectionId; 1746 num_cids The number of CIDs desired. 1748 Endpoints SHOULD respond to RequestConnectionId by sending a 1749 NewConnectionId with usage "cid_spare" containing num_cid CIDs soon 1750 as possible. Endpoints MUST NOT send a RequestConnectionId message 1751 when an existing request is still unfulfilled; this implies that 1752 endpoints needs to request new CIDs well in advance. An endpoint MAY 1753 ignore requests, which it considers excessive (though they MUST be 1754 acknowledged as usual). 1756 Endpoints MUST NOT send either of these messages if they did not 1757 negotiate a CID. If an implementation receives these messages when 1758 CIDs were not negotiated, it MUST abort the connection with an 1759 unexpected_message alert. 1761 9.1. Connection ID Example 1763 Below is an example exchange for DTLS 1.3 using a single CID in each 1764 direction. 1766 Note: The connection_id extension is defined in [DTLS-CID], which is 1767 used in ClientHello and ServerHello messages. 1769 Client Server 1770 ------ ------ 1772 ClientHello 1773 (connection_id=5) 1774 --------> 1776 <-------- HelloRetryRequest 1777 (cookie) 1779 ClientHello --------> 1780 (connection_id=5) 1781 +cookie 1783 <-------- ServerHello 1784 (connection_id=100) 1785 EncryptedExtensions 1786 (cid=5) 1787 Certificate 1788 (cid=5) 1789 CertificateVerify 1790 (cid=5) 1791 Finished 1792 (cid=5) 1794 Certificate --------> 1795 (cid=100) 1796 CertificateVerify 1797 (cid=100) 1798 Finished 1799 (cid=100) 1800 <-------- Ack 1801 (cid=5) 1803 Application Data ========> 1804 (cid=100) 1805 <======== Application Data 1806 (cid=5) 1808 Figure 13: Example DTLS 1.3 Exchange with CIDs 1810 If no CID is negotiated, then the receiver MUST reject any records it 1811 receives that contain a CID. 1813 10. Application Data Protocol 1815 Application data messages are carried by the record layer and are 1816 fragmented and encrypted based on the current connection state. The 1817 messages are treated as transparent data to the record layer. 1819 11. Security Considerations 1821 Security issues are discussed primarily in [TLS13]. 1823 The primary additional security consideration raised by DTLS is that 1824 of denial of service. DTLS includes a cookie exchange designed to 1825 protect against denial of service. However, implementations that do 1826 not use this cookie exchange are still vulnerable to DoS. In 1827 particular, DTLS servers that do not use the cookie exchange may be 1828 used as attack amplifiers even if they themselves are not 1829 experiencing DoS. Therefore, DTLS servers SHOULD use the cookie 1830 exchange unless there is good reason to believe that amplification is 1831 not a threat in their environment. Clients MUST be prepared to do a 1832 cookie exchange with every handshake. 1834 DTLS implementations MUST NOT update their sending address in 1835 response to packets from a different address unless they first 1836 perform some reachability test; no such test is defined in this 1837 specification. Even with such a test, An on-path adversary can also 1838 black-hole traffic or create a reflection attack against third 1839 parties because a DTLS peer has no means to distinguish a genuine 1840 address update event (for example, due to a NAT rebinding) from one 1841 that is malicious. This attack is of concern when there is a large 1842 asymmetry of request/response message sizes. 1844 With the exception of order protection and non-replayability, the 1845 security guarantees for DTLS 1.3 are the same as TLS 1.3. While TLS 1846 always provides order protection and non-replayability, DTLS does not 1847 provide order protection and may not provide replay protection. 1849 Unlike TLS implementations, DTLS implementations SHOULD NOT respond 1850 to invalid records by terminating the connection. 1852 If implementations process out-of-epoch records as recommended in 1853 Section 8, then this creates a denial of service risk since an 1854 adversary could inject records with fake epoch values, forcing the 1855 recipient to compute the next-generation application_traffic_secret 1856 using the HKDF-Expand-Label construct to only find out that the 1857 message was does not pass the AEAD cipher processing. The impact of 1858 this attack is small since the HKDF-Expand-Label only performs 1859 symmetric key hashing operations. Implementations which are 1860 concerned about this form of attack can discard out-of-epoch records. 1862 The security and privacy properties of the CID for DTLS 1.3 builds on 1863 top of what is described in [DTLS-CID]. There are, however, several 1864 improvements: 1866 - The use of the Post-Handshake message allows the client and the 1867 server to update their CIDs and those values are exchanged with 1868 confidentiality protection. 1870 - With multi-homing, an adversary is able to correlate the 1871 communication interaction over the two paths, which adds further 1872 privacy concerns. In order to prevent this, implementations 1873 SHOULD attempt to use fresh CIDs whenever they change local 1874 addresses or ports (though this is not always possible to detect). 1875 The RequestConnectionId message can be used by a peer to ask for 1876 new CIDs to ensure that a pool of suitable CIDs is available. 1878 - Switching CID based on certain events, or even regularly, helps 1879 against tracking by on-path adversaries but the sequence numbers 1880 can still allow linkability. For this reason this specification 1881 defines an algorithm for encrypting sequence numbers, see 1882 Section 4.2.3. Note that sequence number encryption is used for 1883 all encrypted DTLS 1.3 records irrespectively of the use of a CID. 1885 - DTLS 1.3 encrypts handshake messages much earlier than in previous 1886 DTLS versions. Therefore, less information identifying the DTLS 1887 client, such as the client certificate, is available to an on-path 1888 adversary. 1890 12. Changes to DTLS 1.2 1892 Since TLS 1.3 introduces a large number of changes to TLS 1.2, the 1893 list of changes from DTLS 1.2 to DTLS 1.3 is equally large. For this 1894 reason this section focuses on the most important changes only. 1896 - New handshake pattern, which leads to a shorter message exchange 1898 - Only AEAD ciphers are supported. Additional data calculation has 1899 been simplified. 1901 - Removed support for weaker and older cryptographic algorithms 1903 - HelloRetryRequest of TLS 1.3 used instead of HelloVerifyRequest 1905 - More flexible ciphersuite negotiation 1907 - New session resumption mechanism 1909 - PSK authentication redefined 1910 - New key derivation hierarchy utilizing a new key derivation 1911 construct 1913 - Improved version negotiation 1915 - Optimized record layer encoding and thereby its size 1917 - Added CID functionality 1919 - Sequence numbers are encrypted. 1921 13. IANA Considerations 1923 IANA is requested to allocate a new value in the "TLS ContentType" 1924 registry for the ACK message, defined in Section 7, with content type 1925 25. The value for the "DTLS-OK" column is "Y". IANA is requested to 1926 reserve the content type range 32-63 so that content types in this 1927 range are not allocated. 1929 IANA is requested to allocate two values in the "TLS Handshake Type" 1930 registry, defined in [TLS13], for RequestConnectionId (TBD), and 1931 NewConnectionId (TBD), as defined in this document. The value for 1932 the "DTLS-OK" columns are "Y". 1934 14. References 1936 14.1. Normative References 1938 [CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 1939 Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, 1940 . 1942 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1943 DOI 10.17487/RFC0768, August 1980, 1944 . 1946 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1947 RFC 793, DOI 10.17487/RFC0793, September 1981, 1948 . 1950 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1951 DOI 10.17487/RFC1191, November 1990, 1952 . 1954 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1955 Requirement Levels", BCP 14, RFC 2119, 1956 DOI 10.17487/RFC2119, March 1997, 1957 . 1959 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1960 Control Message Protocol (ICMPv6) for the Internet 1961 Protocol Version 6 (IPv6) Specification", STD 89, 1962 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1963 . 1965 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1966 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1967 . 1969 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 1970 "Computing TCP's Retransmission Timer", RFC 6298, 1971 DOI 10.17487/RFC6298, June 2011, 1972 . 1974 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1975 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1976 May 2017, . 1978 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1979 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1980 . 1982 14.2. Informative References 1984 [DTLS-CID] 1985 Rescorla, E., Tschofenig, H., and T. Fossati, "Connection 1986 Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection- 1987 id-07 (work in progress), October 2019. 1989 [I-D.ietf-tls-dtls-connection-id] 1990 Rescorla, E., Tschofenig, H., and T. Fossati, "Connection 1991 Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection- 1992 id-07 (work in progress), October 2019. 1994 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 1995 Protocol", RFC 2522, DOI 10.17487/RFC2522, March 1999, 1996 . 1998 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1999 RFC 4303, DOI 10.17487/RFC4303, December 2005, 2000 . 2002 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2003 Congestion Control Protocol (DCCP)", RFC 4340, 2004 DOI 10.17487/RFC4340, March 2006, 2005 . 2007 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 2008 (TLS) Protocol Version 1.1", RFC 4346, 2009 DOI 10.17487/RFC4346, April 2006, 2010 . 2012 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2013 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 2014 . 2016 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 2017 RFC 4960, DOI 10.17487/RFC4960, September 2007, 2018 . 2020 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 2021 the Datagram Congestion Control Protocol (DCCP)", 2022 RFC 5238, DOI 10.17487/RFC5238, May 2008, 2023 . 2025 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2026 (TLS) Protocol Version 1.2", RFC 5246, 2027 DOI 10.17487/RFC5246, August 2008, 2028 . 2030 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2031 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2032 January 2012, . 2034 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 2035 Kivinen, "Internet Key Exchange Protocol Version 2 2036 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2037 2014, . 2039 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2040 "Recommendations for Secure Use of Transport Layer 2041 Security (TLS) and Datagram Transport Layer Security 2042 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2043 2015, . 2045 14.3. URIs 2047 [1] mailto:tls@ietf.org 2049 [2] https://www1.ietf.org/mailman/listinfo/tls 2051 [3] https://www.ietf.org/mail-archive/web/tls/current/index.html 2053 Appendix A. Protocol Data Structures and Constant Values 2055 This section provides the normative protocol types and constants 2056 definitions. 2058 A.1. Record Layer 2060 struct { 2061 ContentType type; 2062 ProtocolVersion legacy_record_version; 2063 uint16 epoch = 0 // DTLS field 2064 uint48 sequence_number; // DTLS field 2065 uint16 length; 2066 opaque fragment[DTLSPlaintext.length]; 2067 } DTLSPlaintext; 2069 struct { 2070 opaque content[DTLSPlaintext.length]; 2071 ContentType type; 2072 uint8 zeros[length_of_padding]; 2073 } DTLSInnerPlaintext; 2075 struct { 2076 opaque unified_hdr[variable]; 2077 opaque encrypted_record[length]; 2078 } DTLSCiphertext; 2080 0 1 2 3 4 5 6 7 2081 +-+-+-+-+-+-+-+-+ 2082 |0|0|1|C|S|L|E E| 2083 +-+-+-+-+-+-+-+-+ 2084 | Connection ID | Legend: 2085 | (if any, | 2086 / length as / C - Connection ID (CID) present 2087 | negotiated) | S - Sequence number length 2088 +-+-+-+-+-+-+-+-+ L - Length present 2089 | 8 or 16 bit | E - Epoch 2090 |Sequence Number| 2091 +-+-+-+-+-+-+-+-+ 2092 | 16 bit Length | 2093 | (if present) | 2094 +-+-+-+-+-+-+-+-+ 2096 A.2. Handshake Protocol 2098 enum { 2099 hello_request_RESERVED(0), 2100 client_hello(1), 2101 server_hello(2), 2102 hello_verify_request_RESERVED(3), 2103 new_session_ticket(4), 2104 end_of_early_data(5), 2105 hello_retry_request_RESERVED(6), 2106 encrypted_extensions(8), 2107 certificate(11), 2108 server_key_exchange_RESERVED(12), 2109 certificate_request(13), 2110 server_hello_done_RESERVED(14), 2111 certificate_verify(15), 2112 client_key_exchange_RESERVED(16), 2113 finished(20), 2114 key_update(24), 2115 message_hash(254), 2116 (255) 2117 } HandshakeType; 2119 struct { 2120 HandshakeType msg_type; /* handshake type */ 2121 uint24 length; /* bytes in message */ 2122 uint16 message_seq; /* DTLS-required field */ 2123 uint24 fragment_offset; /* DTLS-required field */ 2124 uint24 fragment_length; /* DTLS-required field */ 2125 select (HandshakeType) { 2126 case client_hello: ClientHello; 2127 case server_hello: ServerHello; 2128 case end_of_early_data: EndOfEarlyData; 2129 case encrypted_extensions: EncryptedExtensions; 2130 case certificate_request: CertificateRequest; 2131 case certificate: Certificate; 2132 case certificate_verify: CertificateVerify; 2133 case finished: Finished; 2134 case new_session_ticket: NewSessionTicket; 2135 case key_update: KeyUpdate; 2136 } body; 2137 } Handshake; 2139 uint16 ProtocolVersion; 2140 opaque Random[32]; 2142 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 2144 struct { 2145 ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2 2146 Random random; 2147 opaque legacy_session_id<0..32>; 2148 opaque legacy_cookie<0..2^8-1>; // DTLS 2149 CipherSuite cipher_suites<2..2^16-2>; 2150 opaque legacy_compression_methods<1..2^8-1>; 2151 Extension extensions<8..2^16-1>; 2152 } ClientHello; 2154 A.3. ACKs 2156 struct { 2157 RecordNumber record_numbers<0..2^16-1>; 2158 } ACK; 2160 A.4. Connection ID Management 2162 enum { 2163 cid_immediate(0), cid_spare(1), (255) 2164 } ConnectionIdUsage; 2166 opaque ConnectionId<0..2^8-1>; 2168 struct { 2169 ConnectionIds cids<0..2^16-1>; 2170 ConnectionIdUsage usage; 2171 } NewConnectionId; 2173 struct { 2174 uint8 num_cids; 2175 } RequestConnectionId; 2177 Appendix B. History 2179 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 2181 IETF Drafts 2183 draft-33: - Key separation between TLS and DTLS. Issue #72. 2185 draft-32: - Editorial improvements and clarifications. 2187 draft-31: - Editorial improvements in text and figures. - Added 2188 normative reference to ChaCha20 and Poly1305. 2190 draft-30: - Changed record format - Added text about end of early 2191 data - Changed format of the Connection ID Update message - Added 2192 Appendix A "Protocol Data Structures and Constant Values" 2194 draft-29: - Added support for sequence number encryption - Update to 2195 new record format - Emphasize that compatibility mode isn't used. 2197 draft-28: - Version bump to align with TLS 1.3 pre-RFC version. 2199 draft-27: - Incorporated unified header format. - Added support for 2200 CIDs. 2202 draft-04 - 26: - Submissions to align with TLS 1.3 draft versions 2204 draft-03 - Only update keys after KeyUpdate is ACKed. 2206 draft-02 - Shorten the protected record header and introduce an 2207 ultra-short version of the record header. - Reintroduce KeyUpdate, 2208 which works properly now that we have ACK. - Clarify the ACK rules. 2210 draft-01 - Restructured the ACK to contain a list of records and also 2211 be a record rather than a handshake message. 2213 draft-00 - First IETF Draft 2215 Personal Drafts draft-01 - Alignment with version -19 of the TLS 1.3 2216 specification 2218 draft-00 2220 - Initial version using TLS 1.3 as a baseline. 2222 - Use of epoch values instead of KeyUpdate message 2224 - Use of cookie extension instead of cookie field in ClientHello and 2225 HelloVerifyRequest messages 2227 - Added ACK message 2229 - Text about sequence number handling 2231 Appendix C. Working Group Information 2233 The discussion list for the IETF TLS working group is located at the 2234 e-mail address tls@ietf.org [1]. Information on the group and 2235 information on how to subscribe to the list is at 2236 https://www1.ietf.org/mailman/listinfo/tls [2] 2238 Archives of the list can be found at: https://www.ietf.org/mail- 2239 archive/web/tls/current/index.html [3] 2241 Appendix D. Contributors 2243 Many people have contributed to previous DTLS versions and they are 2244 acknowledged in prior versions of DTLS specifications or in the 2245 referenced specifications. The sequence number encryption concept is 2246 taken from the QUIC specification. We would like to thank the 2247 authors of the QUIC specification for their work. 2249 In addition, we would like to thank: 2251 * David Benjamin 2252 Google 2253 davidben@google.com 2255 * Thomas Fossati 2256 Nokia 2257 thomas.fossati@nokia.com 2259 * Tobias Gondrom 2260 Huawei 2261 tobias.gondrom@gondrom.org 2263 * Ilari Liusvaara 2264 Independent 2265 ilariliusvaara@welho.com 2267 * Martin Thomson 2268 Mozilla 2269 martin.thomson@gmail.com 2271 * Christopher A. Wood 2272 Apple Inc. 2273 cawood@apple.com 2275 * Yin Xinxing 2276 Huawei 2277 yinxinxing@huawei.com 2279 Authors' Addresses 2281 Eric Rescorla 2282 RTFM, Inc. 2284 EMail: ekr@rtfm.com 2285 Hannes Tschofenig 2286 Arm Limited 2288 EMail: hannes.tschofenig@arm.com 2290 Nagendra Modadugu 2291 Google, Inc. 2293 EMail: nagendra@cs.stanford.edu