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