idnits 2.17.1 draft-ietf-tls-dtls13-30.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC6347, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 05, 2018) is 1998 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 2077 -- Looks like a reference, but probably isn't: '2' on line 2161 == Missing Reference: 'ACK' is mentioned on line 1545, but not defined == Missing Reference: 'NewSessionTicket' is mentioned on line 1542, but not defined -- Looks like a reference, but probably isn't: '1' on line 2159 -- Looks like a reference, but probably isn't: '3' on line 2164 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-13) exists of draft-ietf-tls-dtls-connection-id-02 -- 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: 1 error (**), 0 flaws (~~), 5 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS E. Rescorla 3 Internet-Draft RTFM, Inc. 4 Obsoletes: 6347 (if approved) H. Tschofenig 5 Intended status: Standards Track Arm Limited 6 Expires: May 9, 2019 N. Modadugu 7 Google, Inc. 8 November 05, 2018 10 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 11 draft-ietf-tls-dtls13-30 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. Datagram semantics of the underlying transport are 23 preserved by the DTLS protocol. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 9, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 73 3. DTLS Design Rationale and Overview . . . . . . . . . . . . . 5 74 3.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 6 75 3.1.1. Reordering . . . . . . . . . . . . . . . . . . . . . 7 76 3.1.2. Message Size . . . . . . . . . . . . . . . . . . . . 7 77 3.2. Replay Detection . . . . . . . . . . . . . . . . . . . . 7 78 4. The DTLS Record Layer . . . . . . . . . . . . . . . . . . . . 7 79 4.1. Determining the Header Format . . . . . . . . . . . . . . 11 80 4.2. Sequence Number and Epoch . . . . . . . . . . . . . . . . 11 81 4.2.1. Processing Guidelines . . . . . . . . . . . . . . . . 11 82 4.2.2. Reconstructing the Sequence Number and Epoch . . . . 12 83 4.2.3. Sequence Number Encryption . . . . . . . . . . . . . 12 84 4.3. Transport Layer Mapping . . . . . . . . . . . . . . . . . 13 85 4.4. PMTU Issues . . . . . . . . . . . . . . . . . . . . . . . 14 86 4.5. Record Payload Protection . . . . . . . . . . . . . . . . 16 87 4.5.1. Anti-Replay . . . . . . . . . . . . . . . . . . . . . 16 88 4.5.2. Handling Invalid Records . . . . . . . . . . . . . . 16 89 5. The DTLS Handshake Protocol . . . . . . . . . . . . . . . . . 17 90 5.1. Denial-of-Service Countermeasures . . . . . . . . . . . . 18 91 5.2. DTLS Handshake Message Format . . . . . . . . . . . . . . 20 92 5.3. ClientHello Message . . . . . . . . . . . . . . . . . . . 22 93 5.4. Handshake Message Fragmentation and Reassembly . . . . . 23 94 5.5. End Of Early Data . . . . . . . . . . . . . . . . . . . . 23 95 5.6. DTLS Handshake Flights . . . . . . . . . . . . . . . . . 24 96 5.7. Timeout and Retransmission . . . . . . . . . . . . . . . 28 97 5.7.1. State Machine . . . . . . . . . . . . . . . . . . . . 28 98 5.7.2. Timer Values . . . . . . . . . . . . . . . . . . . . 30 99 5.8. CertificateVerify and Finished Messages . . . . . . . . . 31 100 5.9. Alert Messages . . . . . . . . . . . . . . . . . . . . . 31 101 5.10. Establishing New Associations with Existing Parameters . 31 102 6. Example of Handshake with Timeout and Retransmission . . . . 32 103 6.1. Epoch Values and Rekeying . . . . . . . . . . . . . . . . 34 104 7. ACK Message . . . . . . . . . . . . . . . . . . . . . . . . . 36 105 7.1. Sending ACKs . . . . . . . . . . . . . . . . . . . . . . 37 106 7.2. Receiving ACKs . . . . . . . . . . . . . . . . . . . . . 38 107 8. Key Updates . . . . . . . . . . . . . . . . . . . . . . . . . 38 108 9. Connection ID Updates . . . . . . . . . . . . . . . . . . . . 38 109 9.1. ID Example . . . . . . . . . . . . . . . . . . . . . . . 40 110 10. Application Data Protocol . . . . . . . . . . . . . . . . . . 41 111 11. Security Considerations . . . . . . . . . . . . . . . . . . . 42 112 12. Changes to DTLS 1.2 . . . . . . . . . . . . . . . . . . . . . 43 113 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 114 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 115 14.1. Normative References . . . . . . . . . . . . . . . . . . 44 116 14.2. Informative References . . . . . . . . . . . . . . . . . 45 117 Appendix A. Protocol Data Structures and Constant Values . . . . 47 118 A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 47 119 A.2. Handshake Protocol . . . . . . . . . . . . . . . . . . . 47 120 A.3. ACKs . . . . . . . . . . . . . . . . . . . . . . . . . . 49 121 A.4. Connection ID Management . . . . . . . . . . . . . . . . 49 122 Appendix B. History . . . . . . . . . . . . . . . . . . . . . . 49 123 Appendix C. Working Group Information . . . . . . . . . . . . . 50 124 Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 50 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 127 1. Introduction 129 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH 131 The source for this draft is maintained in GitHub. Suggested changes 132 should be submitted as pull requests at https://github.com/tlswg/ 133 dtls13-spec. Instructions are on that page as well. Editorial 134 changes can be managed in GitHub, but any substantive change should 135 be discussed on the TLS mailing list. 137 The primary goal of the TLS protocol is to provide privacy and data 138 integrity between two communicating peers. The TLS protocol is 139 composed of two layers: the TLS Record Protocol and the TLS Handshake 140 Protocol. However, TLS must run over a reliable transport channel - 141 typically TCP [RFC0793]. 143 There are applications that utilize UDP [RFC0768] as a transport and 144 to offer communication security protection for those applications the 145 Datagram Transport Layer Security (DTLS) protocol has been designed. 146 DTLS is deliberately designed to be as similar to TLS as possible, 147 both to minimize new security invention and to maximize the amount of 148 code and infrastructure reuse. 150 DTLS 1.0 [RFC4347] was originally defined as a delta from TLS 1.1 151 [RFC4346] and DTLS 1.2 [RFC6347] was defined as a series of deltas to 152 TLS 1.2 [RFC5246]. There is no DTLS 1.1; that version number was 153 skipped in order to harmonize version numbers with TLS. This 154 specification describes the most current version of the DTLS protocol 155 aligning with the efforts around TLS 1.3 [TLS13]. 157 Implementations that speak both DTLS 1.2 and DTLS 1.3 can 158 interoperate with those that speak only DTLS 1.2 (using DTLS 1.2 of 159 course), just as TLS 1.3 implementations can interoperate with TLS 160 1.2 (see Appendix D of [TLS13] for details). While backwards 161 compatibility with DTLS 1.0 is possible the use of DTLS 1.0 is not 162 recommended as explained in Section 3.1.2 of RFC 7525 [RFC7525]. 164 2. Conventions and Terminology 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 168 "OPTIONAL" in this document are to be interpreted as described in BCP 169 14 [RFC2119] [RFC8174] when, and only when, they appear in all 170 capitals, as shown here. 172 The following terms are used: 174 - client: The endpoint initiating the DTLS connection. 176 - connection: A transport-layer connection between two endpoints. 178 - endpoint: Either the client or server of the connection. 180 - handshake: An initial negotiation between client and server that 181 establishes the parameters of their transactions. 183 - peer: An endpoint. When discussing a particular endpoint, "peer" 184 refers to the endpoint that is remote to the primary subject of 185 discussion. 187 - receiver: An endpoint that is receiving records. 189 - sender: An endpoint that is transmitting records. 191 - session: An association between a client and a server resulting 192 from a handshake. 194 - server: The endpoint which did not initiate the DTLS connection. 196 The reader is assumed to be familiar with the TLS 1.3 specification 197 since this document is defined as a delta from TLS 1.3. As in TLS 198 1.3 the HelloRetryRequest has the same format as a ServerHello 199 message but for convenience we use the term HelloRetryRequest 200 throughout this document as if it were a distinct message. 202 Figures in this document illustrate various combinations of the DTLS 203 protocol exchanges and the symbols have the following meaning: 205 - '+' indicates noteworthy extensions sent in the previously noted 206 message. 208 - '*' indicates optional or situation-dependent messages/extensions 209 that are not always sent. 211 - '{}' indicates messages protected using keys derived from a 212 [sender]_handshake_traffic_secret. 214 - '[]' indicates messages protected using keys derived from 215 traffic_secret_N. 217 3. DTLS Design Rationale and Overview 219 The basic design philosophy of DTLS is to construct "TLS over 220 datagram transport". Datagram transport does not require nor provide 221 reliable or in-order delivery of data. The DTLS protocol preserves 222 this property for application data. Applications such as media 223 streaming, Internet telephony, and online gaming use datagram 224 transport for communication due to the delay-sensitive nature of 225 transported data. The behavior of such applications is unchanged 226 when the DTLS protocol is used to secure communication, since the 227 DTLS protocol does not compensate for lost or re-ordered data 228 traffic. 230 TLS cannot be used directly in datagram environments for the 231 following five reasons: 233 1. TLS does not allow independent decryption of individual records. 234 Because the integrity check indirectly depends on a sequence 235 number, if record N is not received, then the integrity check on 236 record N+1 will be based on the wrong sequence number and thus 237 will fail. DTLS solves this problem by adding explicit sequence 238 numbers. 240 2. The TLS handshake is a lock-step cryptographic handshake. 241 Messages must be transmitted and received in a defined order; any 242 other order is an error. This is incompatible with reordering 243 and message loss. 245 3. Not all TLS 1.3 handshake messages (such as the NewSessionTicket 246 message) are acknowledged. Hence, a new acknowledgment message 247 has to be added to detect message loss. 249 4. Handshake messages are potentially larger than any given 250 datagram, thus creating the problem of IP fragmentation. 252 5. Datagram transport protocols, like UDP, are susceptible to 253 abusive behavior effecting denial of service attacks against 254 nonparticipants, and require a return-routability check with the 255 help of cookies to be integrated into the handshake. A detailed 256 discussion of countermeasures can be found in Section 5.1. 258 3.1. Packet Loss 260 DTLS uses a simple retransmission timer to handle packet loss. 261 Figure 1 demonstrates the basic concept, using the first phase of the 262 DTLS handshake: 264 Client Server 265 ------ ------ 266 ClientHello ------> 268 X<-- HelloRetryRequest 269 (lost) 271 [Timer Expires] 273 ClientHello ------> 274 (retransmit) 276 Figure 1: DTLS retransmission example 278 Once the client has transmitted the ClientHello message, it expects 279 to see a HelloRetryRequest or a ServerHello from the server. 280 However, if the server's message is lost, the client knows that 281 either the ClientHello or the response from the server has been lost 282 and retransmits. When the server receives the retransmission, it 283 knows to retransmit. 285 The server also maintains a retransmission timer and retransmits when 286 that timer expires. 288 Note that timeout and retransmission do not apply to the 289 HelloRetryRequest since this would require creating state on the 290 server. The HelloRetryRequest is designed to be small enough that it 291 will not itself be fragmented, thus avoiding concerns about 292 interleaving multiple HelloRetryRequests. 294 3.1.1. Reordering 296 In DTLS, each handshake message is assigned a specific sequence 297 number within that handshake. When a peer receives a handshake 298 message, it can quickly determine whether that message is the next 299 message it expects. If it is, then it processes it. If not, it 300 queues it for future handling once all previous messages have been 301 received. 303 3.1.2. Message Size 305 TLS and DTLS handshake messages can be quite large (in theory up to 306 2^24-1 bytes, in practice many kilobytes). By contrast, UDP 307 datagrams are often limited to less than 1500 bytes if IP 308 fragmentation is not desired. In order to compensate for this 309 limitation, each DTLS handshake message may be fragmented over 310 several DTLS records, each of which is intended to fit in a single IP 311 datagram. Each DTLS handshake message contains both a fragment 312 offset and a fragment length. Thus, a recipient in possession of all 313 bytes of a handshake message can reassemble the original unfragmented 314 message. 316 3.2. Replay Detection 318 DTLS optionally supports record replay detection. The technique used 319 is the same as in IPsec AH/ESP, by maintaining a bitmap window of 320 received records. Records that are too old to fit in the window and 321 records that have previously been received are silently discarded. 322 The replay detection feature is optional, since packet duplication is 323 not always malicious, but can also occur due to routing errors. 324 Applications may conceivably detect duplicate packets and accordingly 325 modify their data transmission strategy. 327 4. The DTLS Record Layer 329 The DTLS record layer is different from the TLS 1.3 record layer. 331 1. The DTLSCiphertext structure omits the superfluous version number 332 and type fields. 334 2. DTLS adds an explicit epoch and sequence number to the TLS record 335 header. This sequence number allows the recipient to correctly 336 verify the DTLS MAC. However, the number of bits used for the 337 epoch and sequence number fields in the DTLSCiphertext structure 338 have been reduced. 340 3. The DTLSCiphertext structure has a variable length header. 342 Note that the DTLS 1.3 record layer is different from the DTLS 1.2 343 record layer. 345 DTLSPlaintext records are used to send unprotected records and 346 DTLSCiphertext records are used to send protected records. 348 The DTLS record formats are shown below. Unless explicitly stated 349 the meaning of the fields is unchanged from previous TLS / DTLS 350 versions. 352 struct { 353 ContentType type; 354 ProtocolVersion legacy_record_version; 355 uint16 epoch = 0 // DTLS field 356 uint48 sequence_number; // DTLS field 357 uint16 length; 358 opaque fragment[DTLSPlaintext.length]; 359 } DTLSPlaintext; 361 struct { 362 opaque content[DTLSPlaintext.length]; 363 ContentType type; 364 uint8 zeros[length_of_padding]; 365 } DTLSInnerPlaintext; 367 struct { 368 opaque unified_hdr[variable]; 369 opaque encrypted_record[length]; 370 } DTLSCiphertext; 372 Figure 2: DTLS 1.3 Record Format 374 unified_hdr: The unified_hdr is a field of variable length, as shown 375 in Figure 3. 377 encrypted_record: Identical to the encrypted_record field in a TLS 378 1.3 record. 380 The DTLSCiphertext header is tightly bit-packed, as shown below: 382 0 1 2 3 4 5 6 7 383 +-+-+-+-+-+-+-+-+ 384 |0|0|1|C|S|L|E E| 385 +-+-+-+-+-+-+-+-+ 386 | Connection ID | Legend: 387 | (if any, | 388 / length as / C - CID present 389 | negotiated) | S - Sequence number length 390 +-+-+-+-+-+-+-+-+ L - Length present 391 | 8 or 16 bit | E - Epoch 392 |Sequence Number| 393 +-+-+-+-+-+-+-+-+ 394 | 16 bit Length | 395 | (if present) | 396 +-+-+-+-+-+-+-+-+ 398 Figure 3: DTLS 1.3 CipherText Header 400 C: The C bit is set if the connection ID is present. 402 S: The size of the sequence number. 0 means an 8-bit sequence 403 number, 1 means 16-bit. 405 L: The L bit is set if the length is present. 407 E: The low order two bits of the epoch. 409 connection ID: Variable length connection ID. The connection ID 410 concept is described in [DTLS-CID]. An example can be found in 411 Section 9.1. 413 sequence number: The low order 8 or 16 bits of the record sequence 414 number. This value is 16 bits if the S bit is set to 1, and 8 415 bits if the S bit is 0. 417 length: Identical to the length field in a TLS 1.3 record. 419 As with previous versions of DTLS, multiple DTLSPlaintext and 420 DTLSCiphertext records can be included in the same underlying 421 transport datagram. 423 Figure 4 illustrates different record layer header types. 425 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 426 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 427 | Content Type | |0|0|1|C|1|E|E|1| |0|0|1|0|0|E|E|0| 428 +-+-+-+-+-+-+-+-+ +-+-+-+-++-+-+-+ +-+-+-+-+-+-+-+-+ 429 | 16 bit | | 16 bit | |8-bit Seq. No. | 430 | Version | |Sequence Number| +-+-+-+-+-+-+-+-+ 431 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | | 432 | 16 bit | | | | Encrypted | 433 | Epoch | / Connection ID / / Record / 434 +-+-+-+-+-+-+-+-+ | | | | 435 | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 436 | | | 16 bit | 437 | 48 bit | | Length | DTLSCiphertext 438 |Sequence Number| +-+-+-+-+-+-+-+-+ Structure 439 | | | | (minimal) 440 | | | Encrypted | 441 +-+-+-+-+-+-+-+-+ / Record / 442 | 16 bit | | | 443 | Length | +-+-+-+-+-+-+-+-+ 444 +-+-+-+-+-+-+-+-+ 445 | | DTLSCiphertext 446 | | Structure 447 / Fragment / (full) 448 | | 449 +-+-+-+-+-+-+-+-+ 451 DTLSPlaintext 452 Structure 454 Figure 4: Header Examples 456 The length field may be omitted and therefore the record consumes the 457 entire rest of the datagram in the lower level transport. In this 458 case it is not possible to have multiple DTLSCiphertext format 459 records without length fields in the same datagram. 461 Omitting the length field MUST only be used for data which is 462 protected with one of the application_traffic_secret values, and not 463 for messages protected with either [sender]_handshake_traffic_sercret 464 or [sender]_early_traffic_secret values. When using an 465 [sender]_application_traffic_secret for message protection, 466 Implementations MAY include the length field at their discretion. 468 The entire header value shown above is used as it appears on the wire 469 as the additional data value for the AEAD function. 471 4.1. Determining the Header Format 473 Implementations can distinguish the two header formats by examining 474 the first byte: 476 - If the first byte is alert(21), handshake(22), or ack(proposed, 477 25), the record MUST be interpreted as a DTLSPlaintext record. 479 - If the first byte is any other other value, then receivers MUST 480 check to see if the leading bits of the first byte are 001. If 481 so, the implementation MUST process the record as DTLSCiphertext; 482 the true content type will be inside the protected portion. 484 - Otherwise, the record MUST be rejected as if it had failed 485 deprotection, as described in Section 4.5.2. 487 4.2. Sequence Number and Epoch 489 4.2.1. Processing Guidelines 491 DTLS uses an explicit sequence number, rather than an implicit one, 492 carried in the sequence_number field of the record. Sequence numbers 493 are maintained separately for each epoch, with each sequence_number 494 initially being 0 for each epoch. 496 The epoch number is initially zero and is incremented each time 497 keying material changes and a sender aims to rekey. More details are 498 provided in Section 6.1. 500 Because DTLS records may be reordered, a record from epoch 1 may be 501 received after epoch 2 has begun. In general, implementations SHOULD 502 discard packets from earlier epochs, but if packet loss causes 503 noticeable problems implementations MAY choose to retain keying 504 material from previous epochs for up to the default MSL specified for 505 TCP [RFC0793] to allow for packet reordering. (Note that the 506 intention here is that implementers use the current guidance from the 507 IETF for MSL, as specified in [RFC0793] or successors not that they 508 attempt to interrogate the MSL that the system TCP stack is using.) 509 Until the handshake has completed, implementations MUST accept 510 packets from the old epoch. 512 Conversely, it is possible for records that are protected with the 513 new epoch to be received prior to the completion of a handshake. For 514 instance, the server may send its Finished message and then start 515 transmitting data. Implementations MAY either buffer or discard such 516 packets, though when DTLS is used over reliable transports (e.g., 517 SCTP [RFC4960]), they SHOULD be buffered and processed once the 518 handshake completes. Note that TLS's restrictions on when packets 519 may be sent still apply, and the receiver treats the packets as if 520 they were sent in the right order. In particular, it is still 521 impermissible to send data prior to completion of the first 522 handshake. 524 Note that some care needs to be taken during the handshake to ensure 525 that retransmitted messages use the right epoch and keying material. 527 Implementations MUST either abandon an association or re-key prior to 528 allowing the sequence number to wrap. 530 Implementations MUST NOT allow the epoch to wrap, but instead MUST 531 establish a new association, terminating the old association. 533 4.2.2. Reconstructing the Sequence Number and Epoch 535 When receiving protected DTLS records message, the recipient does not 536 have a full epoch or sequence number value and so there is some 537 opportunity for ambiguity. Because the full epoch and sequence 538 number are used to compute the per-record nonce, failure to 539 reconstruct these values leads to failure to deprotect the record, 540 and so implementations MAY use a mechanism of their choice to 541 determine the full values. This section provides an algorithm which 542 is comparatively simple and which implementations are RECOMMENDED to 543 follow. 545 If the epoch bits match those of the current epoch, then 546 implementations SHOULD reconstruct the sequence number by computing 547 the full sequence number which is numerically closest to one plus the 548 sequence number of the highest successfully deprotected record. 550 During the handshake phase, the epoch bits unambiguously indicate the 551 correct key to use. After the handshake is complete, if the epoch 552 bits do not match those from the current epoch implementations SHOULD 553 use the most recent past epoch which has matching bits, and then 554 reconstruct the sequence number as described above. 556 4.2.3. Sequence Number Encryption 558 In DTLS 1.3, when records are encrypted, record sequence numbers are 559 also encrypted. The basic pattern is that the underlying encryption 560 algorithm used with the AEAD algorithm is used to generate a mask 561 which is then XORed with the sequence number. 563 When the AEAD is based on AES, then the Mask is generated by 564 computing AES-ECB on the first 16 bytes of the ciphertext: 566 Mask = AES-ECB(sn_key, Ciphertext[0..15]) 568 When the AEAD is based on ChaCha20, then the mask is generated by 569 treating the first 12 bytes of the ciphertext as the Nonce and the 570 next 4 bytes as the counter: 572 Mask = ChaCha20(sn_key, Ciphertext[0..12], Ciphertext[13..15]) 574 The sn_key is computed as follows: 576 [sender]_sn_key = HKDF-Expand-Label(Secret, "sn" , "", key_length) 578 [sender] denotes the sending side. The Secret value to be used is 579 described in Section 7.3 of [TLS13]. 581 The encrypted sequence number is computed by XORing the leading bytes 582 of the Mask with the sequence number. Decryption is accomplished by 583 the same process. 585 In some (rare) cases the ciphertext may be less than 16 bytes. This 586 cannot happen with most of the DTLS AEAD algorithms because the 587 authentication tag itself is 16 bytes, however some algorithms such 588 as TLS_AES_128_CCM_8_SHA256 have a shorter authentication tag, and in 589 combination with a short plaintext, the result might be less than 16 590 bytes. In this case, implementations MUST pad the plaintext out 591 (using the conventional record padding mechanism) in order to make a 592 suitable-length ciphertext. 594 Note that sequence number encryption is only applied to the 595 DTLSCiphertext structure and not to the DTLSPlaintext structure, 596 which also contains a sequence number. 598 4.3. Transport Layer Mapping 600 DTLS messages MAY be fragmentmented into multiple DTLS records. Each 601 DTLS record MUST fit within a single datagram. In order to avoid IP 602 fragmentation, clients of the DTLS record layer SHOULD attempt to 603 size records so that they fit within any PMTU estimates obtained from 604 the record layer. 606 Multiple DTLS records MAY be placed in a single datagram. They are 607 simply encoded consecutively. The DTLS record framing is sufficient 608 to determine the boundaries. Note, however, that the first byte of 609 the datagram payload MUST be the beginning of a record. Records MUST 610 NOT span datagrams. 612 DTLS records, as defined in this document, do not contain any 613 association identifiers and applications must arrange to multiplex 614 between associations. With UDP, the host/port number is used to look 615 up the appropriate security association for incoming records. 617 However, the Connection ID extension defined in [DTLS-CID] adds an 618 association identifier to DTLS records. 620 Some transports, such as DCCP [RFC4340], provide their own sequence 621 numbers. When carried over those transports, both the DTLS and the 622 transport sequence numbers will be present. Although this introduces 623 a small amount of inefficiency, the transport layer and DTLS sequence 624 numbers serve different purposes; therefore, for conceptual 625 simplicity, it is superior to use both sequence numbers. 627 Some transports provide congestion control for traffic carried over 628 them. If the congestion window is sufficiently narrow, DTLS 629 handshake retransmissions may be held rather than transmitted 630 immediately, potentially leading to timeouts and spurious 631 retransmission. When DTLS is used over such transports, care should 632 be taken not to overrun the likely congestion window. [RFC5238] 633 defines a mapping of DTLS to DCCP that takes these issues into 634 account. 636 4.4. PMTU Issues 638 In general, DTLS's philosophy is to leave PMTU discovery to the 639 application. However, DTLS cannot completely ignore PMTU for three 640 reasons: 642 - The DTLS record framing expands the datagram size, thus lowering 643 the effective PMTU from the application's perspective. 645 - In some implementations, the application may not directly talk to 646 the network, in which case the DTLS stack may absorb ICMP 647 [RFC1191] "Datagram Too Big" indications or ICMPv6 [RFC4443] 648 "Packet Too Big" indications. 650 - The DTLS handshake messages can exceed the PMTU. 652 In order to deal with the first two issues, the DTLS record layer 653 SHOULD behave as described below. 655 If PMTU estimates are available from the underlying transport 656 protocol, they should be made available to upper layer protocols. In 657 particular: 659 - For DTLS over UDP, the upper layer protocol SHOULD be allowed to 660 obtain the PMTU estimate maintained in the IP layer. 662 - For DTLS over DCCP, the upper layer protocol SHOULD be allowed to 663 obtain the current estimate of the PMTU. 665 - For DTLS over TCP or SCTP, which automatically fragment and 666 reassemble datagrams, there is no PMTU limitation. However, the 667 upper layer protocol MUST NOT write any record that exceeds the 668 maximum record size of 2^14 bytes. 670 The DTLS record layer SHOULD allow the upper layer protocol to 671 discover the amount of record expansion expected by the DTLS 672 processing. 674 If there is a transport protocol indication (either via ICMP or via a 675 refusal to send the datagram as in Section 14 of [RFC4340]), then the 676 DTLS record layer MUST inform the upper layer protocol of the error. 678 The DTLS record layer SHOULD NOT interfere with upper layer protocols 679 performing PMTU discovery, whether via [RFC1191] or [RFC4821] 680 mechanisms. In particular: 682 - Where allowed by the underlying transport protocol, the upper 683 layer protocol SHOULD be allowed to set the state of the DF bit 684 (in IPv4) or prohibit local fragmentation (in IPv6). 686 - If the underlying transport protocol allows the application to 687 request PMTU probing (e.g., DCCP), the DTLS record layer SHOULD 688 honor this request. 690 The final issue is the DTLS handshake protocol. From the perspective 691 of the DTLS record layer, this is merely another upper layer 692 protocol. However, DTLS handshakes occur infrequently and involve 693 only a few round trips; therefore, the handshake protocol PMTU 694 handling places a premium on rapid completion over accurate PMTU 695 discovery. In order to allow connections under these circumstances, 696 DTLS implementations SHOULD follow the following rules: 698 - If the DTLS record layer informs the DTLS handshake layer that a 699 message is too big, it SHOULD immediately attempt to fragment it, 700 using any existing information about the PMTU. 702 - If repeated retransmissions do not result in a response, and the 703 PMTU is unknown, subsequent retransmissions SHOULD back off to a 704 smaller record size, fragmenting the handshake message as 705 appropriate. This standard does not specify an exact number of 706 retransmits to attempt before backing off, but 2-3 seems 707 appropriate. 709 4.5. Record Payload Protection 711 Like TLS, DTLS transmits data as a series of protected records. The 712 rest of this section describes the details of that format. 714 4.5.1. Anti-Replay 716 Each DTLS record contains a sequence number to provide replay 717 protection. Sequence number verification SHOULD be performed using 718 the following sliding window procedure, borrowed from Section 3.4.3 719 of [RFC4303]. 721 The received packet counter for a session MUST be initialized to zero 722 when that session is established. For each received record, the 723 receiver MUST verify that the record contains a sequence number that 724 does not duplicate the sequence number of any other record received 725 during the lifetime of the session. This check SHOULD happen after 726 deprotecting the packet; otherwise the packet discard might itself 727 serve as a timing channel for the sequence number. 729 Duplicates are rejected through the use of a sliding receive window. 730 (How the window is implemented is a local matter, but the following 731 text describes the functionality that the implementation must 732 exhibit.) A minimum window size of 32 MUST be supported, but a 733 window size of 64 is preferred and SHOULD be employed as the default. 734 Another window size (larger than the minimum) MAY be chosen by the 735 receiver. (The receiver does not notify the sender of the window 736 size.) 738 The "right" edge of the window represents the highest validated 739 sequence number value received on the session. Records that contain 740 sequence numbers lower than the "left" edge of the window are 741 rejected. Packets falling within the window are checked against a 742 list of received packets within the window. An efficient means for 743 performing this check, based on the use of a bit mask, is described 744 in Section 3.4.3 of [RFC4303]. If the received record falls within 745 the window and is new, or if the packet is to the right of the 746 window, then the packet is new. 748 The window MUST NOT be updated until the packet has been deprotected 749 successfully. 751 4.5.2. Handling Invalid Records 753 Unlike TLS, DTLS is resilient in the face of invalid records (e.g., 754 invalid formatting, length, MAC, etc.). In general, invalid records 755 SHOULD be silently discarded, thus preserving the association; 756 however, an error MAY be logged for diagnostic purposes. 758 Implementations which choose to generate an alert instead, MUST 759 generate error alerts to avoid attacks where the attacker repeatedly 760 probes the implementation to see how it responds to various types of 761 error. Note that if DTLS is run over UDP, then any implementation 762 which does this will be extremely susceptible to denial-of-service 763 (DoS) attacks because UDP forgery is so easy. Thus, this practice is 764 NOT RECOMMENDED for such transports, both to increase the reliability 765 of DTLS service and to avoid the risk of spoofing attacks sending 766 traffic to unrelated third parties. 768 If DTLS is being carried over a transport that is resistant to 769 forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts 770 because an attacker will have difficulty forging a datagram that will 771 not be rejected by the transport layer. 773 5. The DTLS Handshake Protocol 775 DTLS 1.3 re-uses the TLS 1.3 handshake messages and flows, with the 776 following changes: 778 1. To handle message loss, reordering, and fragmentation 779 modifications to the handshake header are necessary. 781 2. Retransmission timers are introduced to handle message loss. 783 3. A new ACK content type has been added for reliable message 784 delivery of handshake messages. 786 Note that TLS 1.3 already supports a cookie extension, which is used 787 to prevent denial-of-service attacks. This DoS prevention mechanism 788 is described in more detail below since UDP-based protocols are more 789 vulnerable to amplification attacks than a connection-oriented 790 transport like TCP that performs return-routability checks as part of 791 the connection establishment. 793 DTLS implementations do not use the TLS 1.3 "compatibility mode" 794 described in [TLS13], Section D.4. DTLS servers MUST NOT echo the 795 "session_id" value from the client and endpoints MUST NOT send 796 ChangeCipherSpec messages. Note however that implementations MUST 797 ignore ChangeCipherSpec messages received in unprotected records. 799 With these exceptions, the DTLS message formats, flows, and logic are 800 the same as those of TLS 1.3. 802 5.1. Denial-of-Service Countermeasures 804 Datagram security protocols are extremely susceptible to a variety of 805 DoS attacks. Two attacks are of particular concern: 807 1. An attacker can consume excessive resources on the server by 808 transmitting a series of handshake initiation requests, causing 809 the server to allocate state and potentially to perform expensive 810 cryptographic operations. 812 2. An attacker can use the server as an amplifier by sending 813 connection initiation messages with a forged source of the 814 victim. The server then sends its response to the victim 815 machine, thus flooding it. Depending on the selected ciphersuite 816 this response message can be quite large, as it is the case for a 817 Certificate message. 819 In order to counter both of these attacks, DTLS borrows the stateless 820 cookie technique used by Photuris [RFC2522] and IKE [RFC7296]. When 821 the client sends its ClientHello message to the server, the server 822 MAY respond with a HelloRetryRequest message. The HelloRetryRequest 823 message, as well as the cookie extension, is defined in TLS 1.3. The 824 HelloRetryRequest message contains a stateless cookie generated using 825 the technique of [RFC2522]. The client MUST retransmit the 826 ClientHello with the cookie added as an extension. The server then 827 verifies the cookie and proceeds with the handshake only if it is 828 valid. This mechanism forces the attacker/client to be able to 829 receive the cookie, which makes DoS attacks with spoofed IP addresses 830 difficult. This mechanism does not provide any defense against DoS 831 attacks mounted from valid IP addresses. 833 The DTLS 1.3 specification changes the way how cookies are exchanged 834 compared to DTLS 1.2. DTLS 1.3 re-uses the HelloRetryRequest message 835 and conveys the cookie to the client via an extension. The client 836 receiving the cookie uses the same extension to place the cookie 837 subsequently into a ClientHello message. DTLS 1.2 on the other hand 838 used a separate message, namely the HelloVerifyRequest, to pass a 839 cookie to the client and did not utilize the extension mechanism. 840 For backwards compatibility reason the cookie field in the 841 ClientHello is present in DTLS 1.3 but is ignored by a DTLS 1.3 842 compliant server implementation. 844 The exchange is shown in Figure 5. Note that the figure focuses on 845 the cookie exchange; all other extensions are omitted. 847 Client Server 848 ------ ------ 849 ClientHello ------> 851 <----- HelloRetryRequest 852 + cookie 854 ClientHello ------> 855 + cookie 857 [Rest of handshake] 859 Figure 5: DTLS exchange with HelloRetryRequest containing the 860 "cookie" extension 862 The cookie extension is defined in Section 4.2.2 of [TLS13]. When 863 sending the initial ClientHello, the client does not have a cookie 864 yet. In this case, the cookie extension is omitted and the 865 legacy_cookie field in the ClientHello message SHOULD be set to a 866 zero length vector (i.e., a single zero byte length field) and MUST 867 be ignored by a server negotiating DTLS 1.3. 869 When responding to a HelloRetryRequest, the client MUST create a new 870 ClientHello message following the description in Section 4.1.2 of 871 [TLS13]. 873 If the HelloRetryRequest message is used, the initial ClientHello and 874 the HelloRetryRequest are included in the calculation of the 875 transcript hash. The computation of the message hash for the 876 HelloRetryRequest is done according to the description in 877 Section 4.4.1 of [TLS13]. 879 The handshake transcript is not reset with the second ClientHello and 880 a stateless server-cookie implementation requires the transcript of 881 the HelloRetryRequest to be stored in the cookie or the internal 882 state of the hash algorithm, since only the hash of the transcript is 883 required for the handshake to complete. 885 When the second ClientHello is received, the server can verify that 886 the cookie is valid and that the client can receive packets at the 887 given IP address. If the client's apparent IP address is embedded in 888 the cookie, this prevents an attacker from generating an acceptable 889 ClientHello apparently from another user. 891 One potential attack on this scheme is for the attacker to collect a 892 number of cookies from different addresses where it controls 893 endpoints and then reuse them to attack the server. The server can 894 defend against this attack by changing the secret value frequently, 895 thus invalidating those cookies. If the server wishes to allow 896 legitimate clients to handshake through the transition (e.g., a 897 client received a cookie with Secret 1 and then sent the second 898 ClientHello after the server has changed to Secret 2), the server can 899 have a limited window during which it accepts both secrets. 900 [RFC7296] suggests adding a key identifier to cookies to detect this 901 case. An alternative approach is simply to try verifying with both 902 secrets. It is RECOMMENDED that servers implement a key rotation 903 scheme that allows the server to manage keys with overlapping 904 lifetime. 906 Alternatively, the server can store timestamps in the cookie and 907 reject cookies that were generated outside a certain interval of 908 time. 910 DTLS servers SHOULD perform a cookie exchange whenever a new 911 handshake is being performed. If the server is being operated in an 912 environment where amplification is not a problem, the server MAY be 913 configured not to perform a cookie exchange. The default SHOULD be 914 that the exchange is performed, however. In addition, the server MAY 915 choose not to do a cookie exchange when a session is resumed. 916 Clients MUST be prepared to do a cookie exchange with every 917 handshake. 919 If a server receives a ClientHello with an invalid cookie, it MUST 920 NOT respond with a HelloRetryRequest. Restarting the handshake from 921 scratch, without a cookie, allows the client to recover from a 922 situation where it obtained a cookie that cannot be verified by the 923 server. As described in Section 4.1.4 of [TLS13], clients SHOULD 924 also abort the handshake with an "unexpected_message" alert in 925 response to any second HelloRetryRequest which was sent in the same 926 connection (i.e., where the ClientHello was itself in response to a 927 HelloRetryRequest). 929 5.2. DTLS Handshake Message Format 931 In order to support message loss, reordering, and message 932 fragmentation, DTLS modifies the TLS 1.3 handshake header: 934 enum { 935 client_hello(1), 936 server_hello(2), 937 new_session_ticket(4), 938 end_of_early_data(5), 939 encrypted_extensions(8), 940 certificate(11), 941 certificate_request(13), 942 certificate_verify(15), 943 finished(20), 944 key_update(24), 945 message_hash(254), 946 (255) 947 } HandshakeType; 949 struct { 950 HandshakeType msg_type; /* handshake type */ 951 uint24 length; /* bytes in message */ 952 uint16 message_seq; /* DTLS-required field */ 953 uint24 fragment_offset; /* DTLS-required field */ 954 uint24 fragment_length; /* DTLS-required field */ 955 select (HandshakeType) { 956 case client_hello: ClientHello; 957 case server_hello: ServerHello; 958 case end_of_early_data: EndOfEarlyData; 959 case encrypted_extensions: EncryptedExtensions; 960 case certificate_request: CertificateRequest; 961 case certificate: Certificate; 962 case certificate_verify: CertificateVerify; 963 case finished: Finished; 964 case new_session_ticket: NewSessionTicket; 965 case key_update: KeyUpdate; 966 } body; 967 } Handshake; 969 The first message each side transmits in each association always has 970 message_seq = 0. Whenever a new message is generated, the 971 message_seq value is incremented by one. When a message is 972 retransmitted, the old message_seq value is re-used, i.e., not 973 incremented. From the perspective of the DTLS record layer, the 974 retransmission is a new record. This record will have a new 975 DTLSPlaintext.sequence_number value. 977 DTLS implementations maintain (at least notionally) a 978 next_receive_seq counter. This counter is initially set to zero. 979 When a handshake message is received, if its message_seq value 980 matches next_receive_seq, next_receive_seq is incremented and the 981 message is processed. If the sequence number is less than 982 next_receive_seq, the message MUST be discarded. If the sequence 983 number is greater than next_receive_seq, the implementation SHOULD 984 queue the message but MAY discard it. (This is a simple space/ 985 bandwidth tradeoff). 987 In addition to the handshake messages that are deprecated by the TLS 988 1.3 specification DTLS 1.3 furthermore deprecates the 989 HelloVerifyRequest message originally defined in DTLS 1.0. DTLS 990 1.3-compliant implements MUST NOT use the HelloVerifyRequest to 991 execute a return-routability check. A dual-stack DTLS 1.2/DTLS 1.3 992 client MUST, however, be prepared to interact with a DTLS 1.2 server. 994 5.3. ClientHello Message 996 The format of the ClientHello used by a DTLS 1.3 client differs from 997 the TLS 1.3 ClientHello format as shown below. 999 uint16 ProtocolVersion; 1000 opaque Random[32]; 1002 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 1004 struct { 1005 ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2 1006 Random random; 1007 opaque legacy_session_id<0..32>; 1008 opaque legacy_cookie<0..2^8-1>; // DTLS 1009 CipherSuite cipher_suites<2..2^16-2>; 1010 opaque legacy_compression_methods<1..2^8-1>; 1011 Extension extensions<8..2^16-1>; 1012 } ClientHello; 1014 legacy_version: In previous versions of DTLS, this field was used 1015 for version negotiation and represented the highest version number 1016 supported by the client. Experience has shown that many servers 1017 do not properly implement version negotiation, leading to "version 1018 intolerance" in which the server rejects an otherwise acceptable 1019 ClientHello with a version number higher than it supports. In 1020 DTLS 1.3, the client indicates its version preferences in the 1021 "supported_versions" extension (see Section 4.2.1 of [TLS13]) and 1022 the legacy_version field MUST be set to {254, 253}, which was the 1023 version number for DTLS 1.2. 1025 random: Same as for TLS 1.3. 1027 legacy_session_id: Same as for TLS 1.3. 1029 legacy_cookie: A DTLS 1.3-only client MUST set the legacy_cookie 1030 field to zero length. 1032 cipher_suites: Same as for TLS 1.3. 1034 legacy_compression_methods: Same as for TLS 1.3. 1036 extensions: Same as for TLS 1.3. 1038 5.4. Handshake Message Fragmentation and Reassembly 1040 Each DTLS message MUST fit within a single transport layer datagram. 1041 However, handshake messages are potentially bigger than the maximum 1042 record size. Therefore, DTLS provides a mechanism for fragmenting a 1043 handshake message over a number of records, each of which can be 1044 transmitted separately, thus avoiding IP fragmentation. 1046 When transmitting the handshake message, the sender divides the 1047 message into a series of N contiguous data ranges. These ranges MUST 1048 NOT be larger than the maximum handshake fragment size and MUST 1049 jointly contain the entire handshake message. The ranges MUST NOT 1050 overlap. The sender then creates N handshake messages, all with the 1051 same message_seq value as the original handshake message. Each new 1052 message is labeled with the fragment_offset (the number of bytes 1053 contained in previous fragments) and the fragment_length (the length 1054 of this fragment). The length field in all messages is the same as 1055 the length field of the original message. An unfragmented message is 1056 a degenerate case with fragment_offset=0 and fragment_length=length. 1058 When a DTLS implementation receives a handshake message fragment, it 1059 MUST buffer it until it has the entire handshake message. DTLS 1060 implementations MUST be able to handle overlapping fragment ranges. 1061 This allows senders to retransmit handshake messages with smaller 1062 fragment sizes if the PMTU estimate changes. 1064 Note that as with TLS, multiple handshake messages may be placed in 1065 the same DTLS record, provided that there is room and that they are 1066 part of the same flight. Thus, there are two acceptable ways to pack 1067 two DTLS messages into the same datagram: in the same record or in 1068 separate records. 1070 5.5. End Of Early Data 1072 The DTLS 1.3 handshake has one important difference from the TLS 1.3 1073 handshake: the EndOfEarlyData message is omitted both from the wire 1074 and the handshake transcript: because DTLS records have epochs, 1075 EndOfEarlyData is not necessary to determine when the early data is 1076 complete, and because DTLS is lossy, attackers can trivially mount 1077 the deletion attacks that EndOfEarlyData prevents in TLS. Servers 1078 SHOULD aggressively age out the epoch 1 keys upon receiving the first 1079 epoch 1 record and SHOULD NOT accept epoch 1 data after the first 1080 epoch 3 record is received. 1082 5.6. DTLS Handshake Flights 1084 DTLS messages are grouped into a series of message flights, according 1085 to the diagrams below. 1087 Client Server 1089 ClientHello +----------+ 1090 + key_share* | Flight 1 | 1091 + pre_shared_key* --------> +----------+ 1093 +----------+ 1094 <-------- HelloRetryRequest | Flight 2 | 1095 + cookie +----------+ 1097 ClientHello +----------+ 1098 + key_share* | Flight 3 | 1099 + pre_shared_key* --------> +----------+ 1100 + cookie 1102 ServerHello 1103 + key_share* 1104 + pre_shared_key* +----------+ 1105 {EncryptedExtensions} | Flight 4 | 1106 {CertificateRequest*} +----------+ 1107 {Certificate*} 1108 {CertificateVerify*} 1109 <-------- {Finished} 1110 [Application Data*] 1112 {Certificate*} +----------+ 1113 {CertificateVerify*} | Flight 5 | 1114 {Finished} --------> +----------+ 1115 [Application Data] 1117 +----------+ 1118 <-------- [ACK] | Flight 6 | 1119 [Application Data*] +----------+ 1121 [Application Data] <-------> [Application Data] 1123 Figure 6: Message flights for a full DTLS Handshake (with cookie 1124 exchange) 1126 ClientHello +----------+ 1127 + pre_shared_key | Flight 1 | 1128 + key_share* --------> +----------+ 1130 ServerHello 1131 + pre_shared_key +----------+ 1132 + key_share* | Flight 2 | 1133 {EncryptedExtensions} +----------+ 1134 <-------- {Finished} 1135 [Application Data*] 1136 +----------+ 1137 {Finished} --------> | Flight 3 | 1138 [Application Data*] +----------+ 1140 +----------+ 1141 <-------- [ACK] | Flight 4 | 1142 [Application Data*] +----------+ 1144 [Application Data] <-------> [Application Data] 1146 Figure 7: Message flights for resumption and PSK handshake (without 1147 cookie exchange) 1149 Client Server 1151 ClientHello 1152 + early_data 1153 + psk_key_exchange_modes +----------+ 1154 + key_share* | Flight 1 | 1155 + pre_shared_key +----------+ 1156 (Application Data*) --------> 1158 ServerHello 1159 + pre_shared_key 1160 + key_share* +----------+ 1161 {EncryptedExtensions} | Flight 2 | 1162 {Finished} +----------+ 1163 <-------- [Application Data*] 1165 +----------+ 1166 (EndOfEarlyData) | Flight 3 | 1167 {Finished} --------> +----------+ 1168 [Application Data*] 1169 +----------+ 1170 <-------- [ACK] | Flight 4 | 1171 [Application Data*] +----------+ 1173 [Application Data] <-------> [Application Data] 1175 Figure 8: Message flights for the Zero-RTT handshake 1177 Client Server 1179 +----------+ 1180 <-------- [NewSessionTicket] | Flight 1 | 1181 +----------+ 1183 +----------+ 1184 [ACK] --------> | Flight 2 | 1185 +----------+ 1187 Figure 9: Message flights for the new session ticket message 1189 Note: The application data sent by the client is not included in the 1190 timeout and retransmission calculation. 1192 5.7. Timeout and Retransmission 1194 5.7.1. State Machine 1196 DTLS uses a simple timeout and retransmission scheme with the state 1197 machine shown in Figure 10. Because DTLS clients send the first 1198 message (ClientHello), they start in the PREPARING state. DTLS 1199 servers start in the WAITING state, but with empty buffers and no 1200 retransmit timer. 1202 +-----------+ 1203 | PREPARING | 1204 +----------> | | 1205 | | | 1206 | +-----------+ 1207 | | 1208 | | Buffer next flight 1209 | | 1210 | \|/ 1211 | +-----------+ 1212 | | | 1213 | | SENDING |<------------------+ 1214 | | | | 1215 | +-----------+ | 1216 Receive | | | 1217 next | | Send flight or partial | 1218 flight | | flight | 1219 | +---------------+ | 1220 | | | Set retransmit timer | 1221 | | \|/ | 1222 | | +-----------+ | 1223 | | | | | 1224 +--)---------| WAITING |-------------------+ 1225 | | +----->| | Timer expires | 1226 | | | +-----------+ | 1227 | | | | | | | 1228 | | | | | | | 1229 | | +----------+ | +--------------------+ 1230 | | Receive record | Read retransmit or ACK 1231 Receive | | Send ACK | 1232 last | | | 1233 flight | | | Receive ACK 1234 | | | for last flight 1235 \|/\|/ | 1236 | 1237 +-----------+ | 1238 | | <---------+ 1239 | FINISHED | 1240 | | 1241 +-----------+ 1242 | /|\ 1243 | | 1244 | | 1245 +---+ 1247 Server read retransmit 1248 Retransmit ACK 1250 Figure 10: DTLS timeout and retransmission state machine 1252 The state machine has four basic states: PREPARING, SENDING, WAITING, 1253 and FINISHED. 1255 In the PREPARING state, the implementation does whatever computations 1256 are necessary to prepare the next flight of messages. It then 1257 buffers them up for transmission (emptying the buffer first) and 1258 enters the SENDING state. 1260 In the SENDING state, the implementation transmits the buffered 1261 flight of messages. If the implementation has received one or more 1262 ACKs (see Section 7) from the peer, then it SHOULD omit any messages 1263 or message fragments which have already been ACKed. Once the 1264 messages have been sent, the implementation then enters the FINISHED 1265 state if this is the last flight in the handshake. Or, if the 1266 implementation expects to receive more messages, it sets a retransmit 1267 timer and then enters the WAITING state. 1269 There are four ways to exit the WAITING state: 1271 1. The retransmit timer expires: the implementation transitions to 1272 the SENDING state, where it retransmits the flight, resets the 1273 retransmit timer, and returns to the WAITING state. 1275 2. The implementation reads a ACK from the peer: upon receiving an 1276 ACK for a partial flight (as mentioned in Section 7.1), the 1277 implementation transitions to the SENDING state, where it 1278 retransmits the unacked portion of the flight, resets the 1279 retransmit timer, and returns to the WAITING state. Upon 1280 receiving an ACK for a complete flight, the implementation 1281 cancels all retransmissions and either remains in WAITING, or, if 1282 the ACK was for the final flight, transitions to FINISHED. 1284 3. The implementation reads a retransmitted flight from the peer: 1285 the implementation transitions to the SENDING state, where it 1286 retransmits the flight, resets the retransmit timer, and returns 1287 to the WAITING state. The rationale here is that the receipt of 1288 a duplicate message is the likely result of timer expiry on the 1289 peer and therefore suggests that part of one's previous flight 1290 was lost. 1292 4. The implementation receives some or all next flight of messages: 1293 if this is the final flight of messages, the implementation 1294 transitions to FINISHED. If the implementation needs to send a 1295 new flight, it transitions to the PREPARING state. Partial reads 1296 (whether partial messages or only some of the messages in the 1297 flight) may also trigger the implementation to send an ACK, as 1298 described in Section 7.1. 1300 Because DTLS clients send the first message (ClientHello), they start 1301 in the PREPARING state. DTLS servers start in the WAITING state, but 1302 with empty buffers and no retransmit timer. 1304 In addition, for at least twice the default Maximum Segment Lifetime 1305 (MSL) defined for [RFC0793], when in the FINISHED state, the server 1306 MUST respond to retransmission of the client's second flight with a 1307 retransmit of its ACK. 1309 Note that because of packet loss, it is possible for one side to be 1310 sending application data even though the other side has not received 1311 the first side's Finished message. Implementations MUST either 1312 discard or buffer all application data packets for the new epoch 1313 until they have received the Finished message for that epoch. 1314 Implementations MAY treat receipt of application data with a new 1315 epoch prior to receipt of the corresponding Finished message as 1316 evidence of reordering or packet loss and retransmit their final 1317 flight immediately, shortcutting the retransmission timer. 1319 5.7.2. Timer Values 1321 Though timer values are the choice of the implementation, mishandling 1322 of the timer can lead to serious congestion problems; for example, if 1323 many instances of a DTLS time out early and retransmit too quickly on 1324 a congested link. Implementations SHOULD use an initial timer value 1325 of 100 msec (the minimum defined in RFC 6298 [RFC6298]) and double 1326 the value at each retransmission, up to no less than the RFC 6298 1327 maximum of 60 seconds. Application specific profiles, such as those 1328 used for the Internet of Things environment, may recommend longer 1329 timer values. Note that a 100 msec timer is recommend rather than 1330 the 3-second RFC 6298 default in order to improve latency for time- 1331 sensitive applications. Because DTLS only uses retransmission for 1332 handshake and not dataflow, the effect on congestion should be 1333 minimal. 1335 Implementations SHOULD retain the current timer value until a 1336 transmission without loss occurs, at which time the value may be 1337 reset to the initial value. After a long period of idleness, no less 1338 than 10 times the current timer value, implementations may reset the 1339 timer to the initial value. One situation where this might occur is 1340 when a rehandshake is used after substantial data transfer. 1342 5.8. CertificateVerify and Finished Messages 1344 CertificateVerify and Finished messages have the same format as in 1345 TLS 1.3. Hash calculations include entire handshake messages, 1346 including DTLS-specific fields: message_seq, fragment_offset, and 1347 fragment_length. However, in order to remove sensitivity to 1348 handshake message fragmentation, the CertificateVerify and the 1349 Finished messages MUST be computed as if each handshake message had 1350 been sent as a single fragment following the algorithm described in 1351 Section 4.4.3 and Section 4.4.4 of [TLS13], respectively. 1353 5.9. Alert Messages 1355 Note that Alert messages are not retransmitted at all, even when they 1356 occur in the context of a handshake. However, a DTLS implementation 1357 which would ordinarily issue an alert SHOULD generate a new alert 1358 message if the offending record is received again (e.g., as a 1359 retransmitted handshake message). Implementations SHOULD detect when 1360 a peer is persistently sending bad messages and terminate the local 1361 connection state after such misbehavior is detected. 1363 5.10. Establishing New Associations with Existing Parameters 1365 If a DTLS client-server pair is configured in such a way that 1366 repeated connections happen on the same host/port quartet, then it is 1367 possible that a client will silently abandon one connection and then 1368 initiate another with the same parameters (e.g., after a reboot). 1369 This will appear to the server as a new handshake with epoch=0. In 1370 cases where a server believes it has an existing association on a 1371 given host/port quartet and it receives an epoch=0 ClientHello, it 1372 SHOULD proceed with a new handshake but MUST NOT destroy the existing 1373 association until the client has demonstrated reachability either by 1374 completing a cookie exchange or by completing a complete handshake 1375 including delivering a verifiable Finished message. After a correct 1376 Finished message is received, the server MUST abandon the previous 1377 association to avoid confusion between two valid associations with 1378 overlapping epochs. The reachability requirement prevents off-path/ 1379 blind attackers from destroying associations merely by sending forged 1380 ClientHellos. 1382 Note: it is not always possible to distinguish which association a 1383 given packet is from. For instance, if the client performs a 1384 handshake, abandons the connection, and then immediately starts a new 1385 handshake, it may not be possible to tell which connection a given 1386 protected record is for. In these cases, trial decryption MAY be 1387 necessary, though implementations could also use some sort of 1388 connection identifier, such as the one specified in 1389 [I-D.rescorla-tls-dtls-connection-id]. 1391 6. Example of Handshake with Timeout and Retransmission 1393 The following is an example of a handshake with lost packets and 1394 retransmissions. 1396 Client Server 1397 ------ ------ 1399 Record 0 --------> 1400 ClientHello 1401 (message_seq=0) 1402 +cookie 1404 X<----- Record 0 1405 (lost) ServerHello 1406 (message_seq=1) 1407 EncryptedExtensions 1408 (message_seq=2) 1409 Certificate 1410 (message_seq=3) 1412 <-------- Record 1 1413 CertificateVerify 1414 (message_seq=4) 1415 Finished 1416 (message_seq=5) 1418 Record 1 --------> 1419 ACK [1] 1421 <-------- Record 2 1422 ServerHello 1423 (message_seq=1) 1424 EncryptedExtensions 1425 (message_seq=2) 1426 Certificate 1427 (message_seq=3) 1429 Record 2 --------> 1430 Certificate 1431 (message_seq=2) 1432 CertificateVerify 1433 (message_seq=3) 1434 Finished 1435 (message_seq=4) 1437 <-------- Record 3 1438 ACK [2] 1440 Figure 11: Example DTLS exchange illustrating message loss 1442 6.1. Epoch Values and Rekeying 1444 A recipient of a DTLS message needs to select the correct keying 1445 material in order to process an incoming message. With the 1446 possibility of message loss and re-order an identifier is needed to 1447 determine which cipher state has been used to protect the record 1448 payload. The epoch value fulfills this role in DTLS. In addition to 1449 the key derivation steps described in Section 7 of [TLS13] triggered 1450 by the states during the handshake a sender may want to rekey at any 1451 time during the lifetime of the connection and has to have a way to 1452 indicate that it is updating its sending cryptographic keys. 1454 This version of DTLS assigns dedicated epoch values to messages in 1455 the protocol exchange to allow identification of the correct cipher 1456 state: 1458 - epoch value (0) is used with unencrypted messages. There are 1459 three unencrypted messages in DTLS, namely ClientHello, 1460 ServerHello, and HelloRetryRequest. 1462 - epoch value (1) is used for messages protected using keys derived 1463 from client_early_traffic_secret. This includes early data sent 1464 by the client and the EndOfEarlyData message. 1466 - epoch value (2) is used for messages protected using keys derived 1467 from [sender]_handshake_traffic_secret. Messages transmitted 1468 during the initial handshake, such as EncryptedExtensions, 1469 CertificateRequest, Certificate, CertificateVerify, and Finished 1470 belong to this category. Note, however, post-handshake are 1471 protected under the appropriate application traffic key and are 1472 not included in this category. 1474 - epoch value (3) is used for payloads protected using keys derived 1475 from the initial traffic_secret_0. This may include handshake 1476 messages, such as post-handshake messages (e.g., a 1477 NewSessionTicket message). 1479 - epoch value (4 to 2^16-1) is used for payloads protected using 1480 keys from the traffic_secret_N (N>0). 1482 Using these reserved epoch values a receiver knows what cipher state 1483 has been used to encrypt and integrity protect a message. 1484 Implementations that receive a payload with an epoch value for which 1485 no corresponding cipher state can be determined MUST generate a 1486 "unexpected_message" alert. For example, client incorrectly uses 1487 epoch value 5 when sending early application data in a 0-RTT 1488 exchange. A server will not be able to compute the appropriate keys 1489 and will therefore have to respond with an alert. 1491 Note that epoch values do not wrap. If a DTLS implementation would 1492 need to wrap the epoch value, it MUST terminate the connection. 1494 The traffic key calculation is described in Section 7.3 of [TLS13]. 1496 Figure 12 illustrates the epoch values in an example DTLS handshake. 1498 Client Server 1499 ------ ------ 1501 ClientHello 1502 (epoch=0) 1503 --------> 1505 <-------- HelloRetryRequest 1506 (epoch=0) 1508 ClientHello --------> 1509 (epoch=0) 1511 <-------- ServerHello 1512 (epoch=0) 1513 {EncryptedExtensions} 1514 (epoch=2) 1515 {Certificate} 1516 (epoch=2) 1517 {CertificateVerify} 1518 (epoch=2) 1519 {Finished} 1520 (epoch=2) 1522 {Certificate} --------> 1523 (epoch=2) 1524 {CertificateVerify} 1525 (epoch=2) 1526 {Finished} 1527 (epoch=2) 1529 <-------- [ACK] 1530 (epoch=3) 1532 [Application Data] --------> 1533 (epoch=3) 1535 <-------- [Application Data] 1536 (epoch=3) 1538 Some time later ... 1540 (Post-Handshake Message Exchange) 1542 <-------- [NewSessionTicket] 1543 (epoch=3) 1545 [ACK] --------> 1546 (epoch=3) 1548 Some time later ... 1549 (Rekeying) 1551 <-------- [Application Data] 1552 (epoch=4) 1553 [Application Data] --------> 1554 (epoch=4) 1556 Figure 12: Example DTLS exchange with epoch information 1558 7. ACK Message 1560 The ACK message is used by an endpoint to indicate handshake- 1561 containing the TLS records it has received from the other side. ACK 1562 is not a handshake message but is rather a separate content type, 1563 with code point TBD (proposed, 25). This avoids it consuming space 1564 in the handshake message sequence. Note that ACKs can still be 1565 piggybacked on the same UDP datagram as handshake records. 1567 struct { 1568 uint64 record_numbers<0..2^16-1>; 1569 } ACK; 1571 record_numbers: a list of the records containing handshake messages 1572 in the current flight which the endpoint has received, in 1573 numerically increasing order. ACKs only cover the current 1574 outstanding flight (this is possible because DTLS is generally a 1575 lockstep protocol). Thus, an ACK from the server would not cover 1576 both the ClientHello and the client's Certificate. 1577 Implementations can accomplish this by clearing their ACK list 1578 upon receiving the start of the next flight. 1580 ACK records MUST be sent with an epoch that is equal to or higher 1581 than the record which is being acknowledged. Implementations SHOULD 1582 simply use the current key. 1584 7.1. Sending ACKs 1586 When an implementation receives a partial flight, it SHOULD generate 1587 an ACK that covers the messages from that flight which it has 1588 received so far. Implementations have some discretion about when to 1589 generate ACKs, but it is RECOMMENDED that they do so under two 1590 circumstances: 1592 - When they receive a message or fragment which is out of order, 1593 either because it is not the next expected message or because it 1594 is not the next piece of the current message. Implementations 1595 MUST NOT send ACKs for handshake messages which they discard as 1596 out-of-order, because otherwise those messages will not be 1597 retransmitted. 1599 - When they have received part of a flight and do not immediately 1600 receive the rest of the flight (which may be in the same UDP 1601 datagram). A reasonable approach here is to set a timer for 1/4 1602 the current retransmit timer value when the first record in the 1603 flight is received and then send an ACK when that timer expires. 1605 In addition, implementations MUST send ACKs upon receiving all of any 1606 flight which they do not respond to with their own messages. 1607 Specifically, this means the client's final flight of the main 1608 handshake, the server's transmission of the NewSessionTicket, and 1609 KeyUpdate messages. ACKs SHOULD NOT be sent for other complete 1610 flights because they are implicitly acknowledged by the receipt of 1611 the next flight, which generally immediately follows the flight. 1612 Each NewSessionTicket or KeyUpdate is an individual flight; in 1613 particular, a KeyUpdate sent in response to a KeyUpdate with 1614 update_requested does not implicitly acknowledge that message. 1615 Implementations MAY ACK the records corresponding to each 1616 transmission of that flight or simply ACK the most recent one. 1618 ACKs MUST NOT be sent for other records of any content type other 1619 than handshake or for records which cannot be unprotected. 1621 Note that in some cases it may be necessary to send an ACK which does 1622 not contain any record numbers. For instance, a client might receive 1623 an EncryptedExtensions message prior to receiving a ServerHello. 1624 Because it cannot decrypt the EncryptedExtensions, it cannot safely 1625 ACK it (as it might be damaged). If the client does not send an ACK, 1626 the server will eventually retransmit its first flight, but this 1627 might take far longer than the actual round trip time between client 1628 and server. Having the client send an empty ACK shortcuts this 1629 process. 1631 7.2. Receiving ACKs 1633 When an implementation receives an ACK, it SHOULD record that the 1634 messages or message fragments sent in the records being ACKed were 1635 received and omit them from any future retransmissions. Upon receipt 1636 of an ACK for only some messages from a flight, an implementation 1637 SHOULD retransmit the remaining messages or fragments. Note that 1638 this requires implementations to track which messages appear in which 1639 records. Once all the messages in a flight have been acknowledged, 1640 the implementation MUST cancel all retransmissions of that flight. 1641 As noted above, the receipt of any packet responding to a given 1642 flight MUST be taken as an implicit ACK for the entire flight. 1644 8. Key Updates 1646 As with TLS 1.3, DTLS 1.3 implementations send a KeyUpdate message to 1647 indicate that they are updating their sending keys. As with other 1648 handshake messages with no built-in response, KeyUpdates MUST be 1649 acknowledged. In order to facilitate epoch reconstruction 1650 Section 4.2.2 implementations MUST NOT send with the new keys or send 1651 a new KeyUpdate until the previous KeyUpdate has been acknowledged 1652 (this avoids having too many epochs in active use). 1654 Due to loss and/or re-ordering, DTLS 1.3 implementations may receive 1655 a record with an older epoch than the current one (the requirements 1656 above preclude receiving a newer record). They SHOULD attempt to 1657 process those records with that epoch (see Section 4.2.2 for 1658 information on determining the correct epoch), but MAY opt to discard 1659 such out-of-epoch records. 1661 Although KeyUpdate MUST be ACKed, it is possible for the ACK to be 1662 lost, in which case the sender of the KeyUpdate will retransmit it. 1663 Implementations MUST retain the ability to ACK the KeyUpdate for up 1664 to 2MSL. It is RECOMMENDED that they do so by retaining the pre- 1665 update keying material, but they MAY do so by responding to messages 1666 which appear to be out-of-epoch with a canned ACK message; in this 1667 case, implementations SHOULD rate limit how often they send such 1668 ACKs. 1670 9. Connection ID Updates 1672 If the client and server have negotiated the "connection_id" 1673 extension [DTLS-CID], either side can send a new connection ID which 1674 it wishes the other side to use in a NewConnectionId message. 1676 enum { 1677 cid_immediate(0), cid_spare(1), (255) 1678 } ConnectionIdUsage; 1680 opaque ConnectionId<0..2^8-1>; 1682 struct { 1683 ConnectionIds cids<0..2^16-1>; 1684 ConnectionIdUsage usage; 1685 } NewConnectionId; 1687 cid Indicates the set of CIDs which the sender wishes the peer to 1688 use. 1690 usage Indicates whether the new CIDs should be used immediately or 1691 are spare. If usage is set to "cid_immediate", then one of the 1692 new CID MUST be used immediately for all future records. If it is 1693 set to "cid_spare", then either existing or new CID MAY be used. 1695 Endpoints SHOULD use receiver-provided CIDs in the order they were 1696 provided. Endpoints MUST NOT have more than one NewConnectionId 1697 message outstanding. 1699 If the client and server have negotiated the "connection_id" 1700 extension, either side can request a new CID using the 1701 RequestConnectionId message. 1703 struct { 1704 uint8 num_cids; 1705 } RequestConnectionId; 1707 num_cids The number of CIDs desired. 1709 Endpoints SHOULD respond to RequestConnectionId by sending a 1710 NewConnectionId with usage "cid_spare" containing num_cid CIDs soon 1711 as possible. Endpoints MUST NOT send a RequestConnectionId message 1712 when an existing request is still unfulfilled; this implies that 1713 endpoints needs to request new CIDs well in advance. An endpoint MAY 1714 ignore requests, which it considers excessive (though they MUST be 1715 ACKed as usual). 1717 Endpoints MUST NOT send either of these messages if they did not 1718 negotiate a connection ID. If an implementation receives these 1719 messages when connection IDs were not negotiated, it MUST abort the 1720 connection with an unexpected_message alert. 1722 9.1. ID Example 1724 Below is an example exchange for DTLS 1.3 using a single connection 1725 id in each direction. 1727 Note: The connection_id extension is defined in [DTLS-CID], which is 1728 used in ClientHello and ServerHello messages. 1730 Client Server 1731 ------ ------ 1733 ClientHello 1734 (connection_id=5) 1735 --------> 1737 <-------- HelloRetryRequest 1738 (cookie) 1740 ClientHello --------> 1741 (connection_id=5) 1742 +cookie 1744 <-------- ServerHello 1745 (connection_id=100) 1746 EncryptedExtensions 1747 (cid=5) 1748 Certificate 1749 (cid=5) 1750 CertificateVerify 1751 (cid=5) 1752 Finished 1753 (cid=5) 1755 Certificate --------> 1756 (cid=100) 1757 CertificateVerify 1758 (cid=100) 1759 Finished 1760 (cid=100) 1761 <-------- Ack 1762 (cid=5) 1764 Application Data ========> 1765 (cid=100) 1766 <======== Application Data 1767 (cid=5) 1769 Figure 13: Example DTLS 1.3 Exchange with Connection IDs 1771 10. Application Data Protocol 1773 Application data messages are carried by the record layer and are 1774 fragmented and encrypted based on the current connection state. The 1775 messages are treated as transparent data to the record layer. 1777 11. Security Considerations 1779 Security issues are discussed primarily in [TLS13]. 1781 The primary additional security consideration raised by DTLS is that 1782 of denial of service. DTLS includes a cookie exchange designed to 1783 protect against denial of service. However, implementations that do 1784 not use this cookie exchange are still vulnerable to DoS. In 1785 particular, DTLS servers that do not use the cookie exchange may be 1786 used as attack amplifiers even if they themselves are not 1787 experiencing DoS. Therefore, DTLS servers SHOULD use the cookie 1788 exchange unless there is good reason to believe that amplification is 1789 not a threat in their environment. Clients MUST be prepared to do a 1790 cookie exchange with every handshake. 1792 Unlike TLS implementations, DTLS implementations SHOULD NOT respond 1793 to invalid records by terminating the connection. 1795 If implementations process out-of-epoch records as recommended in 1796 Section 8, then this creates a denial of service risk since an 1797 adversary could inject packets with fake epoch values, forcing the 1798 recipient to compute the next-generation application_traffic_secret 1799 using the HKDF-Expand-Label construct to only find out that the 1800 message was does not pass the AEAD cipher processing. The impact of 1801 this attack is small since the HKDF-Expand-Label only performs 1802 symmetric key hashing operations. Implementations which are 1803 concerned about this form of attack can discard out-of-epoch records. 1805 The security and privacy properties of the connection ID for DTLS 1.3 1806 builds on top of what is described in [DTLS-CID]. There are, 1807 however, several improvements: 1809 - The use of the Post-Handshake message allows the client and the 1810 server to update their connection IDs and those values are 1811 exchanged with confidentiality protection. 1813 - With multi-homing, an adversary is able to correlate the 1814 communication interaction over the two paths, which adds further 1815 privacy concerns. In order to prevent this, implementations 1816 SHOULD attempt to use fresh connection IDs whenever they change 1817 local addresses or ports (though this is not always possible to 1818 detect). The RequestConnectionId message can be used to ask for 1819 new IDs in order to ensure that you have a pool of suitable IDs. 1821 - Switching connection ID based on certain events, or even 1822 regularly, helps against tracking by onpath adversaries but the 1823 sequence numbers can still allow linkability. For this reason 1824 this specification defines an algorithm for encrypting sequence 1825 numbers, see Section 4.2.3. 1827 - Since the DTLS 1.3 exchange encrypts handshake messages much 1828 earlier than in previous DTLS versions information identifying the 1829 DTLS client, such as the client certificate, less information is 1830 available to an on-path adversary. 1832 12. Changes to DTLS 1.2 1834 Since TLS 1.3 introduces a large number of changes to TLS 1.2, the 1835 list of changes from DTLS 1.2 to DTLS 1.3 is equally large. For this 1836 reason this section focuses on the most important changes only. 1838 - New handshake pattern, which leads to a shorter message exchange 1840 - Support for AEAD-only ciphers 1842 - HelloRetryRequest of TLS 1.3 used instead of HelloVerifyRequest 1844 - More flexible ciphersuite negotiation 1846 - New session resumption mechanism 1848 - PSK authentication redefined 1850 - New key derivation hierarchy utilizing a new key derivation 1851 construct 1853 - Removed support for weaker and older cryptographic algorithms 1855 - Improved version negotiation 1857 - Optimized record layer encoding and thereby its size 1859 - Added connection ID functionality 1861 - Sequence numbers are encrypted. 1863 13. IANA Considerations 1865 IANA is requested to allocate a new value in the "TLS ContentType" 1866 registry for the ACK message, defined in Section 7, with content type 1867 25. IANA is requested to reserve the content type range 32-63 so 1868 that content types in this range are not allocated. 1870 IANA is requested to allocate two values in the "TLS Handshake Type" 1871 registry, defined in [TLS13], for RequestConnectionId (TBD), and 1872 NewConnectionId (TBD), as defined in this document. 1874 14. References 1876 14.1. Normative References 1878 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1879 DOI 10.17487/RFC0768, August 1980, 1880 . 1882 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1883 RFC 793, DOI 10.17487/RFC0793, September 1981, 1884 . 1886 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1887 DOI 10.17487/RFC1191, November 1990, 1888 . 1890 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1891 Requirement Levels", BCP 14, RFC 2119, 1892 DOI 10.17487/RFC2119, March 1997, 1893 . 1895 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1896 Control Message Protocol (ICMPv6) for the Internet 1897 Protocol Version 6 (IPv6) Specification", STD 89, 1898 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1899 . 1901 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1902 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1903 . 1905 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 1906 "Computing TCP's Retransmission Timer", RFC 6298, 1907 DOI 10.17487/RFC6298, June 2011, 1908 . 1910 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1911 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1912 May 2017, . 1914 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1915 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1916 . 1918 14.2. Informative References 1920 [DTLS-CID] 1921 Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom, 1922 "Connection Identifiers for DTLS 1.2", draft-ietf-tls- 1923 dtls-connection-id-02 (work in progress), October 2018. 1925 [I-D.rescorla-tls-dtls-connection-id] 1926 Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom, 1927 "The Datagram Transport Layer Security (DTLS) Connection 1928 Identifier", draft-rescorla-tls-dtls-connection-id-02 1929 (work in progress), November 2017. 1931 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 1932 Protocol", RFC 2522, DOI 10.17487/RFC2522, March 1999, 1933 . 1935 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1936 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1937 . 1939 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1940 Congestion Control Protocol (DCCP)", RFC 4340, 1941 DOI 10.17487/RFC4340, March 2006, 1942 . 1944 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1945 (TLS) Protocol Version 1.1", RFC 4346, 1946 DOI 10.17487/RFC4346, April 2006, 1947 . 1949 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1950 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 1951 . 1953 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1954 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1955 . 1957 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 1958 the Datagram Congestion Control Protocol (DCCP)", 1959 RFC 5238, DOI 10.17487/RFC5238, May 2008, 1960 . 1962 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1963 (TLS) Protocol Version 1.2", RFC 5246, 1964 DOI 10.17487/RFC5246, August 2008, 1965 . 1967 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1968 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1969 January 2012, . 1971 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1972 Kivinen, "Internet Key Exchange Protocol Version 2 1973 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1974 2014, . 1976 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1977 "Recommendations for Secure Use of Transport Layer 1978 Security (TLS) and Datagram Transport Layer Security 1979 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1980 2015, . 1982 14.3. URIs 1984 [1] mailto:tls@ietf.org 1986 [2] https://www1.ietf.org/mailman/listinfo/tls 1988 [3] https://www.ietf.org/mail-archive/web/tls/current/index.html 1990 Appendix A. Protocol Data Structures and Constant Values 1992 This section provides the normative protocol types and constants 1993 definitions. 1995 A.1. Record Layer 1997 struct { 1998 ContentType type; 1999 ProtocolVersion legacy_record_version; 2000 uint16 epoch = 0 // DTLS field 2001 uint48 sequence_number; // DTLS field 2002 uint16 length; 2003 opaque fragment[DTLSPlaintext.length]; 2004 } DTLSPlaintext; 2006 struct { 2007 opaque content[DTLSPlaintext.length]; 2008 ContentType type; 2009 uint8 zeros[length_of_padding]; 2010 } DTLSInnerPlaintext; 2012 struct { 2013 opaque unified_hdr[variable]; 2014 opaque encrypted_record[length]; 2015 } DTLSCiphertext; 2017 0 1 2 3 4 5 6 7 2018 +-+-+-+-+-+-+-+-+ 2019 |0|0|1|C|S|L|E E| 2020 +-+-+-+-+-+-+-+-+ 2021 | Connection ID | Legend: 2022 | (if any, | 2023 / length as / C - CID present 2024 | negotiated) | S - Sequence number length 2025 +-+-+-+-+-+-+-+-+ L - Length present 2026 | 8 or 16 bit | E - Epoch 2027 |Sequence Number| 2028 +-+-+-+-+-+-+-+-+ 2029 | 16 bit Length | 2030 | (if present) | 2031 +-+-+-+-+-+-+-+-+ 2033 A.2. Handshake Protocol 2035 enum { 2036 hello_request_RESERVED(0), 2037 client_hello(1), 2038 server_hello(2), 2039 hello_verify_request_RESERVED(3), 2040 new_session_ticket(4), 2041 end_of_early_data(5), 2042 hello_retry_request_RESERVED(6), 2043 encrypted_extensions(8), 2044 certificate(11), 2045 server_key_exchange_RESERVED(12), 2046 certificate_request(13), 2047 server_hello_done_RESERVED(14), 2048 certificate_verify(15), 2049 client_key_exchange_RESERVED(16), 2050 finished(20), 2051 key_update(24), 2052 message_hash(254), 2053 (255) 2054 } HandshakeType; 2056 struct { 2057 HandshakeType msg_type; /* handshake type */ 2058 uint24 length; /* bytes in message */ 2059 uint16 message_seq; /* DTLS-required field */ 2060 uint24 fragment_offset; /* DTLS-required field */ 2061 uint24 fragment_length; /* DTLS-required field */ 2062 select (HandshakeType) { 2063 case client_hello: ClientHello; 2064 case server_hello: ServerHello; 2065 case end_of_early_data: EndOfEarlyData; 2066 case encrypted_extensions: EncryptedExtensions; 2067 case certificate_request: CertificateRequest; 2068 case certificate: Certificate; 2069 case certificate_verify: CertificateVerify; 2070 case finished: Finished; 2071 case new_session_ticket: NewSessionTicket; 2072 case key_update: KeyUpdate; 2073 } body; 2074 } Handshake; 2076 uint16 ProtocolVersion; 2077 opaque Random[32]; 2079 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 2081 struct { 2082 ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2 2083 Random random; 2084 opaque legacy_session_id<0..32>; 2085 opaque legacy_cookie<0..2^8-1>; // DTLS 2086 CipherSuite cipher_suites<2..2^16-2>; 2087 opaque legacy_compression_methods<1..2^8-1>; 2088 Extension extensions<8..2^16-1>; 2089 } ClientHello; 2091 A.3. ACKs 2093 struct { 2094 uint64 record_numbers<0..2^16-1>; 2095 } ACK; 2097 A.4. Connection ID Management 2099 enum { 2100 cid_immediate(0), cid_spare(1), (255) 2101 } ConnectionIdUsage; 2103 opaque ConnectionId<0..2^8-1>; 2105 struct { 2106 ConnectionIds cids<0..2^16-1>; 2107 ConnectionIdUsage usage; 2108 } NewConnectionId; 2110 struct { 2111 uint8 num_cids; 2112 } RequestConnectionId; 2114 Appendix B. History 2116 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 2118 IETF Drafts draft-29: - Added support for sequence number encryption 2119 - Update to new record format - Emphasize that compatibility mode 2120 isn't used. 2122 draft-28: - Version bump to align with TLS 1.3 pre-RFC version. 2124 draft-27: - Incorporated unified header format. - Added support for 2125 connection IDs. 2127 draft-04 - 26: - Submissions to align with TLS 1.3 draft versions 2129 draft-03 - Only update keys after KeyUpdate is ACKed. 2131 draft-02 - Shorten the protected record header and introduce an 2132 ultra-short version of the record header. - Reintroduce KeyUpdate, 2133 which works properly now that we have ACK. - Clarify the ACK rules. 2135 draft-01 - Restructured the ACK to contain a list of packets and also 2136 be a record rather than a handshake message. 2138 draft-00 - First IETF Draft 2140 Personal Drafts draft-01 - Alignment with version -19 of the TLS 1.3 2141 specification 2143 draft-00 2145 - Initial version using TLS 1.3 as a baseline. 2147 - Use of epoch values instead of KeyUpdate message 2149 - Use of cookie extension instead of cookie field in ClientHello and 2150 HelloVerifyRequest messages 2152 - Added ACK message 2154 - Text about sequence number handling 2156 Appendix C. Working Group Information 2158 The discussion list for the IETF TLS working group is located at the 2159 e-mail address tls@ietf.org [1]. Information on the group and 2160 information on how to subscribe to the list is at 2161 https://www1.ietf.org/mailman/listinfo/tls [2] 2163 Archives of the list can be found at: https://www.ietf.org/mail- 2164 archive/web/tls/current/index.html [3] 2166 Appendix D. Contributors 2168 Many people have contributed to previous DTLS versions and they are 2169 acknowledged in prior versions of DTLS specifications or in the 2170 referenced specifications. The sequence number encryption concept is 2171 taken from the QUIC specification. We would like to thank the 2172 authors of the QUIC specification for their work. 2174 In addition, we would like to thank: 2176 * Ilari Liusvaara 2177 Independent 2178 ilariliusvaara@welho.com 2180 * Martin Thomson 2181 Mozilla 2182 martin.thomson@gmail.com 2184 * Yin Xinxing 2185 Huawei 2186 yinxinxing@huawei.com 2188 * Thomas Fossati 2189 Nokia 2190 thomas.fossati@nokia.com 2192 * Tobias Gondrom 2193 Huawei 2194 tobias.gondrom@gondrom.org 2196 Authors' Addresses 2198 Eric Rescorla 2199 RTFM, Inc. 2201 EMail: ekr@rtfm.com 2203 Hannes Tschofenig 2204 Arm Limited 2206 EMail: hannes.tschofenig@arm.com 2208 Nagendra Modadugu 2209 Google, Inc. 2211 EMail: nagendra@cs.stanford.edu