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