idnits 2.17.1 draft-ietf-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 (April 28, 2017) is 2545 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 785 -- Looks like a reference, but probably isn't: '2' on line 787 == Missing Reference: 'Ack' is mentioned on line 1372, but not defined == Missing Reference: 'NewSessionTicket' is mentioned on line 1369, but not defined == Missing Reference: 'CertificateRequest' is mentioned on line 1063, but not defined == Missing Reference: 'Certificate' is mentioned on line 1066, but not defined == Missing Reference: 'CertificateVerify' is mentioned on line 1055, but not defined == Missing Reference: 'Finished' is mentioned on line 1067, but not defined -- Looks like a reference, but probably isn't: '1' on line 1532 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-19 ** 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 (~~), 9 warnings (==), 8 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: October 30, 2017 N. Modadugu 7 Google, Inc. 8 April 28, 2017 10 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 11 draft-ietf-tls-dtls13-00 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 October 30, 2017. 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 . . . . . . . . . . . . . . . . . . . . . . . 5 75 3.1.1. Reordering . . . . . . . . . . . . . . . . . . . . . 6 76 3.1.2. Message Size . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . 9 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. ACK Message . . . . . . . . . . . . . . . . . . . . . . . 20 89 5.4. Handshake Message Fragmentation and Reassembly . . . . . 20 90 5.5. Timeout and Retransmission . . . . . . . . . . . . . . . 21 91 5.5.1. State Machine . . . . . . . . . . . . . . . . . . . . 25 92 5.5.2. Timer Values . . . . . . . . . . . . . . . . . . . . 28 93 5.6. CertificateVerify and Finished Messages . . . . . . . . . 28 94 5.7. Alert Messages . . . . . . . . . . . . . . . . . . . . . 28 95 5.8. Establishing New Associations with Existing Parameters . 29 96 5.9. Epoch Values and Rekeying . . . . . . . . . . . . . . . . 29 98 6. Application Data Protocol . . . . . . . . . . . . . . . . . . 32 99 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 100 8. Changes to DTLS 1.2 . . . . . . . . . . . . . . . . . . . . . 32 101 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 102 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 103 10.1. Normative References . . . . . . . . . . . . . . . . . . 33 104 10.2. Informative References . . . . . . . . . . . . . . . . . 34 105 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 35 106 Appendix B. Working Group Information . . . . . . . . . . . . . 35 107 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 35 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 110 1. Introduction 112 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH 114 The source for this draft is maintained in GitHub. Suggested changes 115 should be submitted as pull requests at https://github.com/tlswg/ 116 dtls13-spec. Instructions are on that page as well. Editorial 117 changes can be managed in GitHub, but any substantive change should 118 be discussed on the TLS mailing list. 120 The primary goal of the TLS protocol is to provide privacy and data 121 integrity between two communicating peers. The TLS protocol is 122 composed of two layers: the TLS Record Protocol and the TLS Handshake 123 Protocol. However, TLS must run over a reliable transport channel - 124 typically TCP [RFC0793]. 126 There are applications that utilize UDP as a transport and to offer 127 communication security protection for those applications the Datagram 128 Transport Layer Security (DTLS) protocol has been designed. DTLS is 129 deliberately designed to be as similar to TLS as possible, both to 130 minimize new security invention and to maximize the amount of code 131 and infrastructure reuse. 133 DTLS 1.0 was originally defined as a delta from TLS 1.1 and DTLS 1.2 134 was defined as a series of deltas to TLS 1.2. There is no DTLS 1.1; 135 that version number was skipped in order to harmonize version numbers 136 with TLS. This specification describes the most current version of 137 the DTLS protocol aligning with the efforts around TLS 1.3. 139 Implementations that speak both DTLS 1.2 and DTLS 1.3 can 140 interoperate with those that speak only DTLS 1.2 (using DTLS 1.2 of 141 course), just as TLS 1.3 implementations can interoperate with TLS 142 1.2 (see Appendix D of [I-D.ietf-tls-tls13] for details). While 143 backwards compatibility with DTLS 1.0 is possible the use of DTLS 1.0 144 is not recommended as explained in Section 3.1.2 of RFC 7525 145 [RFC7525]. 147 2. Conventions and Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 151 "OPTIONAL" in this document are to be interpreted as described in RFC 152 2119 [RFC2119]. 154 The following terms are used: 156 - client: The endpoint initiating the TLS connection. 158 - connection: A transport-layer connection between two endpoints. 160 - endpoint: Either the client or server of the connection. 162 - handshake: An initial negotiation between client and server that 163 establishes the parameters of their transactions. 165 - peer: An endpoint. When discussing a particular endpoint, "peer" 166 refers to the endpoint that is remote to the primary subject of 167 discussion. 169 - receiver: An endpoint that is receiving records. 171 - sender: An endpoint that is transmitting records. 173 - session: An association between a client and a server resulting 174 from a handshake. 176 - server: The endpoint which did not initiate the TLS connection. 178 The reader is assumed to be familiar with the TLS 1.3 specification 179 since this document defined as a delta from TLS 1.3. 181 Figures in this document illustrate various combinations of the DTLS 182 protocol exchanges and the symbols have the following meaning: 184 - '+' indicates noteworthy extensions sent in the previously noted 185 message. 187 - '*' indicates optional or situation-dependent messages/extensions 188 that are not always sent. 190 - '{}' indicates messages protected using keys derived from a 191 [sender]_handshake_traffic_secret. 193 - '[]' indicates messages protected using keysderived from 194 traffic_secret_N. 196 3. DTLS Design Rational and Overview 198 The basic design philosophy of DTLS is to construct "TLS over 199 datagram transport". Datagram transport does not require or provide 200 reliable or in-order delivery of data. The DTLS protocol preserves 201 this property for application data. Applications such as media 202 streaming, Internet telephony, and online gaming use datagram 203 transport for communication due to the delay-sensitive nature of 204 transported data. The behavior of such applications is unchanged 205 when the DTLS protocol is used to secure communication, since the 206 DTLS protocol does not compensate for lost or re-ordered data 207 traffic. 209 TLS cannot be used directly in datagram environments for the 210 following five reasons: 212 1. TLS does not allow independent decryption of individual records. 213 Because the integrity check indirectly depends on a sequence 214 number, if record N is not received, then the integrity check on 215 record N+1 will be based on the wrong sequence number and thus 216 will fail. DTLS solves this problem by adding explicit sequence 217 numbers. 219 2. The TLS handshake is a lock-step cryptographic handshake. 220 Messages must be transmitted and received in a defined order; any 221 other order is an error. Clearly, this is incompatible with 222 reordering and message loss. 224 3. Not all TLS 1.3 handshake messages (such as the NewSessionTicket 225 message) are acknowledged. Hence, a new acknowledgement message 226 has to be added to detect message loss. 228 4. Handshake messages are potentially larger than any given 229 datagram, thus creating the problem of IP fragmentation. 231 5. Datagram transport protocols, like UDP, are more vulnerable to 232 denial of service attacks and require a return-routability check 233 with the help of cookies to be integrated into the handshake. A 234 detailed discussion of countermeasures can be found in 235 Section 5.1. 237 3.1. Packet Loss 239 DTLS uses a simple retransmission timer to handle packet loss. 240 Figure 1 demonstrates the basic concept, using the first phase of the 241 DTLS handshake: 243 Client Server 244 ------ ------ 245 ClientHello ------> 247 X<-- HelloRetryRequest 248 (lost) 250 [Timer Expires] 252 ClientHello ------> 253 (retransmit) 255 Figure 1: DTLS Retransmission Example. 257 Once the client has transmitted the ClientHello message, it expects 258 to see a HelloRetryRequest from the server. However, if the server's 259 message is lost, the client knows that either the ClientHello or the 260 HelloRetryRequest has been lost and retransmits. When the server 261 receives the retransmission, it knows to retransmit. 263 The server also maintains a retransmission timer and retransmits when 264 that timer expires. 266 Note that timeout and retransmission do not apply to the 267 HelloRetryRequest since this would require creating state on the 268 server. The HelloRetryRequest is designed to be small enough that it 269 will not itself be fragmented, thus avoiding concerns about 270 interleaving multiple HelloRetryRequests. 272 3.1.1. Reordering 274 In DTLS, each handshake message is assigned a specific sequence 275 number within that handshake. When a peer receives a handshake 276 message, it can quickly determine whether that message is the next 277 message it expects. If it is, then it processes it. If not, it 278 queues it for future handling once all previous messages have been 279 received. 281 3.1.2. Message Size 283 TLS and DTLS handshake messages can be quite large (in theory up to 284 2^24-1 bytes, in practice many kilobytes). By contrast, UDP 285 datagrams are often limited to less than 1500 bytes if IP 286 fragmentation is not desired. In order to compensate for this 287 limitation, each DTLS handshake message may be fragmented over 288 several DTLS records, each of which is intended to fit in a single IP 289 datagram. Each DTLS handshake message contains both a fragment 290 offset and a fragment length. Thus, a recipient in possession of all 291 bytes of a handshake message can reassemble the original unfragmented 292 message. 294 3.2. Replay Detection 296 DTLS optionally supports record replay detection. The technique used 297 is the same as in IPsec AH/ESP, by maintaining a bitmap window of 298 received records. Records that are too old to fit in the window and 299 records that have previously been received are silently discarded. 300 The replay detection feature is optional, since packet duplication is 301 not always malicious, but can also occur due to routing errors. 302 Applications may conceivably detect duplicate packets and accordingly 303 modify their data transmission strategy. 305 4. The DTLS Record Layer 307 The DTLS record layer is similar to that of TLS 1.3 unless noted 308 otherwise. The only change is the inclusion of an explicit epoch and 309 sequence number in the record. This sequence number allows the 310 recipient to correctly verify the TLS MAC. The DTLS record format is 311 shown below: 313 struct { 314 opaque content[DTLSPlaintext.length]; 315 ContentType type; 316 uint8 zeros[length_of_padding]; 317 } DTLSInnerPlaintext; 319 struct { 320 ContentType opaque_type = 23; /* application_data */ 321 ProtocolVersion legacy_record_version = {254,253); // DTLSv1.2 322 uint16 epoch; // DTLS-related field 323 uint48 sequence_number; // DTLS-related field 324 uint16 length; 325 opaque encrypted_record[length]; 326 } DTLSCiphertext; 328 type: The content type of the record. 330 legacy_record_version: This field is redundant and it is treated in 331 the same way as specified in the TLS 1.3 specification. The DTLS 332 version 1.2 version number is reused, namely { 254, 253 }. This 333 field is deprecated and MUST be ignored. 335 epoch: A counter value that is incremented on every cipher state 336 change. 338 sequence_number: The sequence number for this record. 340 length: Identical to the length field in a TLS 1.3 record. 342 encrypted_record: Identical to the encrypted_record field in a TLS 343 1.3 record. 345 4.1. Sequence Number Handling 347 DTLS uses an explicit sequence number, rather than an implicit one, 348 carried in the sequence_number field of the record. Sequence numbers 349 are maintained separately for each epoch, with each sequence_number 350 initially being 0 for each epoch. For instance, if a handshake 351 message from epoch 0 is retransmitted, it might have a sequence 352 number after a message from epoch 1, even if the message from epoch 1 353 was transmitted first. Note that some care needs to be taken during 354 the handshake to ensure that retransmitted messages use the right 355 epoch and keying material. 357 The epoch number is initially zero and is incremented each time 358 keying material changes and a sender aims to rekey. More details are 359 provided in Section 5.9. In order to ensure that any given sequence/ 360 epoch pair is unique, implementations MUST NOT allow the same epoch 361 value to be reused within two times the TCP maximum segment lifetime. 363 Note that because DTLS records may be reordered, a record from epoch 364 1 may be received after epoch 2 has begun. In general, 365 implementations SHOULD discard packets from earlier epochs, but if 366 packet loss causes noticeable problems they MAY choose to retain 367 keying material from previous epochs for up to the default MSL 368 specified for TCP [RFC0793] to allow for packet reordering. (Note 369 that the intention here is that implementers use the current guidance 370 from the IETF for MSL, not that they attempt to interrogate the MSL 371 that the system TCP stack is using.) Until the handshake has 372 completed, implementations MUST accept packets from the old epoch. 374 Conversely, it is possible for records that are protected by the 375 newly negotiated context to be received prior to the completion of a 376 handshake. For instance, the server may send its Finished message 377 and then start transmitting data. Implementations MAY either buffer 378 or discard such packets, though when DTLS is used over reliable 379 transports (e.g., SCTP), they SHOULD be buffered and processed once 380 the handshake completes. Note that TLS's restrictions on when 381 packets may be sent still apply, and the receiver treats the packets 382 as if they were sent in the right order. In particular, it is still 383 impermissible to send data prior to completion of the first 384 handshake. 386 Implementations MUST either abandon an association or re-key prior to 387 allowing the sequence number to wrap. 389 Implementations MUST NOT allow the epoch to wrap, but instead MUST 390 establish a new association, terminating the old association. 392 4.2. Transport Layer Mapping 394 Each DTLS record MUST fit within a single datagram. In order to 395 avoid IP fragmentation, clients of the DTLS record layer SHOULD 396 attempt to size records so that they fit within any PMTU estimates 397 obtained from the record layer. 399 Note that unlike IPsec, DTLS records do not contain any association 400 identifiers. Applications must arrange to multiplex between 401 associations. With UDP, the host/port number is used to look up the 402 appropriate security association for incoming records. 404 Multiple DTLS records may be placed in a single datagram. They are 405 simply encoded consecutively. The DTLS record framing is sufficient 406 to determine the boundaries. Note, however, that the first byte of 407 the datagram payload must be the beginning of a record. Records may 408 not span datagrams. 410 Some transports, such as DCCP [RFC4340], provide their own sequence 411 numbers. When carried over those transports, both the DTLS and the 412 transport sequence numbers will be present. Although this introduces 413 a small amount of inefficiency, the transport layer and DTLS sequence 414 numbers serve different purposes; therefore, for conceptual 415 simplicity, it is superior to use both sequence numbers. 417 Some transports provide congestion control for traffic carried over 418 them. If the congestion window is sufficiently narrow, DTLS 419 handshake retransmissions may be held rather than transmitted 420 immediately, potentially leading to timeouts and spurious 421 retransmission. When DTLS is used over such transports, care should 422 be taken not to overrun the likely congestion window. [RFC5238] 423 defines a mapping of DTLS to DCCP that takes these issues into 424 account. 426 4.3. PMTU Issues 428 In general, DTLS's philosophy is to leave PMTU discovery to the 429 application. However, DTLS cannot completely ignore PMTU for three 430 reasons: 432 - The DTLS record framing expands the datagram size, thus lowering 433 the effective PMTU from the application's perspective. 435 - In some implementations, the application may not directly talk to 436 the network, in which case the DTLS stack may absorb ICMP 438 [RFC1191] "Datagram Too Big" indications or ICMPv6 [RFC4443] 439 "Packet Too Big" indications. 441 - The DTLS handshake messages can exceed the PMTU. 443 In order to deal with the first two issues, the DTLS record layer 444 SHOULD behave as described below. 446 If PMTU estimates are available from the underlying transport 447 protocol, they should be made available to upper layer protocols. In 448 particular: 450 - For DTLS over UDP, the upper layer protocol SHOULD be allowed to 451 obtain the PMTU estimate maintained in the IP layer. 453 - For DTLS over DCCP, the upper layer protocol SHOULD be allowed to 454 obtain the current estimate of the PMTU. 456 - For DTLS over TCP or SCTP, which automatically fragment and 457 reassemble datagrams, there is no PMTU limitation. However, the 458 upper layer protocol MUST NOT write any record that exceeds the 459 maximum record size of 2^14 bytes. 461 The DTLS record layer SHOULD allow the upper layer protocol to 462 discover the amount of record expansion expected by the DTLS 463 processing. 465 If there is a transport protocol indication (either via ICMP or via a 466 refusal to send the datagram as in Section 14 of [RFC4340]), then the 467 DTLS record layer MUST inform the upper layer protocol of the error. 469 The DTLS record layer SHOULD NOT interfere with upper layer protocols 470 performing PMTU discovery, whether via [RFC1191] or [RFC4821] 471 mechanisms. In particular: 473 - Where allowed by the underlying transport protocol, the upper 474 layer protocol SHOULD be allowed to set the state of the DF bit 475 (in IPv4) or prohibit local fragmentation (in IPv6). 477 - If the underlying transport protocol allows the application to 478 request PMTU probing (e.g., DCCP), the DTLS record layer should 479 honor this request. 481 The final issue is the DTLS handshake protocol. From the perspective 482 of the DTLS record layer, this is merely another upper layer 483 protocol. However, DTLS handshakes occur infrequently and involve 484 only a few round trips; therefore, the handshake protocol PMTU 485 handling places a premium on rapid completion over accurate PMTU 486 discovery. In order to allow connections under these circumstances, 487 DTLS implementations SHOULD follow the following rules: 489 - If the DTLS record layer informs the DTLS handshake layer that a 490 message is too big, it SHOULD immediately attempt to fragment it, 491 using any existing information about the PMTU. 493 - If repeated retransmissions do not result in a response, and the 494 PMTU is unknown, subsequent retransmissions SHOULD back off to a 495 smaller record size, fragmenting the handshake message as 496 appropriate. This standard does not specify an exact number of 497 retransmits to attempt before backing off, but 2-3 seems 498 appropriate. 500 4.4. Record Payload Protection 502 Like TLS, DTLS transmits data as a series of protected records. The 503 rest of this section describes the details of that format. 505 4.4.1. Anti-Replay 507 DTLS records contain a sequence number to provide replay protection. 508 Sequence number verification SHOULD be performed using the following 509 sliding window procedure, borrowed from Section 3.4.3 of [RFC4303]. 511 The receiver packet counter for this session MUST be initialized to 512 zero when the session is established. For each received record, the 513 receiver MUST verify that the record contains a sequence number that 514 does not duplicate the sequence number of any other record received 515 during the life of this session. This SHOULD be the first check 516 applied to a packet after it has been matched to a session, to speed 517 rejection of duplicate records. 519 Duplicates are rejected through the use of a sliding receive window. 520 (How the window is implemented is a local matter, but the following 521 text describes the functionality that the implementation must 522 exhibit.) A minimum window size of 32 MUST be supported, but a 523 window size of 64 is preferred and SHOULD be employed as the default. 524 Another window size (larger than the minimum) MAY be chosen by the 525 receiver. (The receiver does not notify the sender of the window 526 size.) 528 The "right" edge of the window represents the highest validated 529 sequence number value received on this session. Records that contain 530 sequence numbers lower than the "left" edge of the window are 531 rejected. Packets falling within the window are checked against a 532 list of received packets within the window. An efficient means for 533 performing this check, based on the use of a bit mask, is described 534 in Section 3.4.3 of [RFC4303]. 536 If the received record falls within the window and is new, or if the 537 packet is to the right of the window, then the receiver proceeds to 538 MAC verification. If the MAC validation fails, the receiver MUST 539 discard the received record as invalid. The receive window is 540 updated only if the MAC verification succeeds. 542 4.4.2. Handling Invalid Records 544 Unlike TLS, DTLS is resilient in the face of invalid records (e.g., 545 invalid formatting, length, MAC, etc.). In general, invalid records 546 SHOULD be silently discarded, thus preserving the association; 547 however, an error MAY be logged for diagnostic purposes. 548 Implementations which choose to generate an alert instead, MUST 549 generate error alerts to avoid attacks where the attacker repeatedly 550 probes the implementation to see how it responds to various types of 551 error. Note that if DTLS is run over UDP, then any implementation 552 which does this will be extremely susceptible to denial-of-service 553 (DoS) attacks because UDP forgery is so easy. Thus, this practice is 554 NOT RECOMMENDED for such transports. 556 If DTLS is being carried over a transport that is resistant to 557 forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts 558 because an attacker will have difficulty forging a datagram that will 559 not be rejected by the transport layer. 561 5. The DTLS Handshake Protocol 563 DTLS 1.3 re-uses the TLS 1.3 handshake messages and flows, with the 564 following changes: 566 1. To handle message loss, reordering, and fragmentation 567 modifications to the handshake header are necessary. 569 2. Retransmission timers are introduced to handle message loss. 571 3. The TLS 1.3 KeyUpdate message is not used in DTLS 1.3 for re- 572 keying. 574 4. A new ACK message has been added for reliable message delivery of 575 certain handshake messages. 577 Note that TLS 1.3 already supports a cookie extension, which used to 578 prevent denial-of-service attacks. This DoS prevention mechanism is 579 described in more detail below since UDP-based protocols are more 580 vulnerable to amplification attacks than a connection-oriented 581 transport like TCP that performs return-routability checks as part of 582 the connection establishment. 584 With these exceptions, the DTLS message formats, flows, and logic are 585 the same as those of TLS 1.3. 587 5.1. Denial-of-Service Countermeasures 589 Datagram security protocols are extremely susceptible to a variety of 590 DoS attacks. Two attacks are of particular concern: 592 1. An attacker can consume excessive resources on the server by 593 transmitting a series of handshake initiation requests, causing 594 the server to allocate state and potentially to perform expensive 595 cryptographic operations. 597 2. An attacker can use the server as an amplifier by sending 598 connection initiation messages with a forged source of the 599 victim. The server then sends its response to the victim 600 machine, thus flooding it. Depending on the selected ciphersuite 601 this response message can be quite large, as it is the case for a 602 Certificate message. 604 In order to counter both of these attacks, DTLS borrows the stateless 605 cookie technique used by Photuris [RFC2522] and IKE [RFC5996]. When 606 the client sends its ClientHello message to the server, the server 607 MAY respond with a HelloRetryRequest message. The HelloRetryRequest 608 message, as well as the cookie extension, is defined in TLS 1.3. The 609 HelloRetryRequest message contains a stateless cookie generated using 610 the technique of [RFC2522]. The client MUST retransmit the 611 ClientHello with the cookie added as an extension. The server then 612 verifies the cookie and proceeds with the handshake only if it is 613 valid. This mechanism forces the attacker/client to be able to 614 receive the cookie, which makes DoS attacks with spoofed IP addresses 615 difficult. This mechanism does not provide any defence against DoS 616 attacks mounted from valid IP addresses. 618 The DTLS 1.3 specification changes the way how cookies are exchanged 619 compared to DTLS 1.2. DTLS 1.3 re-uses the HelloRetryRequest message 620 and conveys the cookie to the client via an extension. The client 621 receiving the cookie uses the same extension to place the cookie 622 subsequently into a ClientHello message. 623 DTLS 1.2 on the other hand used a separate message, namely the 624 HelloVerifyRequest, to pass a cookie to the client and did not 625 utilize the extension mechanism. For backwards compatibility reason 626 the cookie field in the ClientHello is present in DTLS 1.3 but is 627 ignored by a DTLS 1.3 compliant server implementation. 629 The exchange is shown in Figure 2. Note that the figure focuses on 630 the cookie exchange; all other extensions are omitted. 632 Client Server 633 ------ ------ 634 ClientHello ------> 636 <----- HelloRetryRequest 637 + cookie 639 ClientHello ------> 640 + cookie 642 [Rest of handshake] 644 Figure 2: DTLS Exchange with HelloRetryRequest contain the Cookie 645 Extension 647 The cookie extension is defined in Section 4.2.2 of 648 [I-D.ietf-tls-tls13]. When sending the initial ClientHello, the 649 client does not have a cookie yet. In this case, the cookie 650 extension is omitted and the legacy_cookie field in the ClientHello 651 message SHOULD be set to a zero length vector (i.e., a single zero 652 byte length field) and MUST be ignored by a server negotiating DTLS 653 1.3. 655 When responding to a HelloRetryRequest, the client MUST create a new 656 ClientHello message following the description in Section 4.1.2 of 657 [I-D.ietf-tls-tls13]. 659 The server SHOULD use information received in the ClientHello to 660 generate its cookie, such as version, random, ciphersuites. The 661 server MUST use the same version number in the HelloRetryRequest that 662 it would use when sending a ServerHello. Upon receipt of the 663 ServerHello, the client MUST verify that the server version values 664 match and MUST terminate the connection with an "illegal_parameter" 665 alert otherwise. 667 If the HelloRetryRequest message is used, the initial ClientHello and 668 the HelloRetryRequest are included in the calculation of the 669 handshake_messages (for the CertificateVerify message) and 670 verify_data (for the Finished message). However, the computation of 671 the message hash for the HelloRetryRequest is done according to the 672 description in Section 4.4.1 of [I-D.ietf-tls-tls13]. 674 The handshake transcript is not reset with the second ClientHello and 675 a stateless server-cookie implementation requires the transcript of 676 the HelloRetryRequest to be stored in the cookie or the internal 677 state of the hash algorithm, since only the hash of the transcript is 678 required for the handshake to complete. 680 When the second ClientHello is received, the server can verify that 681 the cookie is valid and that the client can receive packets at the 682 given IP address. 684 One potential attack on this scheme is for the attacker to collect a 685 number of cookies from different addresses and then reuse them to 686 attack the server. The server can defend against this attack by 687 changing the secret value frequently, thus invalidating those 688 cookies. If the server wishes that legitimate clients be able to 689 handshake through the transition (e.g., they received a cookie with 690 Secret 1 and then sent the second ClientHello after the server has 691 changed to Secret 2), the server can have a limited window during 692 which it accepts both secrets. [RFC5996] suggests adding a key 693 identifier to cookies to detect this case. An alternative approach 694 is simply to try verifying with both secrets. It is RECOMMENDED that 695 servers implement a key rotation scheme that allows the server to 696 manage keys with overlapping lifetime. 698 Alternatively, the server can store timestamps in the cookie and 699 reject those cookies that were not generated within a certain amount 700 of time. 702 DTLS servers SHOULD perform a cookie exchange whenever a new 703 handshake is being performed. If the server is being operated in an 704 environment where amplification is not a problem, the server MAY be 705 configured not to perform a cookie exchange. The default SHOULD be 706 that the exchange is performed, however. In addition, the server MAY 707 choose not to do a cookie exchange when a session is resumed. 708 Clients MUST be prepared to do a cookie exchange with every 709 handshake. 711 If a server receives a ClientHello with an invalid cookie, it MUST 712 NOT respond with a HelloRetryRequest. Restarting the handshake from 713 scratch, without a cookie, allows the client to recover from a 714 situation where it obtained a cookie that cannot be verified by the 715 server. As described in Section 4.1.4 of 716 [I-D.ietf-tls-tls13],clients SHOULD also abort the handshake with an 717 "unexpected_message" alert in response to any second 718 HelloRetryRequest which was sent in the same connection (i.e., where 719 the ClientHello was itself in response to a HelloRetryRequest). 721 5.2. DTLS Handshake Message Format 723 In order to support message loss, reordering, and message 724 fragmentation, DTLS modifies the TLS 1.3 handshake header: 726 enum { 727 hello_request_RESERVED(0), 728 client_hello(1), 729 server_hello(2), 730 hello_verify_request_RESERVED(3), 731 new_session_ticket(4), 732 end_of_early_data(5), 733 hello_retry_request(6), 734 encrypted_extensions(8), 735 certificate(11), 736 server_key_exchange_RESERVED(12), 737 certificate_request(13), 738 server_hello_done_RESERVED(14), 739 certificate_verify(15), 740 client_key_exchange_RESERVED(16), 741 finished(20), 742 key_update_RESERVED(24), 743 ack([[TBD RFC Editor -- Proposal: 25]]), 744 message_hash(254), 745 (255) 746 } HandshakeType; 748 struct { 749 HandshakeType msg_type; /* handshake type */ 750 uint24 length; /* bytes in message */ 751 uint16 message_seq; /* DTLS-required field */ 752 uint24 fragment_offset; /* DTLS-required field */ 753 uint24 fragment_length; /* DTLS-required field */ 754 select (HandshakeType) { 755 case client_hello: ClientHello; 756 case server_hello: ServerHello; 757 case end_of_early_data: EndOfEarlyData; 758 case hello_retry_request: HelloRetryRequest; 759 case encrypted_extensions: EncryptedExtensions; 760 case certificate_request: CertificateRequest; 761 case certificate: Certificate; 762 case certificate_verify: CertificateVerify; 763 case finished: Finished; 764 case new_session_ticket: NewSessionTicket; 765 case key_update: KeyUpdate; /* reserved */ 766 case ack: ACK; /* DTLS-required field */ 767 } body; 768 } Handshake; 770 In addition to the handshake messages that are deprecated by the TLS 771 1.3 specification DTLS 1.3 furthermore deprecates the 772 HelloVerifyRequest message originally defined in DTLS 1.0. DTLS 773 1.3-compliant implements MUST NOT use the HelloVerifyRequest to 774 execute a return-routability check. A dual-stack DTLS 1.2/DTLS 1.3 775 client MUST, however, be prepared to interact with a DTLS 1.2 server. 777 A DTLS 1.3 MUST NOT use the KeyUpdate message to change keying 778 material used for the protection of traffic data. Instead the epoch 779 field is used, which is explained in Section 5.9. 781 The format of the ClientHello used by a DTLS 1.3 client differs from 782 the TLS 1.3 ClientHello format as shown below. 784 uint16 ProtocolVersion; 785 opaque Random[32]; 787 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 789 struct { 790 ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2 791 Random random; 792 opaque legacy_session_id<0..32>; 793 opaque legacy_cookie<0..2^8-1>; // DTLS 794 CipherSuite cipher_suites<2..2^16-2>; 795 opaque legacy_compression_methods<1..2^8-1>; 796 Extension extensions<0..2^16-1>; 797 } ClientHello; 799 legacy_version: In previous versions of DTLS, this field was used 800 for version negotiation and represented the highest version number 801 supported by the client. Experience has shown that many servers 802 do not properly implement version negotiation, leading to "version 803 intolerance" in which the server rejects an otherwise acceptable 804 ClientHello with a version number higher than it supports. In 805 DTLS 1.3, the client indicates its version preferences in the 806 "supported_versions" extension (see Section 4.2.1 of 807 [I-D.ietf-tls-tls13]) and the legacy_version field MUST be set to 808 {254, 253}, which was the version number for DTLS 1.2. 810 random: Same as for TLS 1.3 812 legacy_session_id: Same as for TLS 1.3 814 legacy_cookie: A DTLS 1.3-only client MUST set the legacy_cookie 815 field to zero length. 817 cipher_suites: Same as for TLS 1.3 818 legacy_compression_methods: Same as for TLS 1.3 820 extensions: Same as for TLS 1.3 822 The first message each side transmits in each handshake always has 823 message_seq = 0. Whenever a new message is generated, the 824 message_seq value is incremented by one. When a message is 825 retransmitted, the old message_seq value is re-used, i.e., not 826 incremented. 828 Here is an example: 830 Client Server 831 ------ ------ 833 ClientHello 834 (message_seq=0) 835 --------> 837 X<---- HelloRetryRequest 838 (lost) (message_seq=0) 840 [Timer Expires] 842 ClientHello 843 (message_seq=0) 844 (retransmit) --------> 846 <-------- HelloRetryRequest 847 (message_seq=0) 849 ClientHello --------> 850 (message_seq=1) 851 +cookie 853 <-------- ServerHello 854 (message_seq=1) 855 EncryptedExtensions 856 (message_seq=2) 857 Certificate 858 (message_seq=3) 859 CertificateVerify 860 (message_seq=4) 861 Finished 862 (message_seq=5) 864 Certificate --------> 865 (message_seq=2) 866 CertificateVerify 867 (message_seq=3) 868 Finished 869 (message_seq=4) 871 <-------- Ack 872 (message_seq=6) 874 Figure 3: Example DTLS Exchange illustrating Message Loss 876 From the perspective of the DTLS record layer, the retransmission is 877 a new record. This record will have a new 878 DTLSPlaintext.sequence_number value. 880 DTLS implementations maintain (at least notionally) a 881 next_receive_seq counter. This counter is initially set to zero. 882 When a message is received, if its sequence number matches 883 next_receive_seq, next_receive_seq is incremented and the message is 884 processed. If the sequence number is less than next_receive_seq, the 885 message MUST be discarded. If the sequence number is greater than 886 next_receive_seq, the implementation SHOULD queue the message but MAY 887 discard it. (This is a simple space/bandwidth tradeoff). 889 5.3. ACK Message 891 struct {} ACK; 893 The ACK handshake message is used by an endpoint to respond to a 894 message where the TLS 1.3 handshake does not foresee such return 895 message. With the use of the ACK message the sender is able to 896 determine whether a transmitted request has been lost and needs to be 897 retransmitted. Since the ACK message does not contain any 898 correlation information the sender MUST only have one such message 899 outstanding at a time. 901 The ACK message uses a handshake content type and is encrypted under 902 the appropriate application traffic key. [[OPEN ISSUE: It seems odd 903 to have the ACK that responds to CFIN encrypted under the application 904 key. Also, what do you do about ACKs that have to deal with key 905 changes.]] 907 5.4. Handshake Message Fragmentation and Reassembly 909 Each DTLS message MUST fit within a single transport layer datagram. 910 However, handshake messages are potentially bigger than the maximum 911 record size. Therefore, DTLS provides a mechanism for fragmenting a 912 handshake message over a number of records, each of which can be 913 transmitted separately, thus avoiding IP fragmentation. 915 When transmitting the handshake message, the sender divides the 916 message into a series of N contiguous data ranges. These ranges MUST 917 NOT be larger than the maximum handshake fragment size and MUST 918 jointly contain the entire handshake message. The ranges MUST NOT 919 overlap. The sender then creates N handshake messages, all with the 920 same message_seq value as the original handshake message. Each new 921 message is labeled with the fragment_offset (the number of bytes 922 contained in previous fragments) and the fragment_length (the length 923 of this fragment). The length field in all messages is the same as 924 the length field of the original message. An unfragmented message is 925 a degenerate case with fragment_offset=0 and fragment_length=length. 927 When a DTLS implementation receives a handshake message fragment, it 928 MUST buffer it until it has the entire handshake message. DTLS 929 implementations MUST be able to handle overlapping fragment ranges. 930 This allows senders to retransmit handshake messages with smaller 931 fragment sizes if the PMTU estimate changes. 933 Note that as with TLS, multiple handshake messages may be placed in 934 the same DTLS record, provided that there is room and that they are 935 part of the same flight. Thus, there are two acceptable ways to pack 936 two DTLS messages into the same datagram: in the same record or in 937 separate records. 939 5.5. Timeout and Retransmission 941 DTLS messages are grouped into a series of message flights, according 942 to the diagrams below. Although each flight of messages may consist 943 of a number of messages, they should be viewed as monolithic for the 944 purpose of timeout and retransmission. 946 Client Server 948 ClientHello +----------+ 949 + key_share* | Flight 1 | 950 + pre_shared_key* --------> +----------+ 952 +----------+ 953 <-------- HelloRetryRequest | Flight 2 | 954 + cookie +----------+ 956 ClientHello +----------+ 957 + key_share* | Flight 3 | 958 + pre_shared_key* --------> +----------+ 959 + cookie 961 ServerHello 962 + key_share* 963 + pre_shared_key* +----------+ 964 {EncryptedExtensions} | Flight 4 | 965 {CertificateRequest*} +----------+ 966 {Certificate*} 967 {CertificateVerify*} 968 <-------- {Finished} 969 [Application Data*] 971 {Certificate*} +----------+ 972 {CertificateVerify*} | Flight 5 | 973 {Finished} --------> +----------+ 974 [Application Data] 976 +----------+ 977 <-------- [Ack] | Flight 6 | 978 [Application Data*] +----------+ 980 [Application Data] <-------> [Application Data] 982 Figure 4: Message Flights for full DTLS Handshake (with Cookie 983 Exchange) 985 ClientHello +----------+ 986 + pre_shared_key | Flight 1 | 987 + key_share* --------> +----------+ 989 ServerHello 990 + pre_shared_key +----------+ 991 + key_share* | Flight 2 | 992 {EncryptedExtensions} +----------+ 993 <-------- {Finished} 994 [Application Data*] 995 +----------+ 996 {Finished} --------> | Flight 3 | 997 [Application Data*] +----------+ 999 +----------+ 1000 <-------- [Ack] | Flight 4 | 1001 [Application Data*] +----------+ 1003 [Application Data] <-------> [Application Data] 1005 Figure 5: Message Flights for Resumption and PSK Handshake (without 1006 Cookie Exchange) 1008 Client Server 1010 ClientHello 1011 + early_data 1012 + psk_key_exchange_modes +----------+ 1013 + key_share* | Flight 1 | 1014 + pre_shared_key +----------+ 1015 (Application Data*) --------> 1017 ServerHello 1018 + pre_shared_key 1019 + key_share* +----------+ 1020 {EncryptedExtensions} | Flight 2 | 1021 {Finished} +----------+ 1022 <-------- [Application Data*] 1024 +----------+ 1025 (EndOfEarlyData) | Flight 3 | 1026 {Finished} --------> +----------+ 1027 [Application Data*] 1028 +----------+ 1029 <-------- [Ack] | Flight 4 | 1030 [Application Data*] +----------+ 1032 [Application Data] <-------> [Application Data] 1034 Figure 6: Message Flights for the Zero-RTT Handshake 1036 Client Server 1038 +----------+ 1039 <-------- [NewSessionTicket] | Flight 1 | 1040 +----------+ 1042 +----------+ 1043 [Ack] --------> | Flight 2 | 1044 +----------+ 1046 Figure 7: Message Flights for New Session Ticket Message 1048 Client Server 1050 +----------+ 1051 <-------- [CertificateRequest] | Flight 1 | 1052 +----------+ 1054 [Certificate] +----------+ 1055 [CertificateVerify] | Flight 2 | 1056 [Finished] --------> +----------+ 1058 Figure 8: Message Flights for Post-Handshake Authentication (Success) 1060 Client Server 1062 +----------+ 1063 <-------- [CertificateRequest] | Flight 1 | 1064 +----------+ 1066 [Certificate] +----------+ 1067 [Finished] --------> | Flight 2 | 1068 +----------+ 1070 Figure 9: Message Flights for Post-Handshake Authentication (Decline) 1072 Note: The application data sent by the client is not included in the 1073 timeout and retransmission calculation. 1075 5.5.1. State Machine 1077 DTLS uses a simple timeout and retransmission scheme with the state 1078 machine shown in Figure 10. Because DTLS clients send the first 1079 message (ClientHello), they start in the PREPARING state. DTLS 1080 servers start in the WAITING state, but with empty buffers and no 1081 retransmit timer. 1083 +-----------+ 1084 | PREPARING | 1085 +---> | | 1086 | | | 1087 | +-----------+ 1088 | | 1089 | | Buffer next flight 1090 | | 1091 | \|/ 1092 | +-----------+ 1093 | | | 1094 | | SENDING |<------------------+ 1095 | | | | 1096 | +-----------+ | 1097 Receive | | | 1098 next | | Send flight | 1099 flight | +--------+ | 1100 | | | Set retransmit timer | 1101 | | \|/ | 1102 | | +-----------+ | 1103 | | | | | 1104 +--)--| WAITING |-------------------+ 1105 | | | | Timer expires | 1106 | | +-----------+ | 1107 | | | | 1108 | | | | 1109 | | +------------------------+ 1110 | | Read retransmit 1111 Receive | | 1112 last | | 1113 flight | | 1114 | | 1115 \|/\|/ 1117 +-----------+ 1118 | | 1119 | FINISHED | 1120 | | 1121 +-----------+ 1122 | /|\ 1123 | | 1124 | | 1125 +---+ 1127 Server read retransmit 1128 Retransmit ACK 1130 Figure 10: DTLS Timeout and Retransmission State Machine 1132 The state machine has three basic states. 1134 In the PREPARING state, the implementation does whatever computations 1135 are necessary to prepare the next flight of messages. It then 1136 buffers them up for transmission (emptying the buffer first) and 1137 enters the SENDING state. 1139 In the SENDING state, the implementation transmits the buffered 1140 flight of messages. Once the messages have been sent, the 1141 implementation then enters the FINISHED state if this is the last 1142 flight in the handshake. Or, if the implementation expects to 1143 receive more messages, it sets a retransmit timer and then enters the 1144 WAITING state. 1146 There are three ways to exit the WAITING state: 1148 1. The retransmit timer expires: the implementation transitions to 1149 the SENDING state, where it retransmits the flight, resets the 1150 retransmit timer, and returns to the WAITING state. 1152 2. The implementation reads a retransmitted flight from the peer: 1153 the implementation transitions to the SENDING state, where it 1154 retransmits the flight, resets the retransmit timer, and returns 1155 to the WAITING state. The rationale here is that the receipt of 1156 a duplicate message is the likely result of timer expiry on the 1157 peer and therefore suggests that part of one's previous flight 1158 was lost. 1160 3. The implementation receives the next flight of messages: if this 1161 is the final flight of messages, the implementation transitions 1162 to FINISHED. If the implementation needs to send a new flight, 1163 it transitions to the PREPARING state. Partial reads (whether 1164 partial messages or only some of the messages in the flight) do 1165 not cause state transitions or timer resets. 1167 Because DTLS clients send the first message (ClientHello), they 1168 start in the PREPARING state. DTLS servers start in the WAITING 1169 state, but with empty buffers and no retransmit timer. 1171 In addition, for at least twice the default Maximum Segment 1172 Lifetime (MSL) defined for [RFC0793], when in the FINISHED state, 1173 the server MUST respond to retransmission of the client's second 1174 flight with a retransmit of its ACK. 1176 Note that because of packet loss, it is possible for one side to 1177 be sending application data even though the other side has not 1178 received the first side's Finished message. Implementations MUST 1179 either discard or buffer all application data packets for the new 1180 epoch until they have received the Finished message for that 1181 epoch. Implementations MAY treat receipt of application data 1182 with a new epoch prior to receipt of the corresponding Finished 1183 message as evidence of reordering or packet loss and retransmit 1184 their final flight immediately, shortcutting the retransmission 1185 timer. 1187 5.5.2. Timer Values 1189 Though timer values are the choice of the implementation, mishandling 1190 of the timer can lead to serious congestion problems; for example, if 1191 many instances of a DTLS time out early and retransmit too quickly on 1192 a congested link. Implementations SHOULD use an initial timer value 1193 of 100 msec (the minimum defined in RFC 6298 [RFC6298]) and double 1194 the value at each retransmission, up to no less than the RFC 6298 1195 maximum of 60 seconds. Application specific profiles, such as those 1196 used for the Internet of Things environment, may recommend longer 1197 timer values. Note that we recommend a 100 msec timer rather than 1198 the 3-second RFC 6298 default in order to improve latency for time- 1199 sensitive applications. Because DTLS only uses retransmission for 1200 handshake and not dataflow, the effect on congestion should be 1201 minimal. 1203 Implementations SHOULD retain the current timer value until a 1204 transmission without loss occurs, at which time the value may be 1205 reset to the initial value. After a long period of idleness, no less 1206 than 10 times the current timer value, implementations may reset the 1207 timer to the initial value. One situation where this might occur is 1208 when a rehandshake is used after substantial data transfer. 1210 5.6. CertificateVerify and Finished Messages 1212 CertificateVerify and Finished messages have the same format as in 1213 TLS 1.3. Hash calculations include entire handshake messages, 1214 including DTLS-specific fields: message_seq, fragment_offset, and 1215 fragment_length. However, in order to remove sensitivity to 1216 handshake message fragmentation, the CertificateVerify and the 1217 Finished messages MUST be computed as if each handshake message had 1218 been sent as a single fragment following the algorithm described in 1219 Section 4.4.3 and Section 4.4.4 of [I-D.ietf-tls-tls13], 1220 respectively. 1222 5.7. Alert Messages 1224 Note that Alert messages are not retransmitted at all, even when they 1225 occur in the context of a handshake. However, a DTLS implementation 1226 which would ordinarily issue an alert SHOULD generate a new alert 1227 message if the offending record is received again (e.g., as a 1228 retransmitted handshake message). Implementations SHOULD detect when 1229 a peer is persistently sending bad messages and terminate the local 1230 connection state after such misbehavior is detected. 1232 5.8. Establishing New Associations with Existing Parameters 1234 If a DTLS client-server pair is configured in such a way that 1235 repeated connections happen on the same host/port quartet, then it is 1236 possible that a client will silently abandon one connection and then 1237 initiate another with the same parameters (e.g., after a reboot). 1238 This will appear to the server as a new handshake with epoch=0. In 1239 cases where a server believes it has an existing association on a 1240 given host/port quartet and it receives an epoch=0 ClientHello, it 1241 SHOULD proceed with a new handshake but MUST NOT destroy the existing 1242 association until the client has demonstrated reachability either by 1243 completing a cookie exchange or by completing a complete handshake 1244 including delivering a verifiable Finished message. After a correct 1245 Finished message is received, the server MUST abandon the previous 1246 association to avoid confusion between two valid associations with 1247 overlapping epochs. The reachability requirement prevents off-path/ 1248 blind attackers from destroying associations merely by sending forged 1249 ClientHellos. 1251 5.9. Epoch Values and Rekeying 1253 A recipient of a DTLS message needs to select the correct keying 1254 material in order to process an incoming message. With the 1255 possibility of message loss and re-order an identifier is needed to 1256 determine which cipher state has been used to protect the record 1257 payload. The epoch value fulfills this role in DTLS. In addition to 1258 the key derivation steps described in Section 7 of 1259 [I-D.ietf-tls-tls13] triggered by the states during the handshake a 1260 sender may want to rekey at any time during the lifetime of the 1261 connection and has to have a way to indicate that it is updating its 1262 sending cryptographic keys. 1264 This version of DTLS assigns dedicated epoch values to messages in 1265 the protocol exchange to allow identification of the correct cipher 1266 state: 1268 - epoch value (0) is used with unencrypted messages. There are 1269 three unencrypted messages in DTLS, namely ClientHello, 1270 ServerHello, and HelloRetryRequest. 1272 - epoch value (1) is used for messages protected using keys derived 1273 from early_traffic_secret. This includes early data sent by the 1274 client and the EndOfEarlyData message. 1276 - epoch value (2) is used for messages protected using keys derived 1277 from the handshake_traffic_secret. Messages transmitted during 1278 the initial handshake, such as EncryptedExtensions, 1279 CertificateRequest, Certificate, CertificateVerify, and Finished 1280 belong to this category. Note, however, post-handshake are 1281 protected under the appropriate application traffic key and are 1282 not included in this category. 1284 - epoch value (3) is used for payloads protected using keys derived 1285 from the initial traffic_secret_0. This may include handshake 1286 messages, such as post-handshake messages (e.g., a 1287 NewSessionTicket message). 1289 - epoch value (4 to 2^16-1) is used for payloads protected using 1290 keys from the traffic_secret_N (N>0). 1292 Using these reserved epoch values a receiver knows what cipher state 1293 has been used to encrypt and integrity protect a message. 1294 Implementations that receive a payload with an epoch value for which 1295 no corresponding cipher state can be determined MUST generate a 1296 "unexpected_message" alert. For example, client incorrectly uses 1297 epoch value 5 when sending early application data in a 0-RTT 1298 exchange. A server will not be able to compute the appropriate keys 1299 and will therefore have to respond with an alert. 1301 Increasing the epoch value by a sender (starting with value 4 1302 upwards) corresponds semantically to rekeying using the KeyUpdate 1303 message in TLS 1.3. Instead of utilizing an dedicated message in 1304 DTLS 1.3 the sender uses an increase in the epoch value to signal 1305 rekeying. Hence, a sender that decides to increment the epoch value 1306 MUST send all its traffic using the next generation of keys, computed 1307 as described in Section 7.2 of [I-D.ietf-tls-tls13]. Upon receiving 1308 a payload with such a new epoch value, the receiver MUST update their 1309 receiving keys and if they have not already updated their sending 1310 state up to or past the then current receiving generation MUST send 1311 messages with the new epoch value prior to sending any other 1312 messages. For epoch values lower than 4 the key schedule described 1313 in Section 7.1 of [I-D.ietf-tls-tls13] is applicable. As a 1314 difference to the functionality of the KeyUpdate in TLS 1.3 the 1315 sender forces the receiver to increase the epoch value for outgoing 1316 data as well. 1318 Note that epoch values do not wrap. If a DTLS implementation would 1319 need to wrap the epoch value, it MUST terminate the connection. 1321 The traffic key calculation is described in Section 7.3 of 1322 [I-D.ietf-tls-tls13]. 1324 Figure 11 illustrates the epoch values in an example DTLS handshake. 1326 Client Server 1327 ------ ------ 1329 ClientHello 1330 (epoch=0) 1331 --------> 1333 <-------- HelloRetryRequest 1334 (epoch=0) 1336 ClientHello --------> 1337 (epoch=0) 1339 <-------- ServerHello 1340 (epoch=0) 1341 {EncryptedExtensions} 1342 (epoch=2) 1343 {Certificate} 1344 (epoch=2) 1345 {CertificateVerify} 1346 (epoch=2) 1347 {Finished} 1348 (epoch=2) 1350 {Certificate} --------> 1351 (epoch=2) 1352 {CertificateVerify} 1353 (epoch=2) 1354 {Finished} 1355 (epoch=2) 1357 <-------- [Ack] 1358 (epoch=3) 1360 [Application Data] --------> 1361 (epoch=3) 1363 <-------- [Application Data] 1364 (epoch=3) 1366 Some time later ... 1367 (Post-Handshake Message Exchange) 1369 <-------- [NewSessionTicket] 1370 (epoch=3) 1372 [Ack] --------> 1373 (epoch=3) 1375 Some time later ... 1376 (Rekeying) 1378 <-------- [Application Data] 1379 (epoch=4) 1380 [Application Data] --------> 1381 (epoch=4) 1383 Figure 11: Example DTLS Exchange with Epoch Information 1385 6. Application Data Protocol 1387 Application data messages are carried by the record layer and are 1388 fragmented and encrypted based on the current connection state. The 1389 messages are treated as transparent data to the record layer. 1391 7. Security Considerations 1393 Security issues are discussed primarily in [I-D.ietf-tls-tls13]. 1395 The primary additional security consideration raised by DTLS is that 1396 of denial of service. DTLS includes a cookie exchange designed to 1397 protect against denial of service. However, implementations that do 1398 not use this cookie exchange are still vulnerable to DoS. In 1399 particular, DTLS servers that do not use the cookie exchange may be 1400 used as attack amplifiers even if they themselves are not 1401 experiencing DoS. Therefore, DTLS servers SHOULD use the cookie 1402 exchange unless there is good reason to believe that amplification is 1403 not a threat in their environment. Clients MUST be prepared to do a 1404 cookie exchange with every handshake. 1406 Unlike TLS implementations, DTLS implementations SHOULD NOT respond 1407 to invalid records by terminating the connection. 1409 8. Changes to DTLS 1.2 1411 Since TLS 1.3 introduce a large number of changes to TLS 1.2, the 1412 list of changes from DTLS 1.2 to DTLS 1.3 is equally large. For this 1413 reason this section focuses on the most important changes only. 1415 - New handshake pattern, which leads to a shorter message exchange 1417 - Support for AEAD-only ciphers 1419 - HelloRetryRequest of TLS 1.3 used instead of HelloVerifyRequest 1420 - More flexible ciphersuite negotiation 1422 - New session resumption mechanism 1424 - PSK authentication redefined 1426 - New key derivation hierarchy utilizing a new key derivation 1427 construct 1429 - Removed support for weaker and older cryptographic algorithms 1431 - Improved version negotation 1433 9. IANA Considerations 1435 IANA is requested to allocate a new value in the TLS HandshakeType 1436 Registry for the ACK message defined in Section 5.3. 1438 10. References 1440 10.1. Normative References 1442 [I-D.ietf-tls-tls13] 1443 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1444 Version 1.3", draft-ietf-tls-tls13-19 (work in progress), 1445 March 2017. 1447 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1448 RFC 793, DOI 10.17487/RFC0793, September 1981, 1449 . 1451 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1452 DOI 10.17487/RFC1191, November 1990, 1453 . 1455 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1456 Requirement Levels", BCP 14, RFC 2119, 1457 DOI 10.17487/RFC2119, March 1997, 1458 . 1460 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1461 Control Message Protocol (ICMPv6) for the Internet 1462 Protocol Version 6 (IPv6) Specification", RFC 4443, 1463 DOI 10.17487/RFC4443, March 2006, 1464 . 1466 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1467 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1468 . 1470 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 1471 "Computing TCP's Retransmission Timer", RFC 6298, 1472 DOI 10.17487/RFC6298, June 2011, 1473 . 1475 10.2. Informative References 1477 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 1478 Protocol", RFC 2522, DOI 10.17487/RFC2522, March 1999, 1479 . 1481 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1482 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1483 . 1485 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1486 Congestion Control Protocol (DCCP)", RFC 4340, 1487 DOI 10.17487/RFC4340, March 2006, 1488 . 1490 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 1491 the Datagram Congestion Control Protocol (DCCP)", 1492 RFC 5238, DOI 10.17487/RFC5238, May 2008, 1493 . 1495 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1496 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1497 RFC 5996, DOI 10.17487/RFC5996, September 2010, 1498 . 1500 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1501 "Recommendations for Secure Use of Transport Layer 1502 Security (TLS) and Datagram Transport Layer Security 1503 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1504 2015, . 1506 10.3. URIs 1508 [1] mailto:tls@ietf.org 1510 Appendix A. History 1512 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 1514 draft-01 - Alignment with version -19 of the TLS 1.3 specification 1516 draft-00 1518 - Initial version using TLS 1.3 as a baseline. 1520 - Use of epoch values instead of KeyUpdate message 1522 - Use of cookie extension instead of cookie field in ClientHello and 1523 HelloVerifyRequest messages 1525 - Added ACK message 1527 - Text about sequence number handling 1529 Appendix B. Working Group Information 1531 The discussion list for the IETF TLS working group is located at the 1532 e-mail address tls@ietf.org [1]. Information on the group and 1533 information on how to subscribe to the list is at 1534 https://www1.ietf.org/mailman/listinfo/tls 1536 Archives of the list can be found at: https://www.ietf.org/mail- 1537 archive/web/tls/current/index.html 1539 Appendix C. Contributors 1541 Many people have contributed to previous DTLS versions and they are 1542 acknowledged in prior versions of DTLS specifications. 1544 For this version of the document we would like to thank: 1546 * Ilari Liusvaara 1547 Independent 1548 ilariliusvaara@welho.com 1550 * Martin Thomson 1551 Mozilla 1552 martin.thomson@gmail.com 1554 Authors' Addresses 1556 Eric Rescorla 1557 RTFM, Inc. 1559 EMail: ekr@rtfm.com 1561 Hannes Tschofenig 1562 ARM Limited 1564 EMail: hannes.tschofenig@arm.com 1566 Nagendra Modadugu 1567 Google, Inc. 1569 EMail: nagendra@cs.stanford.edu