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