idnits 2.17.1 draft-rescorla-tls-dtls13-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC6347, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 26, 2016) is 2739 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: '1' on line 1449 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-18 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS E. Rescorla 3 Internet-Draft RTFM, Inc. 4 Obsoletes: 6347 (if approved) H. Tschofenig 5 Intended status: Standards Track ARM Limited 6 Expires: April 29, 2017 October 26, 2016 8 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 9 draft-rescorla-tls-dtls13-00 11 Abstract 13 This document specifies Version 1.3 of the Datagram Transport Layer 14 Security (DTLS) protocol. DTLS 1.3 allows client/server applications 15 to communicate over the Internet in a way that is designed to prevent 16 eavesdropping, tampering, and message forgery. 18 The DTLS 1.3 protocol is intentionally based on the Transport Layer 19 Security (TLS) 1.3 protocol and provides equivalent security 20 guarantees. Datagram semantics of the underlying transport are 21 preserved by the DTLS protocol. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 29, 2017. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 71 3. DTLS Design Rational and Overview . . . . . . . . . . . . . . 4 72 3.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.1.1. Reordering . . . . . . . . . . . . . . . . . . . . . 6 74 3.1.2. Message Size . . . . . . . . . . . . . . . . . . . . 6 75 3.2. Replay Detection . . . . . . . . . . . . . . . . . . . . 6 76 4. The DTLS Record Layer . . . . . . . . . . . . . . . . . . . . 7 77 4.1. Transport Layer Mapping . . . . . . . . . . . . . . . . . 8 78 4.2. PMTU Issues . . . . . . . . . . . . . . . . . . . . . . . 9 79 4.3. Record Payload Protection . . . . . . . . . . . . . . . . 11 80 4.3.1. Anti-Replay . . . . . . . . . . . . . . . . . . . . . 11 81 4.3.2. Handling Invalid Records . . . . . . . . . . . . . . 11 82 5. The DTLS Handshake Protocol . . . . . . . . . . . . . . . . . 12 83 5.1. Denial-of-Service Countermeasures . . . . . . . . . . . . 12 84 5.2. DTLS Handshake Message Format . . . . . . . . . . . . . . 15 85 5.3. ACK Message . . . . . . . . . . . . . . . . . . . . . . . 19 86 5.4. Handshake Message Fragmentation and Reassembly . . . . . 19 87 5.5. Timeout and Retransmission . . . . . . . . . . . . . . . 20 88 5.5.1. State Machine . . . . . . . . . . . . . . . . . . . . 24 89 5.5.2. Timer Values . . . . . . . . . . . . . . . . . . . . 27 90 5.6. CertificateVerify and Finished Messages . . . . . . . . . 28 91 5.7. Alert Messages . . . . . . . . . . . . . . . . . . . . . 28 92 5.8. Establishing New Associations with Existing Parameters . 28 93 5.9. Epoch Values and Rekeying . . . . . . . . . . . . . . . . 28 94 6. Application Data Protocol . . . . . . . . . . . . . . . . . . 30 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 96 8. Changes to DTLS 1.2 . . . . . . . . . . . . . . . . . . . . . 30 97 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 31 98 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 100 11.1. Normative References . . . . . . . . . . . . . . . . . . 31 101 11.2. Informative References . . . . . . . . . . . . . . . . . 32 102 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 34 103 Appendix B. Working Group Information . . . . . . . . . . . . . 34 104 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 34 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 107 1. Introduction 109 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH 111 The source for this draft is maintained in GitHub. Suggested changes 112 should be submitted as pull requests at https://github.com/tlswg/ 113 dtls13-spec. Instructions are on that page as well. Editorial 114 changes can be managed in GitHub, but any substantive change should 115 be discussed on the TLS mailing list. 117 The primary goal of the TLS protocol is to provide privacy and data 118 integrity between two communicating peers. The TLS protocol is 119 composed of two layers: the TLS Record Protocol and the TLS Handshake 120 Protocol. However, TLS must run over a reliable transport channel - 121 typically TCP [RFC0793]. 123 There are applications that utilize UDP as a transport and to offer 124 communication security protection for those applications the Datagram 125 Transport Layer Security (DTLS) protocol has been designed. DTLS is 126 deliberately designed to be as similar to TLS as possible, both to 127 minimize new security invention and to maximize the amount of code 128 and infrastructure reuse. 130 DTLS 1.0 was originally defined as a delta from TLS 1.1 and DTLS 1.2 131 was defined as a series of deltas to TLS 1.2. There is no DTLS 1.1; 132 that version number was skipped in order to harmonize version numbers 133 with TLS. This specification describes the most current version of 134 the DTLS protocol aligning with the efforts around TLS 1.3. 136 Implementations that speak both DTLS 1.2 and DTLS 1.3 can 137 interoperate with those that speak only DTLS 1.2 (using DTLS 1.2 of 138 course), just as TLS 1.3 implementations can interoperate with TLS 139 1.2 (see Appendix C of [I-D.ietf-tls-tls13] for details). While 140 backwards compatibility with DTLS 1.0 is possible the use of DTLS 1.0 141 is not recommended as explained in Section 3.1.2 of RFC 7525 142 [RFC7525]. 144 2. Conventions and Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 148 "OPTIONAL" in this document are to be interpreted as described in RFC 149 2119 [RFC2119]. 151 The following terms are used: 153 - client: The endpoint initiating the TLS connection. 155 - connection: A transport-layer connection between two endpoints. 157 - endpoint: Either the client or server of the connection. 159 - handshake: An initial negotiation between client and server that 160 establishes the parameters of their transactions. 162 - peer: An endpoint. When discussing a particular endpoint, "peer" 163 refers to the endpoint that is remote to the primary subject of 164 discussion. 166 - receiver: An endpoint that is receiving records. 168 - sender: An endpoint that is transmitting records. 170 - session: An association between a client and a server resulting 171 from a handshake. 173 - server: The endpoint which did not initiate the TLS connection. 175 The reader is assumed to be familiar with the TLS 1.3 specification 176 since this document defined as a delta from TLS 1.3. 178 3. DTLS Design Rational and Overview 180 The basic design philosophy of DTLS is to construct "TLS over 181 datagram transport". Datagram transport does not require or provide 182 reliable or in-order delivery of data. The DTLS protocol preserves 183 this property for application data. Applications such as media 184 streaming, Internet telephony, and online gaming use datagram 185 transport for communication due to the delay-sensitive nature of 186 transported data. The behavior of such applications is unchanged 187 when the DTLS protocol is used to secure communication, since the 188 DTLS protocol does not compensate for lost or re-ordered data 189 traffic. 191 TLS cannot be used directly in datagram environments for the 192 following five reasons: 194 1. TLS does not allow independent decryption of individual records. 195 Because the integrity check indirectly depends on a sequence 196 number, if record N is not received, then the integrity check on 197 record N+1 will be based on the wrong sequence number and thus 198 will fail. DTLS solves this problem by adding explicit sequence 199 numbers. 201 2. The TLS handshake is a lock-step cryptographic handshake. 202 Messages must be transmitted and received in a defined order; any 203 other order is an error. Clearly, this is incompatible with 204 reordering and message loss. 206 3. Not all TLS 1.3 handshake messages (such as the NewSessionTicket 207 message) are acknowledged. Hence, a new acknowledgement message 208 has to be added to detect message loss. 210 4. Handshake messages are potentially larger than any given 211 datagram, thus creating the problem of IP fragmentation. 213 5. Datagram transport protocols, like UDP, are more vulnerable to 214 denial of service attacks and require a return-routability check 215 with the help of cookies to be integrated into the handshake. A 216 detailed discussion of countermeasures can be found in 217 Section 5.1. 219 3.1. Packet Loss 221 DTLS uses a simple retransmission timer to handle packet loss. 222 Figure 1 demonstrates the basic concept, using the first phase of the 223 DTLS handshake: 225 Client Server 226 ------ ------ 227 ClientHello ------> 229 X<-- HelloRetryRequest 230 (lost) 232 [Timer Expires] 234 ClientHello ------> 235 (retransmit) 237 Figure 1: DTLS Retransmission Example. 239 Once the client has transmitted the ClientHello message, it expects 240 to see a HelloRetryRequest from the server. However, if the server's 241 message is lost, the client knows that either the ClientHello or the 242 HelloRetryRequest has been lost and retransmits. When the server 243 receives the retransmission, it knows to retransmit. 245 The server also maintains a retransmission timer and retransmits when 246 that timer expires. 248 Note that timeout and retransmission do not apply to the 249 HelloRetryRequest since this would require creating state on the 250 server. The HelloRetryRequest is designed to be small enough that it 251 will not itself be fragmented, thus avoiding concerns about 252 interleaving multiple HelloRetryRequests. 254 3.1.1. Reordering 256 In DTLS, each handshake message is assigned a specific sequence 257 number within that handshake. When a peer receives a handshake 258 message, it can quickly determine whether that message is the next 259 message it expects. If it is, then it processes it. If not, it 260 queues it for future handling once all previous messages have been 261 received. 263 3.1.2. Message Size 265 TLS and DTLS handshake messages can be quite large (in theory up to 266 2^24-1 bytes, in practice many kilobytes). By contrast, UDP 267 datagrams are often limited to less than 1500 bytes if IP 268 fragmentation is not desired. In order to compensate for this 269 limitation, each DTLS handshake message may be fragmented over 270 several DTLS records, each of which is intended to fit in a single IP 271 datagram. Each DTLS handshake message contains both a fragment 272 offset and a fragment length. Thus, a recipient in possession of all 273 bytes of a handshake message can reassemble the original unfragmented 274 message. 276 3.2. Replay Detection 278 DTLS optionally supports record replay detection. The technique used 279 is the same as in IPsec AH/ESP, by maintaining a bitmap window of 280 received records. Records that are too old to fit in the window and 281 records that have previously been received are silently discarded. 282 The replay detection feature is optional, since packet duplication is 283 not always malicious, but can also occur due to routing errors. 284 Applications may conceivably detect duplicate packets and accordingly 285 modify their data transmission strategy. 287 4. The DTLS Record Layer 289 The DTLS record layer is extremely similar to that of TLS 1.3. The 290 only change is the inclusion of an explicit epoch and sequence number 291 in the record. This sequence number allows the recipient to 292 correctly verify the TLS MAC. The DTLS record format is shown below: 294 struct { 295 ContentType type; 296 ProtocolVersion version = { 254, 253 }; 297 uint16 epoch; // DTLS-related field 298 uint48 sequence_number; // DTLS-related field 299 uint16 length; 300 opaque fragment[DTLSPlaintext.length]; 301 } DTLSPlaintext; 303 type: Identical to the type field in a TLS 1.3 record. 305 version: This specification re-uses the DTLS version 1.2 version 306 number, namely { 254, 253 }. This field is deprecated and MUST be 307 ignored for all purposes. 309 epoch: A counter value that is incremented on every cipher state 310 change. 312 sequence_number: The sequence number for this record. 314 length: Identical to the length field in a TLS 1.3 record. 316 fragment: Identical to the fragment field in a TLS 1.3 record. 318 DTLS uses an explicit sequence number, rather than an implicit one, 319 carried in the sequence_number field of the record. Sequence numbers 320 are maintained separately for each epoch, with each sequence_number 321 initially being 0 for each epoch. For instance, if a handshake 322 message from epoch 0 is retransmitted, it might have a sequence 323 number after a message from epoch 1, even if the message from epoch 1 324 was transmitted first. Note that some care needs to be taken during 325 the handshake to ensure that retransmitted messages use the right 326 epoch and keying material. 328 If several handshakes are performed in close succession, there might 329 be multiple records on the wire with the same sequence number but 330 from different cipher states. The epoch field allows recipients to 331 distinguish such packets. The epoch number is initially zero and is 332 incremented each time keying material changes and a sender aims to 333 rekey. More details are provided in Section 5.9. In order to ensure 334 that any given sequence/epoch pair is unique, implementations MUST 335 NOT allow the same epoch value to be reused within two times the TCP 336 maximum segment lifetime. 338 Note that because DTLS records may be reordered, a record from epoch 339 1 may be received after epoch 2 has begun. In general, 340 implementations SHOULD discard packets from earlier epochs, but if 341 packet loss causes noticeable problems they MAY choose to retain 342 keying material from previous epochs for up to the default MSL 343 specified for TCP [RFC0793] to allow for packet reordering. (Note 344 that the intention here is that implementers use the current guidance 345 from the IETF for MSL, not that they attempt to interrogate the MSL 346 that the system TCP stack is using.) Until the handshake has 347 completed, implementations MUST accept packets from the old epoch. 349 Conversely, it is possible for records that are protected by the 350 newly negotiated context to be received prior to the completion of a 351 handshake. For instance, the server may send its Finished message 352 and then start transmitting data. Implementations MAY either buffer 353 or discard such packets, though when DTLS is used over reliable 354 transports (e.g., SCTP), they SHOULD be buffered and processed once 355 the handshake completes. Note that TLS's restrictions on when 356 packets may be sent still apply, and the receiver treats the packets 357 as if they were sent in the right order. In particular, it is still 358 impermissible to send data prior to completion of the first 359 handshake. 361 As in TLS, implementations MUST either abandon an association or re- 362 key using a KeyUpdate message prior to allowing the sequence number 363 to wrap. 365 Implementations MUST NOT allow the epoch to wrap, but instead MUST 366 establish a new association, terminating the old association. 368 4.1. Transport Layer Mapping 370 Each DTLS record MUST fit within a single datagram. In order to 371 avoid IP fragmentation, clients of the DTLS record layer SHOULD 372 attempt to size records so that they fit within any PMTU estimates 373 obtained from the record layer. 375 Note that unlike IPsec, DTLS records do not contain any association 376 identifiers. Applications must arrange to multiplex between 377 associations. With UDP, this is presumably done with the host/port 378 number. 380 Multiple DTLS records may be placed in a single datagram. They are 381 simply encoded consecutively. The DTLS record framing is sufficient 382 to determine the boundaries. Note, however, that the first byte of 383 the datagram payload must be the beginning of a record. Records may 384 not span datagrams. 386 Some transports, such as DCCP [RFC4340] provide their own sequence 387 numbers. When carried over those transports, both the DTLS and the 388 transport sequence numbers will be present. Although this introduces 389 a small amount of inefficiency, the transport layer and DTLS sequence 390 numbers serve different purposes; therefore, for conceptual 391 simplicity, it is superior to use both sequence numbers. 393 Some transports provide congestion control for traffic carried over 394 them. If the congestion window is sufficiently narrow, DTLS 395 handshake retransmissions may be held rather than transmitted 396 immediately, potentially leading to timeouts and spurious 397 retransmission. When DTLS is used over such transports, care should 398 be taken not to overrun the likely congestion window. [RFC5238] 399 defines a mapping of DTLS to DCCP that takes these issues into 400 account. 402 4.2. PMTU Issues 404 In general, DTLS's philosophy is to leave PMTU discovery to the 405 application. However, DTLS cannot completely ignore PMTU for three 406 reasons: 408 - The DTLS record framing expands the datagram size, thus lowering 409 the effective PMTU from the application's perspective. 411 - In some implementations, the application may not directly talk to 412 the network, in which case the DTLS stack may absorb ICMP 413 [RFC1191] "Datagram Too Big" indications or ICMPv6 [RFC4443] 414 "Packet Too Big" indications. 416 - The DTLS handshake messages can exceed the PMTU. 418 In order to deal with the first two issues, the DTLS record layer 419 SHOULD behave as described below. 421 If PMTU estimates are available from the underlying transport 422 protocol, they should be made available to upper layer protocols. 423 In particular: 425 - For DTLS over UDP, the upper layer protocol SHOULD be allowed to 426 obtain the PMTU estimate maintained in the IP layer. 428 - For DTLS over DCCP, the upper layer protocol SHOULD be allowed to 429 obtain the current estimate of the PMTU. 431 - For DTLS over TCP or SCTP, which automatically fragment and 432 reassemble datagrams, there is no PMTU limitation. However, the 433 upper layer protocol MUST NOT write any record that exceeds the 434 maximum record size of 2^14 bytes. 436 The DTLS record layer SHOULD allow the upper layer protocol to 437 discover the amount of record expansion expected by the DTLS 438 processing. 440 If there is a transport protocol indication (either via ICMP or 441 via a refusal to send the datagram as in Section 14 of [RFC4340]), 442 then the DTLS record layer MUST inform the upper layer protocol of 443 the error. 445 The DTLS record layer SHOULD NOT interfere with upper layer 446 protocols performing PMTU discovery, whether via [RFC1191] or 447 [RFC4821] mechanisms. In particular: 449 - Where allowed by the underlying transport protocol, the upper 450 layer protocol SHOULD be allowed to set the state of the DF bit 451 (in IPv4) or prohibit local fragmentation (in IPv6). 453 - If the underlying transport protocol allows the application to 454 request PMTU probing (e.g., DCCP), the DTLS record layer should 455 honor this request. 457 The final issue is the DTLS handshake protocol. From the 458 perspective of the DTLS record layer, this is merely another upper 459 layer protocol. However, DTLS handshakes occur infrequently and 460 involve only a few round trips; therefore, the handshake protocol 461 PMTU handling places a premium on rapid completion over accurate 462 PMTU discovery. In order to allow connections under these 463 circumstances, DTLS implementations SHOULD follow the following 464 rules: 466 - If the DTLS record layer informs the DTLS handshake layer that a 467 message is too big, it SHOULD immediately attempt to fragment it, 468 using any existing information about the PMTU. 470 - If repeated retransmissions do not result in a response, and the 471 PMTU is unknown, subsequent retransmissions SHOULD back off to a 472 smaller record size, fragmenting the handshake message as 473 appropriate. This standard does not specify an exact number of 474 retransmits to attempt before backing off, but 2-3 seems 475 appropriate. 477 4.3. Record Payload Protection 479 Like TLS, DTLS transmits data as a series of protected records. The 480 rest of this section describes the details of that format. 482 4.3.1. Anti-Replay 484 DTLS records contain a sequence number to provide replay protection. 485 Sequence number verification SHOULD be performed using the following 486 sliding window procedure, borrowed from Section 3.4.3 of [RFC4303]. 488 The receiver packet counter for this session MUST be initialized to 489 zero when the session is established. For each received record, the 490 receiver MUST verify that the record contains a sequence number that 491 does not duplicate the sequence number of any other record received 492 during the life of this session. This SHOULD be the first check 493 applied to a packet after it has been matched to a session, to speed 494 rejection of duplicate records. 496 Duplicates are rejected through the use of a sliding receive window. 497 (How the window is implemented is a local matter, but the following 498 text describes the functionality that the implementation must 499 exhibit.) A minimum window size of 32 MUST be supported, but a 500 window size of 64 is preferred and SHOULD be employed as the default. 501 Another window size (larger than the minimum) MAY be chosen by the 502 receiver. (The receiver does not notify the sender of the window 503 size.) 505 The "right" edge of the window represents the highest validated 506 sequence number value received on this session. Records that contain 507 sequence numbers lower than the "left" edge of the window are 508 rejected. Packets falling within the window are checked against a 509 list of received packets within the window. An efficient means for 510 performing this check, based on the use of a bit mask, is described 511 in Section 3.4.3 of [RFC4303]. 513 If the received record falls within the window and is new, or if the 514 packet is to the right of the window, then the receiver proceeds to 515 MAC verification. If the MAC validation fails, the receiver MUST 516 discard the received record as invalid. The receive window is 517 updated only if the MAC verification succeeds. 519 4.3.2. Handling Invalid Records 521 Unlike TLS, DTLS is resilient in the face of invalid records (e.g., 522 invalid formatting, length, MAC, etc.). In general, invalid records 523 SHOULD be silently discarded, thus preserving the association; 524 however, an error MAY be logged for diagnostic purposes. 526 Implementations which choose to generate an alert instead, MUST 527 generate fatal level alerts to avoid attacks where the attacker 528 repeatedly probes the implementation to see how it responds to 529 various types of error. Note that if DTLS is run over UDP, then any 530 implementation which does this will be extremely susceptible to 531 denial-of-service (DoS) attacks because UDP forgery is so easy. 532 Thus, this practice is NOT RECOMMENDED for such transports. 534 If DTLS is being carried over a transport that is resistant to 535 forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts 536 because an attacker will have difficulty forging a datagram that will 537 not be rejected by the transport layer. 539 5. The DTLS Handshake Protocol 541 DTLS 1.3 re-uses the TLS 1.3 handshake messages and flows, with the 542 following changes: 544 1. To handle message loss, reordering, and fragmentation 545 modifications to the handshake header are necessary. 547 2. Retransmission timers are introduced to handle message loss. 549 3. The TLS 1.3 KeyUpdate message is not used in DTLS 1.3 for re- 550 keying. 552 4. A new ACK message is introduced to more robustness in message 553 delivery. 555 Note that TLS 1.3 already supports a cookie extension, which used to 556 prevent denial-of-service attacks. This DoS prevention mechanism is 557 described in more detail below since UDP-based protocols are more 558 vulnerable to amplification attacks than a connection-oriented 559 transport like TCP that performs return-routability checks as part of 560 the connection establishment. 562 With these exceptions, the DTLS message formats, flows, and logic are 563 the same as those of TLS 1.3. 565 5.1. Denial-of-Service Countermeasures 567 Datagram security protocols are extremely susceptible to a variety of 568 DoS attacks. Two attacks are of particular concern: 570 1. An attacker can consume excessive resources on the server by 571 transmitting a series of handshake initiation requests, causing 572 the server to allocate state and potentially to perform expensive 573 cryptographic operations. 575 2. An attacker can use the server as an amplifier by sending 576 connection initiation messages with a forged source of the 577 victim. The server then sends its next message (in DTLS, a 578 Certificate message, which can be quite large) to the victim 579 machine, thus flooding it. 581 In order to counter both of these attacks, DTLS borrows the stateless 582 cookie technique used by Photuris [RFC2522] and IKE [RFC5996]. When 583 the client sends its ClientHello message to the server, the server 584 MAY respond with a HelloRetryRequest message. The HelloRetryRequest 585 message as well as the cookie extension is defined in TLS 1.3. The 586 HelloRetryRequest message contains a stateless cookie generated using 587 the technique of [RFC2522]. The client MUST retransmit the 588 ClientHello with the cookie added as an extension. The server then 589 verifies the cookie and proceeds with the handshake only if it is 590 valid. This mechanism forces the attacker/client to be able to 591 receive the cookie, which makes DoS attacks with spoofed IP addresses 592 difficult. This mechanism does not provide any defence against DoS 593 attacks mounted from valid IP addresses. 595 The DTLS 1.3 specification changes the way how cookies are exchanged 596 compared to DTLS 1.2. DTLS 1.3 re-uses the HelloRetryRequest message 597 and conveys the cookie to the client via an extension. The client 598 then uses the same extension to place the cookie into a ClientHello 599 message. DTLS 1.2 on the other hand used a separate message, namely 600 the HelloVerifyRequest, to pass a cookie to the client and did not 601 utilize the extension mechanism. For backwards compatibility reason 602 the cookie field in the ClientHello is present in DTLS 1.3 but is 603 ignored by a DTLS 1.3 compliant server implementation. 605 The exchange is shown in Figure 2. Note that the figure focuses on 606 the cookie exchange; all other extensions are omitted. 608 Client Server 609 ------ ------ 610 ClientHello ------> 612 <----- HelloRetryRequest 613 + cookie 615 ClientHello ------> 616 + cookie 618 [Rest of handshake] 620 Figure 2: DTLS Exchange with HelloRetryRequest contain the Cookie 621 Extension 623 The cookie extension is defined in Section 4.2.1 of 624 [I-D.ietf-tls-tls13]. When sending the initial ClientHello, the 625 client does not have a cookie yet. In this case, the cookie 626 extension is omitted and the legacy_cookie field in the ClientHello 627 message SHOULD be set to a zero length vector (i.e., a single zero 628 byte length field) and MUST be ignored by a server negotiating DTLS 629 1.3. 631 When responding to a HelloRetryRequest, the client MUST create a new 632 ClientHello message following the description in Section 4.1 of 633 [I-D.ietf-tls-tls13]. 635 The server SHOULD use information received in the ClientHello to 636 generate its cookie, such as version, random, ciphersuites. The 637 server MUST use the same version number in the HelloRetryRequest that 638 it would use when sending a ServerHello. Upon receipt of the 639 ServerHello, the client MUST verify that the server version values 640 match. 642 If the HelloRetryRequest message is used, the initial ClientHello and 643 the HelloRetryRequest are included in the calculation of the 644 handshake_messages (for the CertificateVerify message) and 645 verify_data (for the Finished message). 647 As such, the handshake transcript is not reset with the second 648 ClientHello and a stateless server-cookie implementation requires the 649 transcript of the HelloRetryRequest to be stored in the cookie or the 650 internal state of the hash algorithm, since only the hash of the 651 transcript is required for the handshake to complete. 653 When the second ClientHello is received, the server can verify that 654 the cookie is valid and that the client can receive packets at the 655 given IP address. 657 One potential attack on this scheme is for the attacker to collect a 658 number of cookies from different addresses and then reuse them to 659 attack the server. The server can defend against this attack by 660 changing the secret value frequently, thus invalidating those 661 cookies. If the server wishes that legitimate clients be able to 662 handshake through the transition (e.g., they received a cookie with 663 Secret 1 and then sent the second ClientHello after the server has 664 changed to Secret 2), the server can have a limited window during 665 which it accepts both secrets. [RFC5996] suggests adding a key 666 identifier to cookies to detect this case. An alternative approach 667 is simply to try verifying with both secrets. It is RECOMMENDED that 668 servers implement a key rotation scheme that allows the server to 669 manage keys with overlapping lifetime. 671 Alternatively, the server can store timestamps in the cookie and 672 reject those cookies that were not generated within a certain amount 673 of time. 675 DTLS servers SHOULD perform a cookie exchange whenever a new 676 handshake is being performed. If the server is being operated in an 677 environment where amplification is not a problem, the server MAY be 678 configured not to perform a cookie exchange. The default SHOULD be 679 that the exchange is performed, however. In addition, the server MAY 680 choose not to do a cookie exchange when a session is resumed. 681 Clients MUST be prepared to do a cookie exchange with every 682 handshake. 684 If a server receives a ClientHello with an invalid cookie, it MUST 685 NOT respond with a HelloRetryRequest. Restarting the handshake from 686 scratch, without a cookie, allows the client to recover from a 687 situation where it obtained a cookie that cannot be verified by the 688 server. As described in Section 4.1.4 of 689 [I-D.ietf-tls-tls13],clients SHOULD also abort the handshake with an 690 "unexpected_message" alert in response to any second 691 HelloRetryRequest which was sent in the same connection (i.e., where 692 the ClientHello was itself in response to a HelloRetryRequest). 694 5.2. DTLS Handshake Message Format 696 In order to support message loss, reordering, and message 697 fragmentation, DTLS modifies the TLS 1.3 handshake header: 699 enum { 700 hello_request_RESERVED(0), 701 client_hello(1), 702 server_hello(2), 703 hello_verify_request_RESERVED(3), 704 new_session_ticket(4), 705 hello_retry_request(6), 706 encrypted_extensions(8), 707 certificate(11), 708 server_key_exchange_RESERVED(12), 709 certificate_request(13), 710 server_hello_done_RESERVED(14), 711 certificate_verify(15), 712 client_key_exchange_RESERVED(16), 713 finished(20), 714 key_update_RESERVED(24), 715 (255) 716 } HandshakeType; 718 struct { 719 HandshakeType msg_type; /* handshake type */ 720 uint24 length; /* bytes in message */ 721 uint16 message_seq; /* DTLS-required field */ 722 uint24 fragment_offset; /* DTLS-required field */ 723 uint24 fragment_length; /* DTLS-required field */ 724 select (HandshakeType) { 725 case client_hello: ClientHello; 726 case server_hello: ServerHello; 727 case hello_retry_request: HelloRetryRequest; 728 case encrypted_extensions: EncryptedExtensions; 729 case certificate_request: CertificateRequest; 730 case certificate: Certificate; 731 case certificate_verify: CertificateVerify; 732 case finished: Finished; 733 case new_session_ticket: NewSessionTicket; 734 case key_update: KeyUpdate; /* reserved */ 735 case ack: ACK; /* DTLS-required field */ 736 } body; 737 } Handshake; 739 In addition to the handshake messages that are deprecated by the TLS 740 1.3 specification DTLS 1.3 furthermore deprecates the 741 HelloVerifyRequest message originally defined in DTLS 1.0. DTLS 742 1.3-compliant implements MUST NOT use the HelloVerifyRequest to 743 execute a return-routability check. A dual-stack DTLS 1.2/DTLS 1.3 744 client must, however, be prepared to interact with a DTLS 1.2 server. 746 A DTLS 1.3 MUST NOT use the KeyUpdate message to change keying 747 material used for the protection of traffic data. Instead the epoch 748 field is used, which is explained in Section 5.9. 750 The format of the ClientHello used by a DTLS 1.3 client differs from 751 the TLS 1.3 ClientHello format as shown below. 753 struct { 754 ProtocolVersion client_version = { 254,252 }; /* DTLS v1.3 */ 755 Random random; 756 opaque legacy_session_id<0..32>; 757 opaque legacy_cookie<0..2^8-1>; // DTLS 758 CipherSuite cipher_suites<2..2^16-2>; 759 opaque legacy_compression_methods<1..2^8-1>; 760 Extension extensions<0..2^16-1>; 761 } ClientHello; 763 client_version: The version of the DTLS protocol by which the client 764 wishes to communicate during this session. This SHOULD be the 765 latest (highest valued) version supported by the client. For the 766 DTLS 1.3 version of the specification, the version will be { 767 254,252 }. 769 random: Same as for TLS 1.3 771 legacy_session_id: Same as for TLS 1.3 773 legacy_cookie: A DTLS 1.3-only client MUST set the legacy_cookie 774 field to zero length. 776 cipher_suites: Same as for TLS 1.3 778 legacy_compression_methods: Same as for TLS 1.3 780 extensions: Same as for TLS 1.3 782 The first message each side transmits in each handshake always has 783 message_seq = 0. Whenever a new message is generated, the 784 message_seq value is incremented by one. When a message is 785 retransmitted, the old message_seq value is re-used, i.e., not 786 incremented. 788 Here is an example: 790 Client Server 791 ------ ------ 793 ClientHello 794 (message_seq=0) 795 --------> 797 X<---- HelloRetryRequest 798 (lost) (message_seq=0) 800 [Timer Expires] 802 ClientHello 803 (message_seq=0) 804 (retransmit) --------> 806 <-------- HelloRetryRequest 807 (message_seq=0) 809 ClientHello --------> 810 (message_seq=1) 811 +cookie 813 <-------- ServerHello 814 (message_seq=1) 815 EncryptedExtensions 816 (message_seq=2) 817 Certificate 818 (message_seq=3) 819 CertificateVerify 820 (message_seq=4) 821 Finished 822 (message_seq=5) 824 Certificate --------> 825 (message_seq=2) 826 CertificateVerify 827 (message_seq=3) 828 Finished 829 (message_seq=4) 831 <-------- Ack 832 (message_seq=6) 834 Figure 3: Example DTLS Exchange illustrating Message Loss 836 From the perspective of the DTLS record layer, the retransmission is 837 a new record. This record will have a new 838 DTLSPlaintext.sequence_number value. 840 DTLS implementations maintain (at least notionally) a 841 next_receive_seq counter. This counter is initially set to zero. 842 When a message is received, if its sequence number matches 843 next_receive_seq, next_receive_seq is incremented and the message is 844 processed. If the sequence number is less than next_receive_seq, the 845 message MUST be discarded. If the sequence number is greater than 846 next_receive_seq, the implementation SHOULD queue the message but MAY 847 discard it. (This is a simple space/bandwidth tradeoff). 849 5.3. ACK Message 851 struct {} ACK; 853 The ACK handshake message is used by a server to return a response to 854 a client-provided message where the TLS 1.3 handshake does not 855 foresee such return message. With the use of the ACK message the 856 client is able to determine whether a transmitted request has been 857 lost and needs to be retransmitted. Since the ACK message does not 858 contain any correlation information the server MUST only have one 859 message outstanding at a time. 861 5.4. Handshake Message Fragmentation and Reassembly 863 Each DTLS message MUST fit within a single transport layer datagram. 864 However, handshake messages are potentially bigger than the maximum 865 record size. Therefore, DTLS provides a mechanism for fragmenting a 866 handshake message over a number of records, each of which can be 867 transmitted separately, thus avoiding IP fragmentation. 869 When transmitting the handshake message, the sender divides the 870 message into a series of N contiguous data ranges. These ranges MUST 871 NOT be larger than the maximum handshake fragment size and MUST 872 jointly contain the entire handshake message. The ranges MUST NOT 873 overlap. The sender then creates N handshake messages, all with the 874 same message_seq value as the original handshake message. Each new 875 message is labeled with the fragment_offset (the number of bytes 876 contained in previous fragments) and the fragment_length (the length 877 of this fragment). The length field in all messages is the same as 878 the length field of the original message. An unfragmented message is 879 a degenerate case with fragment_offset=0 and fragment_length=length. 881 When a DTLS implementation receives a handshake message fragment, it 882 MUST buffer it until it has the entire handshake message. DTLS 883 implementations MUST be able to handle overlapping fragment ranges. 885 This allows senders to retransmit handshake messages with smaller 886 fragment sizes if the PMTU estimate changes. 888 Note that as with TLS, multiple handshake messages may be placed in 889 the same DTLS record, provided that there is room and that they are 890 part of the same flight. Thus, there are two acceptable ways to pack 891 two DTLS messages into the same datagram: in the same record or in 892 separate records. 894 5.5. Timeout and Retransmission 896 DTLS messages are grouped into a series of message flights, according 897 to the diagrams below. Although each flight of messages may consist 898 of a number of messages, they should be viewed as monolithic for the 899 purpose of timeout and retransmission. 901 Client Server 903 ClientHello +----------+ 904 + key_share* | Flight 1 | 905 + pre_shared_key* --------> +----------+ 907 +----------+ 908 <-------- HelloRetryRequest | Flight 2 | 909 + cookie +----------+ 911 ClientHello +----------+ 912 + key_share* | Flight 3 | 913 + pre_shared_key* --------> +----------+ 914 + cookie 916 ServerHello 917 + key_share* 918 + pre_shared_key* +----------+ 919 {EncryptedExtensions} | Flight 4 | 920 {CertificateRequest*} +----------+ 921 {Certificate*} 922 {CertificateVerify*} 923 <-------- {Finished} 924 [Application Data*] 926 {Certificate*} +----------+ 927 {CertificateVerify*} | Flight 5 | 928 {Finished} --------> +----------+ 929 [Application Data] 931 +----------+ 932 <-------- {Ack} | Flight 6 | 933 [Application Data*] +----------+ 935 [Application Data] <-------> [Application Data] 937 Figure 4: Message Flights for full DTLS Handshake (with Cookie 938 Exchange) 940 ClientHello +----------+ 941 + pre_shared_key | Flight 1 | 942 + key_share* --------> +----------+ 944 ServerHello 945 + pre_shared_key +----------+ 946 + key_share* | Flight 2 | 947 {EncryptedExtensions} +----------+ 948 <-------- {Finished} 949 [Application Data*] 950 +----------+ 951 {Finished} --------> | Flight 3 | 952 [Application Data*] +----------+ 954 +----------+ 955 <-------- {Ack} | Flight 4 | 956 [Application Data*] +----------+ 958 [Application Data] <-------> [Application Data] 960 Figure 5: Message Flights for Resumption and PSK Handshake (without 961 Cookie Exchange) 963 Client Server 965 ClientHello 966 + early_data 967 + pre_shared_key +----------+ 968 + key_share* | Flight 1 | 969 (EncryptedExtensions) +----------+ 970 (Finished) 971 (Application Data*) 972 (end_of_early_data) --------> 974 ServerHello 975 + early_data 976 + pre_shared_key +----------+ 977 + key_share* | Flight 2 | 978 {EncryptedExtensions} +----------+ 979 {CertificateRequest*} 980 <-------- {Finished} 981 [Application Data*] 983 +----------+ 984 | Flight 3 | 985 {Finished} --------> +----------+ 986 [Application Data*] 987 +----------+ 988 <-------- {Ack} | Flight 4 | 989 [Application Data*] +----------+ 991 [Application Data] <-------> [Application Data] 993 Figure 6: Message Flights for a zero round trip handshake 995 Client Server 997 +----------+ 998 <-------- {NewSessionTicket} | Flight 1 | 999 +----------+ 1001 +----------+ 1002 {Ack} --------> | Flight 2 | 1003 +----------+ 1005 Figure 7: Message Flights for New Session Ticket Message 1007 Client Server 1009 +----------+ 1010 <-------- {CertificateRequest} | Flight 1 | 1011 +----------+ 1013 {Certificate} +----------+ 1014 {CertificateVerify} | Flight 2 | 1015 {Finished} --------> +----------+ 1017 Figure 8: Message Flights for Post-Handshake Authentication (Success) 1019 Client Server 1021 +----------+ 1022 <-------- {CertificateRequest} | Flight 1 | 1023 +----------+ 1025 {Certificate} +----------+ 1026 {Finished} --------> | Flight 2 | 1027 +----------+ 1029 Figure 9: Message Flights for Post-Handshake Authentication (Decline) 1031 Note: The application data sent by the client is not included in the 1032 timeout and retransmission calculation. 1034 5.5.1. State Machine 1036 DTLS uses a simple timeout and retransmission scheme with the state 1037 machine shown in Figure 10. Because DTLS clients send the first 1038 message (ClientHello), they start in the PREPARING state. DTLS 1039 servers start in the WAITING state, but with empty buffers and no 1040 retransmit timer. 1042 +-----------+ 1043 | PREPARING | 1044 +---> | | <--------------------+ 1045 | | | | 1046 | +-----------+ | 1047 | | | 1048 | | Buffer next flight | 1049 | | | 1050 | \|/ | 1051 | +-----------+ | 1052 | | | | 1053 | | SENDING |<------------------+ | 1054 | | | | | Send 1055 | +-----------+ | | HelloRequest 1056 Receive | | | | 1057 next | | Send flight | | or 1058 flight | +--------+ | | 1059 | | | Set retransmit timer | | Receive 1060 | | \|/ | | HelloRequest 1061 | | +-----------+ | | Send 1062 | | | | | | ClientHello 1063 +--)--| WAITING |-------------------+ | 1064 | | | | Timer expires | | 1065 | | +-----------+ | | 1066 | | | | | 1067 | | | | | 1068 | | +------------------------+ | 1069 | | Read retransmit | 1070 Receive | | | 1071 last | | | 1072 flight | | | 1073 | | | 1074 \|/\|/ | 1075 | 1076 +-----------+ | 1077 | | | 1078 | FINISHED | -------------------------------+ 1079 | | 1080 +-----------+ 1081 | /|\ 1082 | | 1083 | | 1084 +---+ 1086 Read retransmit 1087 Retransmit last flight 1089 Figure 10: DTLS Timeout and Retransmission State Machine 1091 The state machine has three basic states. 1093 In the PREPARING state, the implementation does whatever computations 1094 are necessary to prepare the next flight of messages. It then 1095 buffers them up for transmission (emptying the buffer first) and 1096 enters the SENDING state. 1098 In the SENDING state, the implementation transmits the buffered 1099 flight of messages. Once the messages have been sent, the 1100 implementation then enters the FINISHED state if this is the last 1101 flight in the handshake. Or, if the implementation expects to 1102 receive more messages, it sets a retransmit timer and then enters the 1103 WAITING state. 1105 There are three ways to exit the WAITING state: 1107 1. The retransmit timer expires: the implementation transitions to 1108 the SENDING state, where it retransmits the flight, resets the 1109 retransmit timer, and returns to the WAITING state. 1111 2. The implementation reads a retransmitted flight from the peer: 1112 the implementation transitions to the SENDING state, where it 1113 retransmits the flight, resets the retransmit timer, and returns 1114 to the WAITING state. The rationale here is that the receipt of 1115 a duplicate message is the likely result of timer expiry on the 1116 peer and therefore suggests that part of one's previous flight 1117 was lost. 1119 3. The implementation receives the next flight of messages: if this 1120 is the final flight of messages, the implementation transitions 1121 to FINISHED. If the implementation needs to send a new flight, 1122 it transitions to the PREPARING state. Partial reads (whether 1123 partial messages or only some of the messages in the flight) do 1124 not cause state transitions or timer resets. 1126 Because DTLS clients send the first message (ClientHello), they 1127 start in the PREPARING state. DTLS servers start in the WAITING 1128 state, but with empty buffers and no retransmit timer. 1130 When the server desires a rehandshake, it transitions from the 1131 FINISHED state to the PREPARING state to transmit the 1132 HelloRequest. When the client receives a HelloRequest, it 1133 transitions from FINISHED to PREPARING to transmit the 1134 ClientHello. 1136 In addition, for at least twice the default Maximum Segment 1137 Lifetime (MSL) defined for [RFC0793], when in the FINISHED state, 1138 the node that transmits the last flight (the server in an 1139 ordinary handshake or the client in a resumed handshake) MUST 1140 respond to a retransmit of the peer's last flight with a 1141 retransmit of the last flight. This avoids deadlock conditions 1142 if the last flight gets lost. To see why this is necessary, 1143 consider what happens in an ordinary handshake if the server's 1144 Finished message is lost: the server believes the handshake is 1145 complete but it actually is not. As the client is waiting for 1146 the Finished message, the client's retransmit timer will fire and 1147 it will retransmit the client's Finished message. This will 1148 cause the server to respond with its own Finished message, 1149 completing the handshake. The same logic applies on the server 1150 side for the resumed handshake. 1152 Note that because of packet loss, it is possible for one side to 1153 be sending application data even though the other side has not 1154 received the first side's Finished message. Implementations MUST 1155 either discard or buffer all application data packets for the new 1156 epoch until they have received the Finished message for that 1157 epoch. Implementations MAY treat receipt of application data 1158 with a new epoch prior to receipt of the corresponding Finished 1159 message as evidence of reordering or packet loss and retransmit 1160 their final flight immediately, shortcutting the retransmission 1161 timer. 1163 5.5.2. Timer Values 1165 Though timer values are the choice of the implementation, mishandling 1166 of the timer can lead to serious congestion problems; for example, if 1167 many instances of a DTLS time out early and retransmit too quickly on 1168 a congested link. Implementations SHOULD use an initial timer value 1169 of 100 msec (the minimum defined in RFC 6298 [RFC6298]) and double 1170 the value at each retransmission, up to no less than the RFC 6298 1171 maximum of 60 seconds. Application specific profiles, such as those 1172 used for the Internet of Things environment, may recommend longer 1173 timer values. Note that we recommend a 100 msec timer rather than 1174 the 3-second RFC 6298 default in order to improve latency for time- 1175 sensitive applications. Because DTLS only uses retransmission for 1176 handshake and not dataflow, the effect on congestion should be 1177 minimal. 1179 Implementations SHOULD retain the current timer value until a 1180 transmission without loss occurs, at which time the value may be 1181 reset to the initial value. After a long period of idleness, no less 1182 than 10 times the current timer value, implementations may reset the 1183 timer to the initial value. One situation where this might occur is 1184 when a rehandshake is used after substantial data transfer. 1186 5.6. CertificateVerify and Finished Messages 1188 CertificateVerify and Finished messages have the same format as in 1189 TLS 1.3. Hash calculations include entire handshake messages, 1190 including DTLS-specific fields: message_seq, fragment_offset, and 1191 fragment_length. However, in order to remove sensitivity to 1192 handshake message fragmentation, the CertificateVerify and the 1193 Finished messages MUST be computed as if each handshake message had 1194 been sent as a single fragment following the algorithm described in 1195 Section 4.4.1 and Section 4.4.3 of [I-D.ietf-tls-tls13], 1196 respectively. 1198 5.7. Alert Messages 1200 Note that Alert messages are not retransmitted at all, even when they 1201 occur in the context of a handshake. However, a DTLS implementation 1202 which would ordinarily issue an alert SHOULD generate a new alert 1203 message if the offending record is received again (e.g., as a 1204 retransmitted handshake message). Implementations SHOULD detect when 1205 a peer is persistently sending bad messages and terminate the local 1206 connection state after such misbehavior is detected. 1208 5.8. Establishing New Associations with Existing Parameters 1210 If a DTLS client-server pair is configured in such a way that 1211 repeated connections happen on the same host/port quartet, then it is 1212 possible that a client will silently abandon one connection and then 1213 initiate another with the same parameters (e.g., after a reboot). 1214 This will appear to the server as a new handshake with epoch=0. In 1215 cases where a server believes it has an existing association on a 1216 given host/port quartet and it receives an epoch=0 ClientHello, it 1217 SHOULD proceed with a new handshake but MUST NOT destroy the existing 1218 association until the client has demonstrated reachability either by 1219 completing a cookie exchange or by completing a complete handshake 1220 including delivering a verifiable Finished message. After a correct 1221 Finished message is received, the server MUST abandon the previous 1222 association to avoid confusion between two valid associations with 1223 overlapping epochs. The reachability requirement prevents off-path/ 1224 blind attackers from destroying associations merely by sending forged 1225 ClientHellos. 1227 5.9. Epoch Values and Rekeying 1229 A recipient of a DTLS message needs to select the correct keying 1230 material in order to process an incoming message. With the 1231 possibility of message loss and re-order an identifier is needed to 1232 determine which cipher state has been used to protect the record 1233 payload. The epoch value fulfills this role in DTLS. In addition to 1234 the key derivation steps described in Section 7 of 1235 [I-D.ietf-tls-tls13] triggered by the states during the handshake a 1236 sender may want to rekey at any time during the lifetime of the 1237 connection and has to have a way to indicate that it is updating its 1238 sending cryptographic keys. 1240 The following epoch values are reserved and correspond to phases in 1241 the handshake and allow identification of the correct cipher state: 1243 - epoch value (0) for use with unencrypted messages, namely 1244 ClientHello, ServerHello, and HelloRetryRequest. 1246 - epoch value (1) for messages protected using keys derived from 1247 early_traffic_secret. 1249 - epoch value (2) for 0-RTT 'Application Data' protected using keys 1250 derived from the early_traffic_secret. 1252 - epoch value (3) for messages protected using keys derived from the 1253 handshake_traffic_secret, namely the EncryptedExtensions, 1254 CertificateRequest, Certificate, CertificateVerify, Finished, ACK, 1255 and NewSessionTicket messages). 1257 - epoch value (4) for application data payloads protected using keys 1258 derived from the initial traffic_secret_0. 1260 - epoch value (5 to 2^16-1) for application data payloads protected 1261 using keys from the traffic_secret_N (N>0). 1263 Using these reserved epoch values a receiver knows what cipher state 1264 has been used to encrypt and integrity protect a message. 1265 Implementations that receive a payload with an epoch value for which 1266 no corresponding cipher state can be determined MUST generate a fatal 1267 "unexpected_message" alert. For example, client incorrectly uses 1268 epoch value 5 when sending application data in a 0-RTT exchange with 1269 the first message. A server will not be able to compute the 1270 appropriate keys and will therefore have to respond with a fatal 1271 alert. 1273 Increasing the epoch value by a sender (starting with value 5 1274 upwards) corresponds semantically to rekeying using the KeyUpdate 1275 message in TLS 1.3. Instead of utilizing an dedicated message in 1276 DTLS 1.3 the sender uses an increase in the epoch value to signal 1277 rekeying. Hence, a sender that decides to increment the epoch value 1278 (with value starting at 5) MUST send all its traffic using the next 1279 generation of keys, computed as described in Section 7.2 of 1280 [I-D.ietf-tls-tls13]. Upon receiving a payload with such a new epoch 1281 value, the receiver MUST update their receiving keys and if they have 1282 not already updated their sending state up to or past the then 1283 current receiving generation MUST send messages with the new epoch 1284 value prior to sending any other messages. For epoch values lower 1285 than 5 the key schedule described in Section 7.1 of 1286 [I-D.ietf-tls-tls13] is applicable. 1288 Note that epoch values do not wrap. If a DTLS implementation would 1289 need to wrap the epoch value, it MUST terminate the connection. 1291 The traffic key calculation is described in Section 7.3 of 1292 [I-D.ietf-tls-tls13]. 1294 6. Application Data Protocol 1296 Application data messages are carried by the record layer and are 1297 fragmented and encrypted based on the current connection state. The 1298 messages are treated as transparent data to the record layer. 1300 7. Security Considerations 1302 Security issues are discussed primarily in [I-D.ietf-tls-tls13]. 1304 The primary additional security consideration raised by DTLS is that 1305 of denial of service. DTLS includes a cookie exchange designed to 1306 protect against denial of service. However, implementations that do 1307 not use this cookie exchange are still vulnerable to DoS. In 1308 particular, DTLS servers that do not use the cookie exchange may be 1309 used as attack amplifiers even if they themselves are not 1310 experiencing DoS. Therefore, DTLS servers SHOULD use the cookie 1311 exchange unless there is good reason to believe that amplification is 1312 not a threat in their environment. Clients MUST be prepared to do a 1313 cookie exchange with every handshake. 1315 Unlike TLS implementations, DTLS implementations SHOULD NOT respond 1316 to invalid records by terminating the connection. 1318 8. Changes to DTLS 1.2 1320 Since TLS 1.3 introduce a large number of changes to TLS 1.2, the 1321 list of changes from DTLS 1.2 to DTLS 1.3 is equally large. For this 1322 reason this section focuses on the most important changes only. 1324 - New handshake pattern, which leads to a shorter message exchange 1326 - Support for AEAD-only ciphers 1328 - HelloRetryRequest of TLS 1.3 used instead of HelloVerifyRequest 1329 - More flexible ciphersuite negotiation 1331 - New session resumption mechanism 1333 - PSK authentication redefined 1335 - New key derivation hierarchy utilizing the HKDF construct 1337 - Removed support for weaker and older cryptographic algorithms 1339 9. Open Issues 1341 - Handling of the handshake sequence numbers (i.e., 1342 Handshake.message_seq) when 0-RTT is rejected. Proposal: keep 1343 pushing the numbers forward 1345 - Explore whether the record layer header can be simplified (to 2 1346 octets for epoch & sequence number) 1348 - Do we need the HelloRequest message in DTLS 1.3? 1350 - Update text in the appendix regarding backwards compatibility. 1352 10. IANA Considerations 1354 IANA is requested to allocate a new value in the TLS HandshakeType 1355 Registry for the ACK message defined in Section 5.3. 1357 11. References 1359 11.1. Normative References 1361 [I-D.ietf-tls-tls13] 1362 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1363 Version 1.3", draft-ietf-tls-tls13-18 (work in progress), 1364 October 2016. 1366 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1367 RFC 793, DOI 10.17487/RFC0793, September 1981, 1368 . 1370 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1371 DOI 10.17487/RFC1191, November 1990, 1372 . 1374 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1375 Requirement Levels", BCP 14, RFC 2119, 1376 DOI 10.17487/RFC2119, March 1997, 1377 . 1379 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1380 Control Message Protocol (ICMPv6) for the Internet 1381 Protocol Version 6 (IPv6) Specification", RFC 4443, 1382 DOI 10.17487/RFC4443, March 2006, 1383 . 1385 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1386 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1387 . 1389 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 1390 "Computing TCP's Retransmission Timer", RFC 6298, 1391 DOI 10.17487/RFC6298, June 2011, 1392 . 1394 11.2. Informative References 1396 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 1397 Protocol", RFC 2522, DOI 10.17487/RFC2522, March 1999, 1398 . 1400 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1401 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1402 . 1404 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1405 Congestion Control Protocol (DCCP)", RFC 4340, 1406 DOI 10.17487/RFC4340, March 2006, 1407 . 1409 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 1410 the Datagram Congestion Control Protocol (DCCP)", 1411 RFC 5238, DOI 10.17487/RFC5238, May 2008, 1412 . 1414 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1415 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1416 RFC 5996, DOI 10.17487/RFC5996, September 2010, 1417 . 1419 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1420 "Recommendations for Secure Use of Transport Layer 1421 Security (TLS) and Datagram Transport Layer Security 1422 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1423 2015, . 1425 11.3. URIs 1427 [1] mailto:tls@ietf.org 1429 Appendix A. History 1431 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 1433 draft-00 1435 - Initial version using TLS 1.3 as a baseline. 1437 - Use of epoch values instead of KeyUpdate message 1439 - Use of cookie extension instead of cookie field in ClientHello and 1440 HelloVerifyRequest messages 1442 - Added ACK message 1444 - Text about sequence number handling 1446 Appendix B. Working Group Information 1448 The discussion list for the IETF TLS working group is located at the 1449 e-mail address tls@ietf.org [1]. Information on the group and 1450 information on how to subscribe to the list is at 1451 https://www1.ietf.org/mailman/listinfo/tls 1453 Archives of the list can be found at: https://www.ietf.org/mail- 1454 archive/web/tls/current/index.html 1456 Appendix C. Contributors 1458 Many people have contributed to previous DTLS versions and they are 1459 acknowledged in prior versions of DTLS specifications. 1461 For this version of the document we would like to thank: 1463 * Nagendra Modadugu (co-author of {{RFC6347}}) 1464 Google, Inc. 1465 nagendra@cs.stanford.edu 1467 * Ilari Liusvaara 1468 Independent 1469 ilariliusvaara@welho.com 1471 * Martin Thomson 1472 Mozilla 1473 martin.thomson@gmail.com 1475 Authors' Addresses 1477 Eric Rescorla 1478 RTFM, Inc. 1480 EMail: ekr@rtfm.com 1482 Hannes Tschofenig 1483 ARM Limited 1485 EMail: hannes.tschofenig@gmx.net