idnits 2.17.1 draft-ietf-tls-dtls13-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC6347, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 07, 2017) is 2484 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 805 -- Looks like a reference, but probably isn't: '2' on line 1222 == Missing Reference: 'Ack' is mentioned on line 1347, but not defined == Missing Reference: 'NewSessionTicket' is mentioned on line 1344, but not defined -- Looks like a reference, but probably isn't: '1' on line 1606 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-21 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) -- 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 (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS E. Rescorla 3 Internet-Draft RTFM, Inc. 4 Obsoletes: 6347 (if approved) H. Tschofenig 5 Intended status: Standards Track ARM Limited 6 Expires: January 8, 2018 N. Modadugu 7 Google, Inc. 8 July 07, 2017 10 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 11 draft-ietf-tls-dtls13-01 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 http://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 January 8, 2018. 42 Copyright Notice 44 Copyright (c) 2017 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 (http://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 Rational and Overview . . . . . . . . . . . . . . 5 74 3.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 6 75 3.1.1. Reordering . . . . . . . . . . . . . . . . . . . . . 6 76 3.1.2. Message Size . . . . . . . . . . . . . . . . . . . . 7 77 3.2. Replay Detection . . . . . . . . . . . . . . . . . . . . 7 78 4. The DTLS Record Layer . . . . . . . . . . . . . . . . . . . . 7 79 4.1. Sequence Number Handling . . . . . . . . . . . . . . . . 8 80 4.2. Transport Layer Mapping . . . . . . . . . . . . . . . . . 9 81 4.3. PMTU Issues . . . . . . . . . . . . . . . . . . . . . . . 10 82 4.4. Record Payload Protection . . . . . . . . . . . . . . . . 11 83 4.4.1. Anti-Replay . . . . . . . . . . . . . . . . . . . . . 11 84 4.4.2. Handling Invalid Records . . . . . . . . . . . . . . 12 85 5. The DTLS Handshake Protocol . . . . . . . . . . . . . . . . . 12 86 5.1. Denial-of-Service Countermeasures . . . . . . . . . . . . 13 87 5.2. DTLS Handshake Message Format . . . . . . . . . . . . . . 16 88 5.3. ClientHello Message . . . . . . . . . . . . . . . . . . . 18 89 5.4. Handshake Message Fragmentation and Reassembly . . . . . 19 90 5.5. DTLS Handshake Flights . . . . . . . . . . . . . . . . . 20 91 5.6. Timeout and Retransmission . . . . . . . . . . . . . . . 24 92 5.6.1. State Machine . . . . . . . . . . . . . . . . . . . . 24 93 5.6.2. Timer Values . . . . . . . . . . . . . . . . . . . . 26 94 5.7. CertificateVerify and Finished Messages . . . . . . . . . 27 95 5.8. Alert Messages . . . . . . . . . . . . . . . . . . . . . 27 96 5.9. Establishing New Associations with Existing Parameters . 27 98 6. Example of Handshake with Timeout and Retransmission . . . . 28 99 6.1. Epoch Values and Rekeying . . . . . . . . . . . . . . . . 30 100 7. ACK Message . . . . . . . . . . . . . . . . . . . . . . . . . 32 101 7.1. Sending ACKs . . . . . . . . . . . . . . . . . . . . . . 33 102 7.2. Receiving ACKs . . . . . . . . . . . . . . . . . . . . . 34 103 8. Application Data Protocol . . . . . . . . . . . . . . . . . . 34 104 9. Security Considerations . . . . . . . . . . . . . . . . . . . 34 105 10. Changes to DTLS 1.2 . . . . . . . . . . . . . . . . . . . . . 34 106 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 107 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 108 12.1. Normative References . . . . . . . . . . . . . . . . . . 35 109 12.2. Informative References . . . . . . . . . . . . . . . . . 36 110 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 38 111 Appendix B. Working Group Information . . . . . . . . . . . . . 38 112 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 38 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 115 1. Introduction 117 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH 119 The source for this draft is maintained in GitHub. Suggested changes 120 should be submitted as pull requests at https://github.com/tlswg/ 121 dtls13-spec. Instructions are on that page as well. Editorial 122 changes can be managed in GitHub, but any substantive change should 123 be discussed on the TLS mailing list. 125 The primary goal of the TLS protocol is to provide privacy and data 126 integrity between two communicating peers. The TLS protocol is 127 composed of two layers: the TLS Record Protocol and the TLS Handshake 128 Protocol. However, TLS must run over a reliable transport channel - 129 typically TCP [RFC0793]. 131 There are applications that utilize UDP [RFC0768] as a transport and 132 to offer communication security protection for those applications the 133 Datagram Transport Layer Security (DTLS) protocol has been designed. 134 DTLS is deliberately designed to be as similar to TLS as possible, 135 both to minimize new security invention and to maximize the amount of 136 code and infrastructure reuse. 138 DTLS 1.0 [RFC4347] was originally defined as a delta from TLS 1.1 139 [RFC4346] and DTLS 1.2 [RFC6347] was defined as a series of deltas to 140 TLS 1.2 [RFC5246]. There is no DTLS 1.1; that version number was 141 skipped in order to harmonize version numbers with TLS. This 142 specification describes the most current version of the DTLS protocol 143 aligning with the efforts around TLS 1.3 [I-D.ietf-tls-tls13]. 145 Implementations that speak both DTLS 1.2 and DTLS 1.3 can 146 interoperate with those that speak only DTLS 1.2 (using DTLS 1.2 of 147 course), just as TLS 1.3 implementations can interoperate with TLS 148 1.2 (see Appendix D of [I-D.ietf-tls-tls13] for details). While 149 backwards compatibility with DTLS 1.0 is possible the use of DTLS 1.0 150 is not recommended as explained in Section 3.1.2 of RFC 7525 151 [RFC7525]. 153 2. Conventions and Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 157 "OPTIONAL" in this document are to be interpreted as described in RFC 158 2119 [RFC2119]. 160 The following terms are used: 162 - client: The endpoint initiating the DTLS connection. 164 - connection: A transport-layer connection between two endpoints. 166 - endpoint: Either the client or server of the connection. 168 - handshake: An initial negotiation between client and server that 169 establishes the parameters of their transactions. 171 - peer: An endpoint. When discussing a particular endpoint, "peer" 172 refers to the endpoint that is remote to the primary subject of 173 discussion. 175 - receiver: An endpoint that is receiving records. 177 - sender: An endpoint that is transmitting records. 179 - session: An association between a client and a server resulting 180 from a handshake. 182 - server: The endpoint which did not initiate the DTLS connection. 184 The reader is assumed to be familiar with the TLS 1.3 specification 185 since this document defined as a delta from TLS 1.3. 187 Figures in this document illustrate various combinations of the DTLS 188 protocol exchanges and the symbols have the following meaning: 190 - '+' indicates noteworthy extensions sent in the previously noted 191 message. 193 - '*' indicates optional or situation-dependent messages/extensions 194 that are not always sent. 196 - '{}' indicates messages protected using keys derived from a 197 [sender]_handshake_traffic_secret. 199 - '[]' indicates messages protected using keys derived from 200 traffic_secret_N. 202 3. DTLS Design Rational and Overview 204 The basic design philosophy of DTLS is to construct "TLS over 205 datagram transport". Datagram transport does not require nor provide 206 reliable or in-order delivery of data. The DTLS protocol preserves 207 this property for application data. Applications such as media 208 streaming, Internet telephony, and online gaming use datagram 209 transport for communication due to the delay-sensitive nature of 210 transported data. The behavior of such applications is unchanged 211 when the DTLS protocol is used to secure communication, since the 212 DTLS protocol does not compensate for lost or re-ordered data 213 traffic. 215 TLS cannot be used directly in datagram environments for the 216 following five reasons: 218 1. TLS does not allow independent decryption of individual records. 219 Because the integrity check indirectly depends on a sequence 220 number, if record N is not received, then the integrity check on 221 record N+1 will be based on the wrong sequence number and thus 222 will fail. DTLS solves this problem by adding explicit sequence 223 numbers. 225 2. The TLS handshake is a lock-step cryptographic handshake. 226 Messages must be transmitted and received in a defined order; any 227 other order is an error. This is incompatible with reordering 228 and message loss. 230 3. Not all TLS 1.3 handshake messages (such as the NewSessionTicket 231 message) are acknowledged. Hence, a new acknowledgement message 232 has to be added to detect message loss. 234 4. Handshake messages are potentially larger than any given 235 datagram, thus creating the problem of IP fragmentation. 237 5. Datagram transport protocols, like UDP, are more vulnerable to 238 denial of service attacks and require a return-routability check 239 with the help of cookies to be integrated into the handshake. A 240 detailed discussion of countermeasures can be found in 241 Section 5.1. 243 3.1. Packet Loss 245 DTLS uses a simple retransmission timer to handle packet loss. 246 Figure 1 demonstrates the basic concept, using the first phase of the 247 DTLS handshake: 249 Client Server 250 ------ ------ 251 ClientHello ------> 253 X<-- HelloRetryRequest 254 (lost) 256 [Timer Expires] 258 ClientHello ------> 259 (retransmit) 261 Figure 1: DTLS Retransmission Example. 263 Once the client has transmitted the ClientHello message, it expects 264 to see a HelloRetryRequest from the server. However, if the server's 265 message is lost, the client knows that either the ClientHello or the 266 HelloRetryRequest has been lost and retransmits. When the server 267 receives the retransmission, it knows to retransmit. 269 The server also maintains a retransmission timer and retransmits when 270 that timer expires. 272 Note that timeout and retransmission do not apply to the 273 HelloRetryRequest since this would require creating state on the 274 server. The HelloRetryRequest is designed to be small enough that it 275 will not itself be fragmented, thus avoiding concerns about 276 interleaving multiple HelloRetryRequests. 278 3.1.1. Reordering 280 In DTLS, each handshake message is assigned a specific sequence 281 number within that handshake. When a peer receives a handshake 282 message, it can quickly determine whether that message is the next 283 message it expects. If it is, then it processes it. If not, it 284 queues it for future handling once all previous messages have been 285 received. 287 3.1.2. Message Size 289 TLS and DTLS handshake messages can be quite large (in theory up to 290 2^24-1 bytes, in practice many kilobytes). By contrast, UDP 291 datagrams are often limited to less than 1500 bytes if IP 292 fragmentation is not desired. In order to compensate for this 293 limitation, each DTLS handshake message may be fragmented over 294 several DTLS records, each of which is intended to fit in a single IP 295 datagram. Each DTLS handshake message contains both a fragment 296 offset and a fragment length. Thus, a recipient in possession of all 297 bytes of a handshake message can reassemble the original unfragmented 298 message. 300 3.2. Replay Detection 302 DTLS optionally supports record replay detection. The technique used 303 is the same as in IPsec AH/ESP, by maintaining a bitmap window of 304 received records. Records that are too old to fit in the window and 305 records that have previously been received are silently discarded. 306 The replay detection feature is optional, since packet duplication is 307 not always malicious, but can also occur due to routing errors. 308 Applications may conceivably detect duplicate packets and accordingly 309 modify their data transmission strategy. 311 4. The DTLS Record Layer 313 The DTLS record layer is similar to that of TLS 1.3 unless noted 314 otherwise. The only change is the inclusion of an explicit epoch and 315 sequence number in the record. This sequence number allows the 316 recipient to correctly verify the TLS MAC. The DTLS record format is 317 shown below: 319 struct { 320 opaque content[DTLSPlaintext.length]; 321 ContentType type; 322 uint8 zeros[length_of_padding]; 323 } DTLSInnerPlaintext; 325 struct { 326 ContentType opaque_type = 23; /* application_data */ 327 ProtocolVersion legacy_record_version = {254,253); // DTLSv1.2 328 uint16 epoch; // DTLS-related field 329 uint48 sequence_number; // DTLS-related field 330 uint16 length; 331 opaque encrypted_record[length]; 332 } DTLSCiphertext; 334 type: The content type of the record. 336 legacy_record_version: This field is redundant and it is treated in 337 the same way as specified in the TLS 1.3 specification. The DTLS 338 version 1.2 version number is reused, namely { 254, 253 }. This 339 field is deprecated and MUST be ignored. 341 epoch: A counter value that is incremented on every cipher state 342 change. 344 sequence_number: The sequence number for this record. 346 length: Identical to the length field in a TLS 1.3 record. 348 encrypted_record: Identical to the encrypted_record field in a TLS 349 1.3 record. 351 4.1. Sequence Number Handling 353 DTLS uses an explicit sequence number, rather than an implicit one, 354 carried in the sequence_number field of the record. Sequence numbers 355 are maintained separately for each epoch, with each sequence_number 356 initially being 0 for each epoch. For instance, if a handshake 357 message from epoch 0 is retransmitted, it might have a sequence 358 number after a message from epoch 1, even if the message from epoch 1 359 was transmitted first. Note that some care needs to be taken during 360 the handshake to ensure that retransmitted messages use the right 361 epoch and keying material. 363 The epoch number is initially zero and is incremented each time 364 keying material changes and a sender aims to rekey. More details are 365 provided in Section 6.1. In order to ensure that any given sequence/ 366 epoch pair is unique, implementations MUST NOT allow the same epoch 367 value to be reused within two times the TCP maximum segment lifetime 368 (MSL). 370 Note that because DTLS records may be reordered, a record from epoch 371 1 may be received after epoch 2 has begun. In general, 372 implementations SHOULD discard packets from earlier epochs, but if 373 packet loss causes noticeable problems they MAY choose to retain 374 keying material from previous epochs for up to the default MSL 375 specified for TCP [RFC0793] to allow for packet reordering. (Note 376 that the intention here is that implementers use the current guidance 377 from the IETF for MSL, not that they attempt to interrogate the MSL 378 that the system TCP stack is using.) Until the handshake has 379 completed, implementations MUST accept packets from the old epoch. 381 Conversely, it is possible for records that are protected by the 382 newly negotiated context to be received prior to the completion of a 383 handshake. For instance, the server may send its Finished message 384 and then start transmitting data. Implementations MAY either buffer 385 or discard such packets, though when DTLS is used over reliable 386 transports (e.g., SCTP), they SHOULD be buffered and processed once 387 the handshake completes. Note that TLS's restrictions on when 388 packets may be sent still apply, and the receiver treats the packets 389 as if they were sent in the right order. In particular, it is still 390 impermissible to send data prior to completion of the first 391 handshake. 393 Implementations MUST either abandon an association or re-key prior to 394 allowing the sequence number to wrap. 396 Implementations MUST NOT allow the epoch to wrap, but instead MUST 397 establish a new association, terminating the old association. 399 4.2. Transport Layer Mapping 401 Each DTLS record MUST fit within a single datagram. In order to 402 avoid IP fragmentation, clients of the DTLS record layer SHOULD 403 attempt to size records so that they fit within any PMTU estimates 404 obtained from the record layer. 406 Note that unlike IPsec, DTLS records do not contain any association 407 identifiers. Applications must arrange to multiplex between 408 associations. With UDP, the host/port number is used to look up the 409 appropriate security association for incoming records. 411 Multiple DTLS records may be placed in a single datagram. They are 412 simply encoded consecutively. The DTLS record framing is sufficient 413 to determine the boundaries. Note, however, that the first byte of 414 the datagram payload must be the beginning of a record. Records may 415 not span datagrams. 417 Some transports, such as DCCP [RFC4340], provide their own sequence 418 numbers. When carried over those transports, both the DTLS and the 419 transport sequence numbers will be present. Although this introduces 420 a small amount of inefficiency, the transport layer and DTLS sequence 421 numbers serve different purposes; therefore, for conceptual 422 simplicity, it is superior to use both sequence numbers. 424 Some transports provide congestion control for traffic carried over 425 them. If the congestion window is sufficiently narrow, DTLS 426 handshake retransmissions may be held rather than transmitted 427 immediately, potentially leading to timeouts and spurious 428 retransmission. When DTLS is used over such transports, care should 429 be taken not to overrun the likely congestion window. [RFC5238] 430 defines a mapping of DTLS to DCCP that takes these issues into 431 account. 433 4.3. PMTU Issues 435 In general, DTLS's philosophy is to leave PMTU discovery to the 436 application. However, DTLS cannot completely ignore PMTU for three 437 reasons: 439 - The DTLS record framing expands the datagram size, thus lowering 440 the effective PMTU from the application's perspective. 442 - In some implementations, the application may not directly talk to 443 the network, in which case the DTLS stack may absorb ICMP 444 [RFC1191] "Datagram Too Big" indications or ICMPv6 [RFC4443] 445 "Packet Too Big" indications. 447 - The DTLS handshake messages can exceed the PMTU. 449 In order to deal with the first two issues, the DTLS record layer 450 SHOULD behave as described below. 452 If PMTU estimates are available from the underlying transport 453 protocol, they should be made available to upper layer protocols. In 454 particular: 456 - For DTLS over UDP, the upper layer protocol SHOULD be allowed to 457 obtain the PMTU estimate maintained in the IP layer. 459 - For DTLS over DCCP, the upper layer protocol SHOULD be allowed to 460 obtain the current estimate of the PMTU. 462 - For DTLS over TCP or SCTP, which automatically fragment and 463 reassemble datagrams, there is no PMTU limitation. However, the 464 upper layer protocol MUST NOT write any record that exceeds the 465 maximum record size of 2^14 bytes. 467 The DTLS record layer SHOULD allow the upper layer protocol to 468 discover the amount of record expansion expected by the DTLS 469 processing. 471 If there is a transport protocol indication (either via ICMP or via a 472 refusal to send the datagram as in Section 14 of [RFC4340]), then the 473 DTLS record layer MUST inform the upper layer protocol of the error. 475 The DTLS record layer SHOULD NOT interfere with upper layer protocols 476 performing PMTU discovery, whether via [RFC1191] or [RFC4821] 477 mechanisms. In particular: 479 - Where allowed by the underlying transport protocol, the upper 480 layer protocol SHOULD be allowed to set the state of the DF bit 481 (in IPv4) or prohibit local fragmentation (in IPv6). 483 - If the underlying transport protocol allows the application to 484 request PMTU probing (e.g., DCCP), the DTLS record layer should 485 honor this request. 487 The final issue is the DTLS handshake protocol. From the perspective 488 of the DTLS record layer, this is merely another upper layer 489 protocol. However, DTLS handshakes occur infrequently and involve 490 only a few round trips; therefore, the handshake protocol PMTU 491 handling places a premium on rapid completion over accurate PMTU 492 discovery. In order to allow connections under these circumstances, 493 DTLS implementations SHOULD follow the following rules: 495 - If the DTLS record layer informs the DTLS handshake layer that a 496 message is too big, it SHOULD immediately attempt to fragment it, 497 using any existing information about the PMTU. 499 - If repeated retransmissions do not result in a response, and the 500 PMTU is unknown, subsequent retransmissions SHOULD back off to a 501 smaller record size, fragmenting the handshake message as 502 appropriate. This standard does not specify an exact number of 503 retransmits to attempt before backing off, but 2-3 seems 504 appropriate. 506 4.4. Record Payload Protection 508 Like TLS, DTLS transmits data as a series of protected records. The 509 rest of this section describes the details of that format. 511 4.4.1. Anti-Replay 513 DTLS records contain a sequence number to provide replay protection. 514 Sequence number verification SHOULD be performed using the following 515 sliding window procedure, borrowed from Section 3.4.3 of [RFC4303]. 517 The receiver packet counter for this session MUST be initialized to 518 zero when the session is established. For each received record, the 519 receiver MUST verify that the record contains a sequence number that 520 does not duplicate the sequence number of any other record received 521 during the life of this session. This SHOULD be the first check 522 applied to a packet after it has been matched to a session, to speed 523 rejection of duplicate records. 525 Duplicates are rejected through the use of a sliding receive window. 526 (How the window is implemented is a local matter, but the following 527 text describes the functionality that the implementation must 528 exhibit.) A minimum window size of 32 MUST be supported, but a 529 window size of 64 is preferred and SHOULD be employed as the default. 530 Another window size (larger than the minimum) MAY be chosen by the 531 receiver. (The receiver does not notify the sender of the window 532 size.) 534 The "right" edge of the window represents the highest validated 535 sequence number value received on this session. Records that contain 536 sequence numbers lower than the "left" edge of the window are 537 rejected. Packets falling within the window are checked against a 538 list of received packets within the window. An efficient means for 539 performing this check, based on the use of a bit mask, is described 540 in Section 3.4.3 of [RFC4303]. 542 If the received record falls within the window and is new, or if the 543 packet is to the right of the window, then the receiver proceeds to 544 MAC verification. If the MAC validation fails, the receiver MUST 545 discard the received record as invalid. The receive window is 546 updated only if the MAC verification succeeds. 548 4.4.2. Handling Invalid Records 550 Unlike TLS, DTLS is resilient in the face of invalid records (e.g., 551 invalid formatting, length, MAC, etc.). In general, invalid records 552 SHOULD be silently discarded, thus preserving the association; 553 however, an error MAY be logged for diagnostic purposes. 554 Implementations which choose to generate an alert instead, MUST 555 generate error alerts to avoid attacks where the attacker repeatedly 556 probes the implementation to see how it responds to various types of 557 error. Note that if DTLS is run over UDP, then any implementation 558 which does this will be extremely susceptible to denial-of-service 559 (DoS) attacks because UDP forgery is so easy. Thus, this practice is 560 NOT RECOMMENDED for such transports. 562 If DTLS is being carried over a transport that is resistant to 563 forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts 564 because an attacker will have difficulty forging a datagram that will 565 not be rejected by the transport layer. 567 5. The DTLS Handshake Protocol 569 DTLS 1.3 re-uses the TLS 1.3 handshake messages and flows, with the 570 following changes: 572 1. To handle message loss, reordering, and fragmentation 573 modifications to the handshake header are necessary. 575 2. Retransmission timers are introduced to handle message loss. 577 3. The TLS 1.3 KeyUpdate message is not used in DTLS 1.3 for re- 578 keying. 580 4. A new ACK content type has been added for reliable message 581 delivery of handshake messages. 583 Note that TLS 1.3 already supports a cookie extension, which used to 584 prevent denial-of-service attacks. This DoS prevention mechanism is 585 described in more detail below since UDP-based protocols are more 586 vulnerable to amplification attacks than a connection-oriented 587 transport like TCP that performs return-routability checks as part of 588 the connection establishment. 590 With these exceptions, the DTLS message formats, flows, and logic are 591 the same as those of TLS 1.3. 593 5.1. Denial-of-Service Countermeasures 595 Datagram security protocols are extremely susceptible to a variety of 596 DoS attacks. Two attacks are of particular concern: 598 1. An attacker can consume excessive resources on the server by 599 transmitting a series of handshake initiation requests, causing 600 the server to allocate state and potentially to perform expensive 601 cryptographic operations. 603 2. An attacker can use the server as an amplifier by sending 604 connection initiation messages with a forged source of the 605 victim. The server then sends its response to the victim 606 machine, thus flooding it. Depending on the selected ciphersuite 607 this response message can be quite large, as it is the case for a 608 Certificate message. 610 In order to counter both of these attacks, DTLS borrows the stateless 611 cookie technique used by Photuris [RFC2522] and IKE [RFC5996]. When 612 the client sends its ClientHello message to the server, the server 613 MAY respond with a HelloRetryRequest message. The HelloRetryRequest 614 message, as well as the cookie extension, is defined in TLS 1.3. The 615 HelloRetryRequest message contains a stateless cookie generated using 616 the technique of [RFC2522]. The client MUST retransmit the 617 ClientHello with the cookie added as an extension. The server then 618 verifies the cookie and proceeds with the handshake only if it is 619 valid. This mechanism forces the attacker/client to be able to 620 receive the cookie, which makes DoS attacks with spoofed IP addresses 621 difficult. This mechanism does not provide any defence against DoS 622 attacks mounted from valid IP addresses. 624 The DTLS 1.3 specification changes the way how cookies are exchanged 625 compared to DTLS 1.2. DTLS 1.3 re-uses the HelloRetryRequest message 626 and conveys the cookie to the client via an extension. The client 627 receiving the cookie uses the same extension to place the cookie 628 subsequently into a ClientHello message. DTLS 1.2 on the other hand 629 used a separate message, namely the HelloVerifyRequest, to pass a 630 cookie to the client and did not utilize the extension mechanism. 631 For backwards compatibility reason the cookie field in the 632 ClientHello is present in DTLS 1.3 but is ignored by a DTLS 1.3 633 compliant server implementation. 635 The exchange is shown in Figure 2. Note that the figure focuses on 636 the cookie exchange; all other extensions are omitted. 638 Client Server 639 ------ ------ 640 ClientHello ------> 642 <----- HelloRetryRequest 643 + cookie 645 ClientHello ------> 646 + cookie 648 [Rest of handshake] 650 Figure 2: DTLS Exchange with HelloRetryRequest contain the Cookie 651 Extension 653 The cookie extension is defined in Section 4.2.2 of 654 [I-D.ietf-tls-tls13]. When sending the initial ClientHello, the 655 client does not have a cookie yet. In this case, the cookie 656 extension is omitted and the legacy_cookie field in the ClientHello 657 message SHOULD be set to a zero length vector (i.e., a single zero 658 byte length field) and MUST be ignored by a server negotiating DTLS 659 1.3. 661 When responding to a HelloRetryRequest, the client MUST create a new 662 ClientHello message following the description in Section 4.1.2 of 663 [I-D.ietf-tls-tls13]. 665 If the HelloRetryRequest message is used, the initial ClientHello and 666 the HelloRetryRequest are included in the calculation of the 667 handshake_messages (for the CertificateVerify message) and 668 verify_data (for the Finished message). However, the computation of 669 the message hash for the HelloRetryRequest is done according to the 670 description in Section 4.4.1 of [I-D.ietf-tls-tls13]. 672 The handshake transcript is not reset with the second ClientHello and 673 a stateless server-cookie implementation requires the transcript of 674 the HelloRetryRequest to be stored in the cookie or the internal 675 state of the hash algorithm, since only the hash of the transcript is 676 required for the handshake to complete. 678 When the second ClientHello is received, the server can verify that 679 the cookie is valid and that the client can receive packets at the 680 given IP address. If the client's apparent IP address is embedded in 681 the cookie, this prevents an attacker from generating an acceptable 682 ClientHello apparently from another user. 684 One potential attack on this scheme is for the attacker to collect a 685 number of cookies from different addresses where it controls 686 endpoints and then reuse them to attack the server. The server can 687 defend against this attack by changing the secret value frequently, 688 thus invalidating those cookies. If the server wishes that 689 legitimate clients be able to handshake through the transition (e.g., 690 they received a cookie with Secret 1 and then sent the second 691 ClientHello after the server has changed to Secret 2), the server can 692 have a limited window during which it accepts both secrets. 693 [RFC5996] suggests adding a key identifier to cookies to detect this 694 case. An alternative approach is simply to try verifying with both 695 secrets. It is RECOMMENDED that servers implement a key rotation 696 scheme that allows the server to manage keys with overlapping 697 lifetime. 699 Alternatively, the server can store timestamps in the cookie and 700 reject those cookies that were not generated within a certain amount 701 of time. 703 DTLS servers SHOULD perform a cookie exchange whenever a new 704 handshake is being performed. If the server is being operated in an 705 environment where amplification is not a problem, the server MAY be 706 configured not to perform a cookie exchange. The default SHOULD be 707 that the exchange is performed, however. In addition, the server MAY 708 choose not to do a cookie exchange when a session is resumed. 709 Clients MUST be prepared to do a cookie exchange with every 710 handshake. 712 If a server receives a ClientHello with an invalid cookie, it MUST 713 NOT respond with a HelloRetryRequest. Restarting the handshake from 714 scratch, without a cookie, allows the client to recover from a 715 situation where it obtained a cookie that cannot be verified by the 716 server. As described in Section 4.1.4 of 717 [I-D.ietf-tls-tls13],clients SHOULD also abort the handshake with an 718 "unexpected_message" alert in response to any second 719 HelloRetryRequest which was sent in the same connection (i.e., where 720 the ClientHello was itself in response to a HelloRetryRequest). 722 5.2. DTLS Handshake Message Format 724 In order to support message loss, reordering, and message 725 fragmentation, DTLS modifies the TLS 1.3 handshake header: 727 enum { 728 hello_request_RESERVED(0), 729 client_hello(1), 730 server_hello(2), 731 hello_verify_request_RESERVED(3), 732 new_session_ticket(4), 733 end_of_early_data(5), 734 hello_retry_request(6), 735 encrypted_extensions(8), 736 certificate(11), 737 server_key_exchange_RESERVED(12), 738 certificate_request(13), 739 server_hello_done_RESERVED(14), 740 certificate_verify(15), 741 client_key_exchange_RESERVED(16), 742 finished(20), 743 key_update_RESERVED(24), 744 ack([[TBD RFC Editor -- Proposal: 25]]), 745 message_hash(254), 746 (255) 747 } HandshakeType; 749 struct { 750 HandshakeType msg_type; /* handshake type */ 751 uint24 length; /* bytes in message */ 752 uint16 message_seq; /* DTLS-required field */ 753 uint24 fragment_offset; /* DTLS-required field */ 754 uint24 fragment_length; /* DTLS-required field */ 755 select (HandshakeType) { 756 case client_hello: ClientHello; 757 case server_hello: ServerHello; 758 case end_of_early_data: EndOfEarlyData; 759 case hello_retry_request: HelloRetryRequest; 760 case encrypted_extensions: EncryptedExtensions; 761 case certificate_request: CertificateRequest; 762 case certificate: Certificate; 763 case certificate_verify: CertificateVerify; 764 case finished: Finished; 765 case new_session_ticket: NewSessionTicket; 766 case key_update: KeyUpdate; /* reserved */ 767 } body; 768 } Handshake; 770 The first message each side transmits in each association always has 771 message_seq = 0. Whenever a new message is generated, the 772 message_seq value is incremented by one. When a message is 773 retransmitted, the old message_seq value is re-used, i.e., not 774 incremented. From the perspective of the DTLS record layer, the 775 retransmission is a new record. This record will have a new 776 DTLSPlaintext.sequence_number value. 778 DTLS implementations maintain (at least notionally) a 779 next_receive_seq counter. This counter is initially set to zero. 780 When a handshake message is received, if its message_seq value 781 matches next_receive_seq, next_receive_seq is incremented and the 782 message is processed. If the sequence number is less than 783 next_receive_seq, the message MUST be discarded. If the sequence 784 number is greater than next_receive_seq, the implementation SHOULD 785 queue the message but MAY discard it. (This is a simple space/ 786 bandwidth tradeoff). 788 In addition to the handshake messages that are deprecated by the TLS 789 1.3 specification DTLS 1.3 furthermore deprecates the 790 HelloVerifyRequest message originally defined in DTLS 1.0. DTLS 791 1.3-compliant implements MUST NOT use the HelloVerifyRequest to 792 execute a return-routability check. A dual-stack DTLS 1.2/DTLS 1.3 793 client MUST, however, be prepared to interact with a DTLS 1.2 server. 795 A DTLS 1.3 MUST NOT use the KeyUpdate message to change keying 796 material used for the protection of traffic data. Instead the epoch 797 field is used, which is explained in Section 6.1. 799 5.3. ClientHello Message 801 The format of the ClientHello used by a DTLS 1.3 client differs from 802 the TLS 1.3 ClientHello format as shown below. 804 uint16 ProtocolVersion; 805 opaque Random[32]; 807 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 809 struct { 810 ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2 811 Random random; 812 opaque legacy_session_id<0..32>; 813 opaque legacy_cookie<0..2^8-1>; // DTLS 814 CipherSuite cipher_suites<2..2^16-2>; 815 opaque legacy_compression_methods<1..2^8-1>; 816 Extension extensions<0..2^16-1>; 817 } ClientHello; 819 legacy_version: In previous versions of DTLS, this field was used 820 for version negotiation and represented the highest version number 821 supported by the client. Experience has shown that many servers 822 do not properly implement version negotiation, leading to "version 823 intolerance" in which the server rejects an otherwise acceptable 824 ClientHello with a version number higher than it supports. In 825 DTLS 1.3, the client indicates its version preferences in the 826 "supported_versions" extension (see Section 4.2.1 of 827 [I-D.ietf-tls-tls13]) and the legacy_version field MUST be set to 828 {254, 253}, which was the version number for DTLS 1.2. 830 random: Same as for TLS 1.3 832 legacy_session_id: Same as for TLS 1.3 834 legacy_cookie: A DTLS 1.3-only client MUST set the legacy_cookie 835 field to zero length. 837 cipher_suites: Same as for TLS 1.3 839 legacy_compression_methods: Same as for TLS 1.3 841 extensions: Same as for TLS 1.3 843 5.4. Handshake Message Fragmentation and Reassembly 845 Each DTLS message MUST fit within a single transport layer datagram. 846 However, handshake messages are potentially bigger than the maximum 847 record size. Therefore, DTLS provides a mechanism for fragmenting a 848 handshake message over a number of records, each of which can be 849 transmitted separately, thus avoiding IP fragmentation. 851 When transmitting the handshake message, the sender divides the 852 message into a series of N contiguous data ranges. These ranges MUST 853 NOT be larger than the maximum handshake fragment size and MUST 854 jointly contain the entire handshake message. The ranges MUST NOT 855 overlap. The sender then creates N handshake messages, all with the 856 same message_seq value as the original handshake message. Each new 857 message is labeled with the fragment_offset (the number of bytes 858 contained in previous fragments) and the fragment_length (the length 859 of this fragment). The length field in all messages is the same as 860 the length field of the original message. An unfragmented message is 861 a degenerate case with fragment_offset=0 and fragment_length=length. 863 When a DTLS implementation receives a handshake message fragment, it 864 MUST buffer it until it has the entire handshake message. DTLS 865 implementations MUST be able to handle overlapping fragment ranges. 866 This allows senders to retransmit handshake messages with smaller 867 fragment sizes if the PMTU estimate changes. 869 Note that as with TLS, multiple handshake messages may be placed in 870 the same DTLS record, provided that there is room and that they are 871 part of the same flight. Thus, there are two acceptable ways to pack 872 two DTLS messages into the same datagram: in the same record or in 873 separate records. 875 5.5. DTLS Handshake Flights 877 DTLS messages are grouped into a series of message flights, according 878 to the diagrams below. 880 Client Server 882 ClientHello +----------+ 883 + key_share* | Flight 1 | 884 + pre_shared_key* --------> +----------+ 886 +----------+ 887 <-------- HelloRetryRequest | Flight 2 | 888 + cookie +----------+ 890 ClientHello +----------+ 891 + key_share* | Flight 3 | 892 + pre_shared_key* --------> +----------+ 893 + cookie 895 ServerHello 896 + key_share* 897 + pre_shared_key* +----------+ 898 {EncryptedExtensions} | Flight 4 | 899 {CertificateRequest*} +----------+ 900 {Certificate*} 901 {CertificateVerify*} 902 <-------- {Finished} 903 [Application Data*] 905 {Certificate*} +----------+ 906 {CertificateVerify*} | Flight 5 | 907 {Finished} --------> +----------+ 908 [Application Data] 910 +----------+ 911 <-------- [Ack] | Flight 6 | 912 [Application Data*] +----------+ 914 [Application Data] <-------> [Application Data] 916 Figure 3: Message Flights for full DTLS Handshake (with Cookie 917 Exchange) 919 ClientHello +----------+ 920 + pre_shared_key | Flight 1 | 921 + key_share* --------> +----------+ 923 ServerHello 924 + pre_shared_key +----------+ 925 + key_share* | Flight 2 | 926 {EncryptedExtensions} +----------+ 927 <-------- {Finished} 928 [Application Data*] 929 +----------+ 930 {Finished} --------> | Flight 3 | 931 [Application Data*] +----------+ 933 +----------+ 934 <-------- [Ack] | Flight 4 | 935 [Application Data*] +----------+ 937 [Application Data] <-------> [Application Data] 939 Figure 4: Message Flights for Resumption and PSK Handshake (without 940 Cookie Exchange) 942 Client Server 944 ClientHello 945 + early_data 946 + psk_key_exchange_modes +----------+ 947 + key_share* | Flight 1 | 948 + pre_shared_key +----------+ 949 (Application Data*) --------> 951 ServerHello 952 + pre_shared_key 953 + key_share* +----------+ 954 {EncryptedExtensions} | Flight 2 | 955 {Finished} +----------+ 956 <-------- [Application Data*] 958 +----------+ 959 (EndOfEarlyData) | Flight 3 | 960 {Finished} --------> +----------+ 961 [Application Data*] 962 +----------+ 963 <-------- [Ack] | Flight 4 | 964 [Application Data*] +----------+ 966 [Application Data] <-------> [Application Data] 968 Figure 5: Message Flights for the Zero-RTT Handshake 970 Client Server 972 +----------+ 973 <-------- [NewSessionTicket] | Flight 1 | 974 +----------+ 976 +----------+ 977 [Ack] --------> | Flight 2 | 978 +----------+ 980 Figure 6: Message Flights for New Session Ticket Message 982 Note: The application data sent by the client is not included in the 983 timeout and retransmission calculation. 985 5.6. Timeout and Retransmission 987 5.6.1. State Machine 989 DTLS uses a simple timeout and retransmission scheme with the state 990 machine shown in Figure 7. Because DTLS clients send the first 991 message (ClientHello), they start in the PREPARING state. DTLS 992 servers start in the WAITING state, but with empty buffers and no 993 retransmit timer. 995 +-----------+ 996 | PREPARING | 997 +----------> | | 998 | | | 999 | +-----------+ 1000 | | 1001 | | Buffer next flight 1002 | | 1003 | \|/ 1004 | +-----------+ 1005 | | | 1006 | | SENDING |<------------------+ 1007 | | | | 1008 | +-----------+ | 1009 Receive | | | 1010 next | | Send flight or partial | 1011 flight | | flight | 1012 | +---------------+ | 1013 | | | Set retransmit timer | 1014 | | \|/ | 1015 | | +-----------+ | 1016 | | | | | 1017 +--)---------| WAITING |-------------------+ 1018 | | +----->| | Timer expires | 1019 | | | +-----------+ | 1020 | | | | | | | 1021 | | | | | | | 1022 | | +----------+ | +--------------------+ 1023 | | Receive record | Read retransmit or ACK 1024 Receive | | Send ACK | 1025 last | | | 1026 flight | | | Receive ACK 1027 | | | for last flight 1028 \|/\|/ | 1029 | 1030 +-----------+ | 1031 | | <---------+ 1032 | FINISHED | 1033 | | 1034 +-----------+ 1035 | /|\ 1036 | | 1037 | | 1038 +---+ 1040 Server read retransmit 1041 Retransmit ACK 1043 Figure 7: DTLS Timeout and Retransmission State Machine 1045 The state machine has three basic states. 1047 In the PREPARING state, the implementation does whatever computations 1048 are necessary to prepare the next flight of messages. It then 1049 buffers them up for transmission (emptying the buffer first) and 1050 enters the SENDING state. 1052 In the SENDING state, the implementation transmits the buffered 1053 flight of messages. If the implementation has received one or more 1054 ACKs Section 7 from the peer, then it SHOULD omit any messages or 1055 message fragments which have already been ACKed. Once the messages 1056 have been sent, the implementation then enters the FINISHED state if 1057 this is the last flight in the handshake. Or, if the implementation 1058 expects to receive more messages, it sets a retransmit timer and then 1059 enters the WAITING state. 1061 There are four ways to exit the WAITING state: 1063 1. The retransmit timer expires: the implementation transitions to 1064 the SENDING state, where it retransmits the flight, resets the 1065 retransmit timer, and returns to the WAITING state. 1067 2. The implementation reads a ACK from the peer: upon receiving an 1068 ACK for a partial flight (as mentioned in Section 7.1, the 1069 implementation transitions to the SENDING state, where it 1070 retransmits the unacked portion of the flight, resets the 1071 retransmit timer, and returns to the WAITING state. Upon 1072 receiving an ACK for a complete flight, the implementation 1073 cancels all retransmissions and either remains in WAITING, or, if 1074 the ACK was for the final flight, transitions to FINISHED. 1076 3. The implementation reads a retransmitted flight from the peer: 1077 the implementation transitions to the SENDING state, where it 1078 retransmits the flight, resets the retransmit timer, and returns 1079 to the WAITING state. The rationale here is that the receipt of 1080 a duplicate message is the likely result of timer expiry on the 1081 peer and therefore suggests that part of one's previous flight 1082 was lost. 1084 4. The implementation receives some or all next flight of messages: 1085 if this is the final flight of messages, the implementation 1086 transitions to FINISHED. If the implementation needs to send a 1087 new flight, it transitions to the PREPARING state. Partial reads 1088 (whether partial messages or only some of the messages in the 1089 flight) may also trigger the implementation to send an ACK, as 1090 described in Section 7.1. 1092 Because DTLS clients send the first message (ClientHello), they start 1093 in the PREPARING state. DTLS servers start in the WAITING state, but 1094 with empty buffers and no retransmit timer. 1096 In addition, for at least twice the default Maximum Segment Lifetime 1097 (MSL) defined for [RFC0793], when in the FINISHED state, the server 1098 MUST respond to retransmission of the client's second flight with a 1099 retransmit of its ACK. 1101 Note that because of packet loss, it is possible for one side to be 1102 sending application data even though the other side has not received 1103 the first side's Finished message. Implementations MUST either 1104 discard or buffer all application data packets for the new epoch 1105 until they have received the Finished message for that epoch. 1106 Implementations MAY treat receipt of application data with a new 1107 epoch prior to receipt of the corresponding Finished message as 1108 evidence of reordering or packet loss and retransmit their final 1109 flight immediately, shortcutting the retransmission timer. 1111 5.6.2. Timer Values 1113 Though timer values are the choice of the implementation, mishandling 1114 of the timer can lead to serious congestion problems; for example, if 1115 many instances of a DTLS time out early and retransmit too quickly on 1116 a congested link. Implementations SHOULD use an initial timer value 1117 of 100 msec (the minimum defined in RFC 6298 [RFC6298]) and double 1118 the value at each retransmission, up to no less than the RFC 6298 1119 maximum of 60 seconds. Application specific profiles, such as those 1120 used for the Internet of Things environment, may recommend longer 1121 timer values. Note that we recommend a 100 msec timer rather than 1122 the 3-second RFC 6298 default in order to improve latency for time- 1123 sensitive applications. Because DTLS only uses retransmission for 1124 handshake and not dataflow, the effect on congestion should be 1125 minimal. 1127 Implementations SHOULD retain the current timer value until a 1128 transmission without loss occurs, at which time the value may be 1129 reset to the initial value. After a long period of idleness, no less 1130 than 10 times the current timer value, implementations may reset the 1131 timer to the initial value. One situation where this might occur is 1132 when a rehandshake is used after substantial data transfer. 1134 5.7. CertificateVerify and Finished Messages 1136 CertificateVerify and Finished messages have the same format as in 1137 TLS 1.3. Hash calculations include entire handshake messages, 1138 including DTLS-specific fields: message_seq, fragment_offset, and 1139 fragment_length. However, in order to remove sensitivity to 1140 handshake message fragmentation, the CertificateVerify and the 1141 Finished messages MUST be computed as if each handshake message had 1142 been sent as a single fragment following the algorithm described in 1143 Section 4.4.3 and Section 4.4.4 of [I-D.ietf-tls-tls13], 1144 respectively. 1146 5.8. Alert Messages 1148 Note that Alert messages are not retransmitted at all, even when they 1149 occur in the context of a handshake. However, a DTLS implementation 1150 which would ordinarily issue an alert SHOULD generate a new alert 1151 message if the offending record is received again (e.g., as a 1152 retransmitted handshake message). Implementations SHOULD detect when 1153 a peer is persistently sending bad messages and terminate the local 1154 connection state after such misbehavior is detected. 1156 5.9. Establishing New Associations with Existing Parameters 1158 If a DTLS client-server pair is configured in such a way that 1159 repeated connections happen on the same host/port quartet, then it is 1160 possible that a client will silently abandon one connection and then 1161 initiate another with the same parameters (e.g., after a reboot). 1162 This will appear to the server as a new handshake with epoch=0. In 1163 cases where a server believes it has an existing association on a 1164 given host/port quartet and it receives an epoch=0 ClientHello, it 1165 SHOULD proceed with a new handshake but MUST NOT destroy the existing 1166 association until the client has demonstrated reachability either by 1167 completing a cookie exchange or by completing a complete handshake 1168 including delivering a verifiable Finished message. After a correct 1169 Finished message is received, the server MUST abandon the previous 1170 association to avoid confusion between two valid associations with 1171 overlapping epochs. The reachability requirement prevents off-path/ 1172 blind attackers from destroying associations merely by sending forged 1173 ClientHellos. 1175 6. Example of Handshake with Timeout and Retransmission 1177 The following is an example of a handshake with lost packets and 1178 retransmissions. 1180 Client Server 1181 ------ ------ 1183 Record 0 --------> 1184 ClientHello 1185 (message_seq=0) 1186 +cookie 1188 X<----- Record 0 1189 (lost) ServerHello 1190 (message_seq=1) 1191 EncryptedExtensions 1192 (message_seq=2) 1193 Certificate 1194 (message_seq=3) 1196 <-------- Record 1 1197 CertificateVerify 1198 (message_seq=4) 1199 Finished 1200 (message_seq=5) 1202 Record 1 --------> 1203 ACK [1] 1205 <-------- Record 2 1206 ServerHello 1207 (message_seq=1) 1208 EncryptedExtensions 1209 (message_seq=2) 1210 Certificate 1211 (message_seq=3) 1213 Record 2 --------> 1214 Certificate 1215 (message_seq=2) 1216 CertificateVerify 1217 (message_seq=3) 1218 Finished 1219 (message_seq=4) 1221 <-------- Record 3 1222 ACK [2] 1224 Figure 8: Example DTLS Exchange illustrating Message Loss 1226 6.1. Epoch Values and Rekeying 1228 A recipient of a DTLS message needs to select the correct keying 1229 material in order to process an incoming message. With the 1230 possibility of message loss and re-order an identifier is needed to 1231 determine which cipher state has been used to protect the record 1232 payload. The epoch value fulfills this role in DTLS. In addition to 1233 the key derivation steps described in Section 7 of 1234 [I-D.ietf-tls-tls13] triggered by the states during the handshake a 1235 sender may want to rekey at any time during the lifetime of the 1236 connection and has to have a way to indicate that it is updating its 1237 sending cryptographic keys. 1239 This version of DTLS assigns dedicated epoch values to messages in 1240 the protocol exchange to allow identification of the correct cipher 1241 state: 1243 - epoch value (0) is used with unencrypted messages. There are 1244 three unencrypted messages in DTLS, namely ClientHello, 1245 ServerHello, and HelloRetryRequest. 1247 - epoch value (1) is used for messages protected using keys derived 1248 from early_traffic_secret. This includes early data sent by the 1249 client and the EndOfEarlyData message. 1251 - epoch value (2) is used for messages protected using keys derived 1252 from the handshake_traffic_secret. Messages transmitted during 1253 the initial handshake, such as EncryptedExtensions, 1254 CertificateRequest, Certificate, CertificateVerify, and Finished 1255 belong to this category. Note, however, post-handshake are 1256 protected under the appropriate application traffic key and are 1257 not included in this category. 1259 - epoch value (3) is used for payloads protected using keys derived 1260 from the initial traffic_secret_0. This may include handshake 1261 messages, such as post-handshake messages (e.g., a 1262 NewSessionTicket message). 1264 - epoch value (4 to 2^16-1) is used for payloads protected using 1265 keys from the traffic_secret_N (N>0). 1267 Using these reserved epoch values a receiver knows what cipher state 1268 has been used to encrypt and integrity protect a message. 1269 Implementations that receive a payload with an epoch value for which 1270 no corresponding cipher state can be determined MUST generate a 1271 "unexpected_message" alert. For example, client incorrectly uses 1272 epoch value 5 when sending early application data in a 0-RTT 1273 exchange. A server will not be able to compute the appropriate keys 1274 and will therefore have to respond with an alert. 1276 Increasing the epoch value by a sender (starting with value 4 1277 upwards) corresponds semantically to rekeying using the KeyUpdate 1278 message in TLS 1.3. Instead of utilizing an dedicated message in 1279 DTLS 1.3 the sender uses an increase in the epoch value to signal 1280 rekeying. Hence, a sender that decides to increment the epoch value 1281 MUST send all its traffic using the next generation of keys, computed 1282 as described in Section 7.2 of [I-D.ietf-tls-tls13]. Upon receiving 1283 a payload with such a new epoch value, the receiver MUST update their 1284 receiving keys and if they have not already updated their sending 1285 state up to or past the then current receiving generation MUST send 1286 messages with the new epoch value prior to sending any other 1287 messages. For epoch values lower than 4 the key schedule described 1288 in Section 7.1 of [I-D.ietf-tls-tls13] is applicable. As a 1289 difference to the functionality of the KeyUpdate in TLS 1.3 the 1290 sender forces the receiver to increase the epoch value for outgoing 1291 data as well. 1293 Note that epoch values do not wrap. If a DTLS implementation would 1294 need to wrap the epoch value, it MUST terminate the connection. 1296 The traffic key calculation is described in Section 7.3 of 1297 [I-D.ietf-tls-tls13]. 1299 Figure 9 illustrates the epoch values in an example DTLS handshake. 1301 Client Server 1302 ------ ------ 1304 ClientHello 1305 (epoch=0) 1306 --------> 1308 <-------- HelloRetryRequest 1309 (epoch=0) 1311 ClientHello --------> 1312 (epoch=0) 1314 <-------- ServerHello 1315 (epoch=0) 1316 {EncryptedExtensions} 1317 (epoch=2) 1318 {Certificate} 1319 (epoch=2) 1320 {CertificateVerify} 1321 (epoch=2) 1322 {Finished} 1323 (epoch=2) 1325 {Certificate} --------> 1326 (epoch=2) 1327 {CertificateVerify} 1328 (epoch=2) 1329 {Finished} 1330 (epoch=2) 1332 <-------- [Ack] 1333 (epoch=3) 1335 [Application Data] --------> 1336 (epoch=3) 1338 <-------- [Application Data] 1339 (epoch=3) 1341 Some time later ... 1342 (Post-Handshake Message Exchange) 1344 <-------- [NewSessionTicket] 1345 (epoch=3) 1347 [Ack] --------> 1348 (epoch=3) 1350 Some time later ... 1351 (Rekeying) 1353 <-------- [Application Data] 1354 (epoch=4) 1355 [Application Data] --------> 1356 (epoch=4) 1358 Figure 9: Example DTLS Exchange with Epoch Information 1360 7. ACK Message 1362 The ACK message is used by an endpoint to indicate handshake- 1363 containing the TLS records it has received from the other side. ACK 1364 is not a handshake message but is rather a separate content type, 1365 with code point TBD. This avoids it consuming space in the handshake 1366 message sequence. Note that ACKs can still be piggybacked on the 1367 same UDP datagram as handshake records. 1369 struct { 1370 uint64 record_numbers<8..2^16-1>; 1371 } ACK; 1373 record_numbers: a list of the records containing handshake messages 1374 in the current flight which the endpoint has received, in 1375 numerically increasing order. ACKs only cover the current 1376 outstanding flight (this is possible because DTLS is generally a 1377 lockstep protocol). Thus, an ACK from the server would not cover 1378 both the ClientHello and the client's Certificate. 1379 Implementations can accomplish this by clearing their ACK list 1380 upon receiving the start of the next flight. 1382 ACK records MUST be sent with an epoch that is equal to or higher 1383 than the record which is being acknowledged. Implementations SHOULD 1384 simply use the current key. 1386 7.1. Sending ACKs 1388 When an implementation receives a partial flight, it SHOULD generate 1389 an ACK that covers the messages from that flight which it has 1390 received so far. Implementations have some discretion about when to 1391 generate ACKs, but it is RECOMMENDED that they do so under two 1392 circumstances: 1394 - When they receive a message or fragment which is out of order, 1395 either because it is not the next expected message or because it 1396 is not the next piece of the current message. Implementations 1397 MUST NOT send ACKs for handshake messages which they discard as 1398 out-of-order, because otherwise those messages will not be 1399 retransmitted. 1401 - When they have received part of a flight and do not immediately 1402 receive the rest of the flight (which may be in the same UDP 1403 datagram). A reasonable approach here is to set a timer for 1/4 1404 the current retransmit timer value when the first record in the 1405 flight is received and then send an ACK when that timer expires. 1407 In addition, implementations MUST send ACKs upon receiving all of any 1408 flight which they do not respond to with their own messages. 1409 Specifically, this means the client's final flight of the main 1410 handshake and the server's transmission of the NewSessionTicket. 1411 ACKs SHOULD NOT be sent for other complete flights because they are 1412 implicitly acknowledged by the receipt of the next flight, which 1413 generally immediately follows the flight. 1415 ACKs MUST NOT be sent for other records of any content type other 1416 than handshake. 1418 7.2. Receiving ACKs 1420 When an implementation receives an ACK, it SHOULD record that the 1421 messages or message fragments sent in the records being ACKed were 1422 received and omit them from any future retransmissions. Upon receipt 1423 of an ACK for only some messages from a flight, an implementation 1424 SHOULD retransmit the remaining messages or fragments. Note that 1425 this requires implementations to track which messages appear in which 1426 records. Once all the messages in a flight have been acknowledged, 1427 the implemenation MUST cancel all retransmissions of that flight. As 1428 noted above, the receipt of any packet responding to a given flight 1429 MUST be taken as an implicit ACK for the entire flight. 1431 8. Application Data Protocol 1433 Application data messages are carried by the record layer and are 1434 fragmented and encrypted based on the current connection state. The 1435 messages are treated as transparent data to the record layer. 1437 9. Security Considerations 1439 Security issues are discussed primarily in [I-D.ietf-tls-tls13]. 1441 The primary additional security consideration raised by DTLS is that 1442 of denial of service. DTLS includes a cookie exchange designed to 1443 protect against denial of service. However, implementations that do 1444 not use this cookie exchange are still vulnerable to DoS. In 1445 particular, DTLS servers that do not use the cookie exchange may be 1446 used as attack amplifiers even if they themselves are not 1447 experiencing DoS. Therefore, DTLS servers SHOULD use the cookie 1448 exchange unless there is good reason to believe that amplification is 1449 not a threat in their environment. Clients MUST be prepared to do a 1450 cookie exchange with every handshake. 1452 Unlike TLS implementations, DTLS implementations SHOULD NOT respond 1453 to invalid records by terminating the connection. 1455 10. Changes to DTLS 1.2 1457 Since TLS 1.3 introduces a large number of changes to TLS 1.2, the 1458 list of changes from DTLS 1.2 to DTLS 1.3 is equally large. For this 1459 reason this section focuses on the most important changes only. 1461 - New handshake pattern, which leads to a shorter message exchange 1463 - Support for AEAD-only ciphers 1465 - HelloRetryRequest of TLS 1.3 used instead of HelloVerifyRequest 1466 - More flexible ciphersuite negotiation 1468 - New session resumption mechanism 1470 - PSK authentication redefined 1472 - New key derivation hierarchy utilizing a new key derivation 1473 construct 1475 - Removed support for weaker and older cryptographic algorithms 1477 - Improved version negotation 1479 11. IANA Considerations 1481 IANA is requested to allocate a new value in the TLS ContentType 1482 Registry for the ACK message defined in Section 7. 1484 12. References 1486 12.1. Normative References 1488 [I-D.ietf-tls-tls13] 1489 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1490 Version 1.3", draft-ietf-tls-tls13-21 (work in progress), 1491 July 2017. 1493 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1494 DOI 10.17487/RFC0768, August 1980, 1495 . 1497 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1498 RFC 793, DOI 10.17487/RFC0793, September 1981, 1499 . 1501 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1502 DOI 10.17487/RFC1191, November 1990, 1503 . 1505 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1506 Requirement Levels", BCP 14, RFC 2119, 1507 DOI 10.17487/RFC2119, March 1997, 1508 . 1510 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1511 Control Message Protocol (ICMPv6) for the Internet 1512 Protocol Version 6 (IPv6) Specification", RFC 4443, 1513 DOI 10.17487/RFC4443, March 2006, 1514 . 1516 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1517 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1518 . 1520 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 1521 "Computing TCP's Retransmission Timer", RFC 6298, 1522 DOI 10.17487/RFC6298, June 2011, 1523 . 1525 12.2. Informative References 1527 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 1528 Protocol", RFC 2522, DOI 10.17487/RFC2522, March 1999, 1529 . 1531 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1532 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1533 . 1535 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1536 Congestion Control Protocol (DCCP)", RFC 4340, 1537 DOI 10.17487/RFC4340, March 2006, 1538 . 1540 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1541 (TLS) Protocol Version 1.1", RFC 4346, 1542 DOI 10.17487/RFC4346, April 2006, 1543 . 1545 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1546 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 1547 . 1549 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 1550 the Datagram Congestion Control Protocol (DCCP)", 1551 RFC 5238, DOI 10.17487/RFC5238, May 2008, 1552 . 1554 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1555 (TLS) Protocol Version 1.2", RFC 5246, 1556 DOI 10.17487/RFC5246, August 2008, 1557 . 1559 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1560 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1561 RFC 5996, DOI 10.17487/RFC5996, September 2010, 1562 . 1564 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1565 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1566 January 2012, . 1568 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1569 "Recommendations for Secure Use of Transport Layer 1570 Security (TLS) and Datagram Transport Layer Security 1571 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1572 2015, . 1574 12.3. URIs 1576 [1] mailto:tls@ietf.org 1578 Appendix A. History 1580 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 1582 IETF Drafts draft-02 - Restructured the ACK to contain a list of 1583 packets and also be a record rather than a handshake message. 1585 draft-00 - First IETF Draft 1587 Personal Drafts draft-01 - Alignment with version -19 of the TLS 1.3 1588 specification 1590 draft-00 1592 - Initial version using TLS 1.3 as a baseline. 1594 - Use of epoch values instead of KeyUpdate message 1596 - Use of cookie extension instead of cookie field in ClientHello and 1597 HelloVerifyRequest messages 1599 - Added ACK message 1601 - Text about sequence number handling 1603 Appendix B. Working Group Information 1605 The discussion list for the IETF TLS working group is located at the 1606 e-mail address tls@ietf.org [1]. Information on the group and 1607 information on how to subscribe to the list is at 1608 https://www1.ietf.org/mailman/listinfo/tls 1610 Archives of the list can be found at: https://www.ietf.org/mail- 1611 archive/web/tls/current/index.html 1613 Appendix C. Contributors 1615 Many people have contributed to previous DTLS versions and they are 1616 acknowledged in prior versions of DTLS specifications. 1618 For this version of the document we would like to thank: 1620 * Ilari Liusvaara 1621 Independent 1622 ilariliusvaara@welho.com 1624 * Martin Thomson 1625 Mozilla 1626 martin.thomson@gmail.com 1628 Authors' Addresses 1630 Eric Rescorla 1631 RTFM, Inc. 1633 EMail: ekr@rtfm.com 1635 Hannes Tschofenig 1636 ARM Limited 1638 EMail: hannes.tschofenig@arm.com 1640 Nagendra Modadugu 1641 Google, Inc. 1643 EMail: nagendra@cs.stanford.edu