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