idnits 2.17.1 draft-ietf-tls-dtls13-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC6347, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 29, 2017) is 2312 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 893 -- Looks like a reference, but probably isn't: '2' on line 1764 == Missing Reference: 'Ack' is mentioned on line 1427, but not defined == Missing Reference: 'NewSessionTicket' is mentioned on line 1424, but not defined -- Looks like a reference, but probably isn't: '1' on line 1762 -- Looks like a reference, but probably isn't: '3' on line 1767 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-21 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS E. Rescorla 3 Internet-Draft RTFM, Inc. 4 Obsoletes: 6347 (if approved) H. Tschofenig 5 Intended status: Standards Track ARM Limited 6 Expires: June 2, 2018 N. Modadugu 7 Google, Inc. 8 November 29, 2017 10 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 11 draft-ietf-tls-dtls13-06 13 Abstract 15 This document specifies Version 1.3 of the Datagram Transport Layer 16 Security (DTLS) protocol. DTLS 1.3 allows client/server applications 17 to communicate over the Internet in a way that is designed to prevent 18 eavesdropping, tampering, and message forgery. 20 The DTLS 1.3 protocol is intentionally based on the Transport Layer 21 Security (TLS) 1.3 protocol and provides equivalent security 22 guarantees. Datagram semantics of the underlying transport are 23 preserved by the DTLS protocol. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 2, 2018. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 73 3. DTLS Design Rationale and Overview . . . . . . . . . . . . . 5 74 3.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 6 75 3.1.1. Reordering . . . . . . . . . . . . . . . . . . . . . 6 76 3.1.2. Message Size . . . . . . . . . . . . . . . . . . . . 7 77 3.2. Replay Detection . . . . . . . . . . . . . . . . . . . . 7 78 4. The DTLS Record Layer . . . . . . . . . . . . . . . . . . . . 7 79 4.1. Sequence Number Handling . . . . . . . . . . . . . . . . 9 80 4.1.1. Determining the Header Format . . . . . . . . . . . . 10 81 4.1.2. Reconstructing the Sequence Number and Epoch . . . . 10 82 4.2. Transport Layer Mapping . . . . . . . . . . . . . . . . . 11 83 4.3. PMTU Issues . . . . . . . . . . . . . . . . . . . . . . . 12 84 4.4. Record Payload Protection . . . . . . . . . . . . . . . . 13 85 4.4.1. Anti-Replay . . . . . . . . . . . . . . . . . . . . . 13 86 4.4.2. Handling Invalid Records . . . . . . . . . . . . . . 14 87 5. The DTLS Handshake Protocol . . . . . . . . . . . . . . . . . 14 88 5.1. Denial-of-Service Countermeasures . . . . . . . . . . . . 15 89 5.2. DTLS Handshake Message Format . . . . . . . . . . . . . . 18 90 5.3. ClientHello Message . . . . . . . . . . . . . . . . . . . 20 91 5.4. Handshake Message Fragmentation and Reassembly . . . . . 21 92 5.5. DTLS Handshake Flights . . . . . . . . . . . . . . . . . 22 93 5.6. Timeout and Retransmission . . . . . . . . . . . . . . . 25 94 5.6.1. State Machine . . . . . . . . . . . . . . . . . . . . 25 95 5.6.2. Timer Values . . . . . . . . . . . . . . . . . . . . 27 96 5.7. CertificateVerify and Finished Messages . . . . . . . . . 28 97 5.8. Alert Messages . . . . . . . . . . . . . . . . . . . . . 28 98 5.9. Establishing New Associations with Existing Parameters . 28 99 6. Example of Handshake with Timeout and Retransmission . . . . 29 100 6.1. Epoch Values and Rekeying . . . . . . . . . . . . . . . . 31 101 7. ACK Message . . . . . . . . . . . . . . . . . . . . . . . . . 33 102 7.1. Sending ACKs . . . . . . . . . . . . . . . . . . . . . . 34 103 7.2. Receiving ACKs . . . . . . . . . . . . . . . . . . . . . 35 104 8. Key Updates . . . . . . . . . . . . . . . . . . . . . . . . . 35 105 9. Application Data Protocol . . . . . . . . . . . . . . . . . . 35 106 10. Security Considerations . . . . . . . . . . . . . . . . . . . 36 107 11. Changes to DTLS 1.2 . . . . . . . . . . . . . . . . . . . . . 36 108 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 109 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 110 13.1. Normative References . . . . . . . . . . . . . . . . . . 37 111 13.2. Informative References . . . . . . . . . . . . . . . . . 38 112 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 40 113 Appendix B. Working Group Information . . . . . . . . . . . . . 40 114 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 40 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 117 1. Introduction 119 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH 121 The source for this draft is maintained in GitHub. Suggested changes 122 should be submitted as pull requests at https://github.com/tlswg/ 123 dtls13-spec. Instructions are on that page as well. Editorial 124 changes can be managed in GitHub, but any substantive change should 125 be discussed on the TLS mailing list. 127 The primary goal of the TLS protocol is to provide privacy and data 128 integrity between two communicating peers. The TLS protocol is 129 composed of two layers: the TLS Record Protocol and the TLS Handshake 130 Protocol. However, TLS must run over a reliable transport channel - 131 typically TCP [RFC0793]. 133 There are applications that utilize UDP [RFC0768] as a transport and 134 to offer communication security protection for those applications the 135 Datagram Transport Layer Security (DTLS) protocol has been designed. 136 DTLS is deliberately designed to be as similar to TLS as possible, 137 both to minimize new security invention and to maximize the amount of 138 code and infrastructure reuse. 140 DTLS 1.0 [RFC4347] was originally defined as a delta from TLS 1.1 141 [RFC4346] and DTLS 1.2 [RFC6347] was defined as a series of deltas to 142 TLS 1.2 [RFC5246]. There is no DTLS 1.1; that version number was 143 skipped in order to harmonize version numbers with TLS. This 144 specification describes the most current version of the DTLS protocol 145 aligning with the efforts around TLS 1.3 [I-D.ietf-tls-tls13]. 147 Implementations that speak both DTLS 1.2 and DTLS 1.3 can 148 interoperate with those that speak only DTLS 1.2 (using DTLS 1.2 of 149 course), just as TLS 1.3 implementations can interoperate with TLS 150 1.2 (see Appendix D of [I-D.ietf-tls-tls13] for details). While 151 backwards compatibility with DTLS 1.0 is possible the use of DTLS 1.0 152 is not recommended as explained in Section 3.1.2 of RFC 7525 153 [RFC7525]. 155 2. Conventions and Terminology 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 159 "OPTIONAL" in this document are to be interpreted as described in RFC 160 2119 [RFC2119]. 162 The following terms are used: 164 - client: The endpoint initiating the DTLS connection. 166 - connection: A transport-layer connection between two endpoints. 168 - endpoint: Either the client or server of the connection. 170 - handshake: An initial negotiation between client and server that 171 establishes the parameters of their transactions. 173 - peer: An endpoint. When discussing a particular endpoint, "peer" 174 refers to the endpoint that is remote to the primary subject of 175 discussion. 177 - receiver: An endpoint that is receiving records. 179 - sender: An endpoint that is transmitting records. 181 - session: An association between a client and a server resulting 182 from a handshake. 184 - server: The endpoint which did not initiate the DTLS connection. 186 The reader is assumed to be familiar with the TLS 1.3 specification 187 since this document defined as a delta from TLS 1.3. 189 Figures in this document illustrate various combinations of the DTLS 190 protocol exchanges and the symbols have the following meaning: 192 - '+' indicates noteworthy extensions sent in the previously noted 193 message. 195 - '*' indicates optional or situation-dependent messages/extensions 196 that are not always sent. 198 - '{}' indicates messages protected using keys derived from a 199 [sender]_handshake_traffic_secret. 201 - '[]' indicates messages protected using keys derived from 202 traffic_secret_N. 204 3. DTLS Design Rationale and Overview 206 The basic design philosophy of DTLS is to construct "TLS over 207 datagram transport". Datagram transport does not require nor provide 208 reliable or in-order delivery of data. The DTLS protocol preserves 209 this property for application data. Applications such as media 210 streaming, Internet telephony, and online gaming use datagram 211 transport for communication due to the delay-sensitive nature of 212 transported data. The behavior of such applications is unchanged 213 when the DTLS protocol is used to secure communication, since the 214 DTLS protocol does not compensate for lost or re-ordered data 215 traffic. 217 TLS cannot be used directly in datagram environments for the 218 following five reasons: 220 1. TLS does not allow independent decryption of individual records. 221 Because the integrity check indirectly depends on a sequence 222 number, if record N is not received, then the integrity check on 223 record N+1 will be based on the wrong sequence number and thus 224 will fail. DTLS solves this problem by adding explicit sequence 225 numbers. 227 2. The TLS handshake is a lock-step cryptographic handshake. 228 Messages must be transmitted and received in a defined order; any 229 other order is an error. This is incompatible with reordering 230 and message loss. 232 3. Not all TLS 1.3 handshake messages (such as the NewSessionTicket 233 message) are acknowledged. Hence, a new acknowledgement message 234 has to be added to detect message loss. 236 4. Handshake messages are potentially larger than any given 237 datagram, thus creating the problem of IP fragmentation. 239 5. Datagram transport protocols, like UDP, are susceptible to 240 abusive behavior effecting denial of service attacks against 241 nonparticipants, and require a return-routability check with the 242 help of cookies to be integrated into the handshake. A detailed 243 discussion of countermeasures can be found in Section 5.1. 245 3.1. Packet Loss 247 DTLS uses a simple retransmission timer to handle packet loss. 248 Figure 1 demonstrates the basic concept, using the first phase of the 249 DTLS handshake: 251 Client Server 252 ------ ------ 253 ClientHello ------> 255 X<-- HelloRetryRequest 256 (lost) 258 [Timer Expires] 260 ClientHello ------> 261 (retransmit) 263 Figure 1: DTLS Retransmission Example. 265 Once the client has transmitted the ClientHello message, it expects 266 to see a HelloRetryRequest from the server. However, if the server's 267 message is lost, the client knows that either the ClientHello or the 268 HelloRetryRequest has been lost and retransmits. When the server 269 receives the retransmission, it knows to retransmit. 271 The server also maintains a retransmission timer and retransmits when 272 that timer expires. 274 Note that timeout and retransmission do not apply to the 275 HelloRetryRequest since this would require creating state on the 276 server. The HelloRetryRequest is designed to be small enough that it 277 will not itself be fragmented, thus avoiding concerns about 278 interleaving multiple HelloRetryRequests. 280 3.1.1. Reordering 282 In DTLS, each handshake message is assigned a specific sequence 283 number within that handshake. When a peer receives a handshake 284 message, it can quickly determine whether that message is the next 285 message it expects. If it is, then it processes it. If not, it 286 queues it for future handling once all previous messages have been 287 received. 289 3.1.2. Message Size 291 TLS and DTLS handshake messages can be quite large (in theory up to 292 2^24-1 bytes, in practice many kilobytes). By contrast, UDP 293 datagrams are often limited to less than 1500 bytes if IP 294 fragmentation is not desired. In order to compensate for this 295 limitation, each DTLS handshake message may be fragmented over 296 several DTLS records, each of which is intended to fit in a single IP 297 datagram. Each DTLS handshake message contains both a fragment 298 offset and a fragment length. Thus, a recipient in possession of all 299 bytes of a handshake message can reassemble the original unfragmented 300 message. 302 3.2. Replay Detection 304 DTLS optionally supports record replay detection. The technique used 305 is the same as in IPsec AH/ESP, by maintaining a bitmap window of 306 received records. Records that are too old to fit in the window and 307 records that have previously been received are silently discarded. 308 The replay detection feature is optional, since packet duplication is 309 not always malicious, but can also occur due to routing errors. 310 Applications may conceivably detect duplicate packets and accordingly 311 modify their data transmission strategy. 313 4. The DTLS Record Layer 315 The DTLS record layer is similar to that of TLS 1.3. There are three 316 major changes: 318 1. The DTLSCiphertext structure omits the superfluous version number 319 field 321 2. DTLS adds an explicit epoch and sequence number in the record 322 header. This sequence number allows the recipient to correctly 323 verify the DTLS MAC. 325 3. DTLS adds a short header format (DTLSShortCiphertext) that can be 326 used to reduce overhead once the handshake is complete. 328 The DTLS record formats are shown below. DTLSPlaintext records are 329 used to send unprotected records and DTLSCiphertext or 330 DTLSShortCiphertext are used to send protected records. 332 struct { 333 ContentType type; 334 ProtocolVersion version; 335 uint16 epoch = 0 // DTLS field 336 uint48 sequence_number; // DTLS field 337 uint16 length; 338 opaque fragment[DTLSPlaintext.length]; 339 } DTLSPlaintext; 341 struct { 342 opaque content[DTLSPlaintext.length]; 343 ContentType type; 344 uint8 zeros[length_of_padding]; 345 } DTLSInnerPlaintext; 347 struct { 348 ContentType opaque_type = 23; /* application_data */ 349 uint32 epoch_and_sequence; 350 uint16 length; 351 opaque encrypted_record[length]; 352 } DTLSCiphertext; 354 type: The content type of the record. 356 epoch_and_sequence: The low order two bits of the epoch and the low 357 order 30 bits of the sequence number, laid out as a 32 bit 358 integer. The first 2 bits hold the low order bits from the epoch 359 and the remaining 30 bits hold the low order bits from the 360 sequence number (see Section 4.1.2 for how to use this value). 362 length: Identical to the length field in a TLS 1.3 record. 364 encrypted_record: Identical to the encrypted_record field in a TLS 365 1.3 record. 367 As with previous versions of DTLS, multiple DTLSPlaintext and 368 DTLSCiphertext records can be included in the same underlying 369 transport datagram. 371 The short DTLS header format is: 373 struct { 374 uint16 short_epoch_and_sequence; // 001ESSSS SSSSSSSS 375 opaque encrypted_record[remainder_of_datagram]; 376 } DTLSShortCiphertext; 378 The short_epoch_and_sequence document contains the epoch and sequence 379 packed into a 16 bit integer as follows: 381 - The first three bits are set to 001 in order to allow multiplexing 382 between DTLS and VoIP protocols (STUN, RTP/RTCP, etc.) [RFC7983] 383 and distinguish the short from long header formats. 385 - The fourth bit is the low order bit of the epoch value. 387 - The remaining bits contain the low order 12 bits of the sequence 388 number. 390 In this format, the length field is omitted and therefore the record 391 consumes the entire rest of the datagram in the lower level 392 transport. It is not possible to have multiple DTLSShortCiphertext 393 format records in the same datagram. 395 DTLSShortCiphertext MUST only be used for data which is protected 396 with one of the application_traffic_secret values, and not for either 397 handshake or early data. When using an application_traffic_secret 398 for message protection, Implementations MAY use either DTLSCiphertext 399 or DTLSShortCiphertext at their discretion. 401 4.1. Sequence Number Handling 403 DTLS uses an explicit sequence number, rather than an implicit one, 404 carried in the sequence_number field of the record. Sequence numbers 405 are maintained separately for each epoch, with each sequence_number 406 initially being 0 for each epoch. For instance, if a handshake 407 message from epoch 0 is retransmitted, it might have a sequence 408 number after a message from epoch 1, even if the message from epoch 1 409 was transmitted first. Note that some care needs to be taken during 410 the handshake to ensure that retransmitted messages use the right 411 epoch and keying material. 413 The epoch number is initially zero and is incremented each time 414 keying material changes and a sender aims to rekey. More details are 415 provided in Section 6.1. In order to ensure that any given sequence/ 416 epoch pair is unique, implementations MUST NOT allow the same epoch 417 value to be reused within two times the TCP maximum segment lifetime 418 (MSL). 420 Note that because DTLS records may be reordered, a record from epoch 421 1 may be received after epoch 2 has begun. In general, 422 implementations SHOULD discard packets from earlier epochs, but if 423 packet loss causes noticeable problems they MAY choose to retain 424 keying material from previous epochs for up to the default MSL 425 specified for TCP [RFC0793] to allow for packet reordering. (Note 426 that the intention here is that implementers use the current guidance 427 from the IETF for MSL, not that they attempt to interrogate the MSL 428 that the system TCP stack is using.) Until the handshake has 429 completed, implementations MUST accept packets from the old epoch. 431 Conversely, it is possible for records that are protected by the 432 newly negotiated context to be received prior to the completion of a 433 handshake. For instance, the server may send its Finished message 434 and then start transmitting data. Implementations MAY either buffer 435 or discard such packets, though when DTLS is used over reliable 436 transports (e.g., SCTP), they SHOULD be buffered and processed once 437 the handshake completes. Note that TLS's restrictions on when 438 packets may be sent still apply, and the receiver treats the packets 439 as if they were sent in the right order. In particular, it is still 440 impermissible to send data prior to completion of the first 441 handshake. 443 Implementations MUST either abandon an association or re-key prior to 444 allowing the sequence number to wrap. 446 Implementations MUST NOT allow the epoch to wrap, but instead MUST 447 establish a new association, terminating the old association. 449 4.1.1. Determining the Header Format 451 Implementations can distinguish the three header formats by examining 452 the first byte, which in the DTLSPlaintext and DTLSCiphertext header 453 represents the content type. If the first byte is alert(21), 454 handshake(22), or ack(25), the record MUST be interpreted as a 455 DTLSPlaintext record. If the first byte is application_data(23) then 456 the record MUST be interpreted handled as DTLSCiphertext; the true 457 content type will be inside the protected portion. 459 If the first byte is any other other value, then receivers MUST check 460 to see if the leading bits of the first byte are 001. If so, they 461 MUST process the record as DTLSShortCiphertext. Otherwise, the 462 record MUST be rejected as if it had failed deprotection. 464 4.1.2. Reconstructing the Sequence Number and Epoch 466 When receiving protected DTLS records message, the recipient does not 467 have a full epoch or sequence number value and so there is some 468 opportunity for ambiguity. Because the full epoch and sequence 469 number are used to compute the per-record nonce, failure to 470 reconstruct these values leads to failure to deprotect the record, 471 and so implementations MAY use a mechanism of their choice to 472 determine the full values. This section provides an algorithm which 473 is comparatively simple and which implementations are RECOMMENDED to 474 follow. 476 If the epoch bits match those of the current epoch, then 477 implementations SHOULD reconstruct the sequence number by computing 478 the full sequence number which is numerically closest to one plus the 479 sequence number of the highest successfully deprotected record. 481 If the epoch bits do not match those from the current epoch, then the 482 record is either from a previous epoch or from a future epoch. 483 Implementations SHOULD use the epoch value which would produce a 484 sequence number which is numerically closest to what would be 485 reconstructed for that epoch, as determined by the algorithm in the 486 paragraph above. 488 Note: the DTLSShortCiphertext format does not allow for easy 489 reconstruction of sequence numbers if ~2000 datagrams in sequence are 490 lost. Implementations which may encounter this situation SHOULD use 491 the DTLSCiphertext format. 493 4.2. Transport Layer Mapping 495 Each DTLS record MUST fit within a single datagram. In order to 496 avoid IP fragmentation, clients of the DTLS record layer SHOULD 497 attempt to size records so that they fit within any PMTU estimates 498 obtained from the record layer. 500 Note that unlike IPsec, DTLS records do not contain any association 501 identifiers. Applications must arrange to multiplex between 502 associations. With UDP, the host/port number is used to look up the 503 appropriate security association for incoming records. 505 Multiple DTLS records may be placed in a single datagram. They are 506 simply encoded consecutively. The DTLS record framing is sufficient 507 to determine the boundaries. Note, however, that the first byte of 508 the datagram payload must be the beginning of a record. Records may 509 not span datagrams. 511 Some transports, such as DCCP [RFC4340], provide their own sequence 512 numbers. When carried over those transports, both the DTLS and the 513 transport sequence numbers will be present. Although this introduces 514 a small amount of inefficiency, the transport layer and DTLS sequence 515 numbers serve different purposes; therefore, for conceptual 516 simplicity, it is superior to use both sequence numbers. 518 Some transports provide congestion control for traffic carried over 519 them. If the congestion window is sufficiently narrow, DTLS 520 handshake retransmissions may be held rather than transmitted 521 immediately, potentially leading to timeouts and spurious 522 retransmission. When DTLS is used over such transports, care should 523 be taken not to overrun the likely congestion window. [RFC5238] 524 defines a mapping of DTLS to DCCP that takes these issues into 525 account. 527 4.3. PMTU Issues 529 In general, DTLS's philosophy is to leave PMTU discovery to the 530 application. However, DTLS cannot completely ignore PMTU for three 531 reasons: 533 - The DTLS record framing expands the datagram size, thus lowering 534 the effective PMTU from the application's perspective. 536 - In some implementations, the application may not directly talk to 537 the network, in which case the DTLS stack may absorb ICMP 538 [RFC1191] "Datagram Too Big" indications or ICMPv6 [RFC4443] 539 "Packet Too Big" indications. 541 - The DTLS handshake messages can exceed the PMTU. 543 In order to deal with the first two issues, the DTLS record layer 544 SHOULD behave as described below. 546 If PMTU estimates are available from the underlying transport 547 protocol, they should be made available to upper layer protocols. In 548 particular: 550 - For DTLS over UDP, the upper layer protocol SHOULD be allowed to 551 obtain the PMTU estimate maintained in the IP layer. 553 - For DTLS over DCCP, the upper layer protocol SHOULD be allowed to 554 obtain the current estimate of the PMTU. 556 - For DTLS over TCP or SCTP, which automatically fragment and 557 reassemble datagrams, there is no PMTU limitation. However, the 558 upper layer protocol MUST NOT write any record that exceeds the 559 maximum record size of 2^14 bytes. 561 The DTLS record layer SHOULD allow the upper layer protocol to 562 discover the amount of record expansion expected by the DTLS 563 processing. 565 If there is a transport protocol indication (either via ICMP or via a 566 refusal to send the datagram as in Section 14 of [RFC4340]), then the 567 DTLS record layer MUST inform the upper layer protocol of the error. 569 The DTLS record layer SHOULD NOT interfere with upper layer protocols 570 performing PMTU discovery, whether via [RFC1191] or [RFC4821] 571 mechanisms. In particular: 573 - Where allowed by the underlying transport protocol, the upper 574 layer protocol SHOULD be allowed to set the state of the DF bit 575 (in IPv4) or prohibit local fragmentation (in IPv6). 577 - If the underlying transport protocol allows the application to 578 request PMTU probing (e.g., DCCP), the DTLS record layer should 579 honor this request. 581 The final issue is the DTLS handshake protocol. From the perspective 582 of the DTLS record layer, this is merely another upper layer 583 protocol. However, DTLS handshakes occur infrequently and involve 584 only a few round trips; therefore, the handshake protocol PMTU 585 handling places a premium on rapid completion over accurate PMTU 586 discovery. In order to allow connections under these circumstances, 587 DTLS implementations SHOULD follow the following rules: 589 - If the DTLS record layer informs the DTLS handshake layer that a 590 message is too big, it SHOULD immediately attempt to fragment it, 591 using any existing information about the PMTU. 593 - If repeated retransmissions do not result in a response, and the 594 PMTU is unknown, subsequent retransmissions SHOULD back off to a 595 smaller record size, fragmenting the handshake message as 596 appropriate. This standard does not specify an exact number of 597 retransmits to attempt before backing off, but 2-3 seems 598 appropriate. 600 4.4. Record Payload Protection 602 Like TLS, DTLS transmits data as a series of protected records. The 603 rest of this section describes the details of that format. 605 4.4.1. Anti-Replay 607 DTLS records contain a sequence number to provide replay protection. 608 Sequence number verification SHOULD be performed using the following 609 sliding window procedure, borrowed from Section 3.4.3 of [RFC4303]. 611 The receiver packet counter for this session MUST be initialized to 612 zero when the session is established. For each received record, the 613 receiver MUST verify that the record contains a sequence number that 614 does not duplicate the sequence number of any other record received 615 during the life of this session. This SHOULD be the first check 616 applied to a packet after it has been matched to a session, to speed 617 rejection of duplicate records. 619 Duplicates are rejected through the use of a sliding receive window. 620 (How the window is implemented is a local matter, but the following 621 text describes the functionality that the implementation must 622 exhibit.) A minimum window size of 32 MUST be supported, but a 623 window size of 64 is preferred and SHOULD be employed as the default. 624 Another window size (larger than the minimum) MAY be chosen by the 625 receiver. (The receiver does not notify the sender of the window 626 size.) 628 The "right" edge of the window represents the highest validated 629 sequence number value received on this session. Records that contain 630 sequence numbers lower than the "left" edge of the window are 631 rejected. Packets falling within the window are checked against a 632 list of received packets within the window. An efficient means for 633 performing this check, based on the use of a bit mask, is described 634 in Section 3.4.3 of [RFC4303]. 636 If the received record falls within the window and is new, or if the 637 packet is to the right of the window, then the receiver proceeds to 638 MAC verification. If the MAC validation fails, the receiver MUST 639 discard the received record as invalid. The receive window is 640 updated only if the MAC verification succeeds. 642 4.4.2. Handling Invalid Records 644 Unlike TLS, DTLS is resilient in the face of invalid records (e.g., 645 invalid formatting, length, MAC, etc.). In general, invalid records 646 SHOULD be silently discarded, thus preserving the association; 647 however, an error MAY be logged for diagnostic purposes. 648 Implementations which choose to generate an alert instead, MUST 649 generate error alerts to avoid attacks where the attacker repeatedly 650 probes the implementation to see how it responds to various types of 651 error. Note that if DTLS is run over UDP, then any implementation 652 which does this will be extremely susceptible to denial-of-service 653 (DoS) attacks because UDP forgery is so easy. Thus, this practice is 654 NOT RECOMMENDED for such transports, both to increase the reliability 655 of DTLS service and to avoid the risk of spoofing attacks sending 656 traffic to unrelated third parties. 658 If DTLS is being carried over a transport that is resistant to 659 forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts 660 because an attacker will have difficulty forging a datagram that will 661 not be rejected by the transport layer. 663 5. The DTLS Handshake Protocol 665 DTLS 1.3 re-uses the TLS 1.3 handshake messages and flows, with the 666 following changes: 668 1. To handle message loss, reordering, and fragmentation 669 modifications to the handshake header are necessary. 671 2. Retransmission timers are introduced to handle message loss. 673 3. A new ACK content type has been added for reliable message 674 delivery of handshake messages. 676 Note that TLS 1.3 already supports a cookie extension, which used to 677 prevent denial-of-service attacks. This DoS prevention mechanism is 678 described in more detail below since UDP-based protocols are more 679 vulnerable to amplification attacks than a connection-oriented 680 transport like TCP that performs return-routability checks as part of 681 the connection establishment. 683 With these exceptions, the DTLS message formats, flows, and logic are 684 the same as those of TLS 1.3. 686 5.1. Denial-of-Service Countermeasures 688 Datagram security protocols are extremely susceptible to a variety of 689 DoS attacks. Two attacks are of particular concern: 691 1. An attacker can consume excessive resources on the server by 692 transmitting a series of handshake initiation requests, causing 693 the server to allocate state and potentially to perform expensive 694 cryptographic operations. 696 2. An attacker can use the server as an amplifier by sending 697 connection initiation messages with a forged source of the 698 victim. The server then sends its response to the victim 699 machine, thus flooding it. Depending on the selected ciphersuite 700 this response message can be quite large, as it is the case for a 701 Certificate message. 703 In order to counter both of these attacks, DTLS borrows the stateless 704 cookie technique used by Photuris [RFC2522] and IKE [RFC5996]. When 705 the client sends its ClientHello message to the server, the server 706 MAY respond with a HelloRetryRequest message. The HelloRetryRequest 707 message, as well as the cookie extension, is defined in TLS 1.3. The 708 HelloRetryRequest message contains a stateless cookie generated using 709 the technique of [RFC2522]. The client MUST retransmit the 710 ClientHello with the cookie added as an extension. The server then 711 verifies the cookie and proceeds with the handshake only if it is 712 valid. This mechanism forces the attacker/client to be able to 713 receive the cookie, which makes DoS attacks with spoofed IP addresses 714 difficult. This mechanism does not provide any defence against DoS 715 attacks mounted from valid IP addresses. 717 The DTLS 1.3 specification changes the way how cookies are exchanged 718 compared to DTLS 1.2. DTLS 1.3 re-uses the HelloRetryRequest message 719 and conveys the cookie to the client via an extension. The client 720 receiving the cookie uses the same extension to place the cookie 721 subsequently into a ClientHello message. DTLS 1.2 on the other hand 722 used a separate message, namely the HelloVerifyRequest, to pass a 723 cookie to the client and did not utilize the extension mechanism. 724 For backwards compatibility reason the cookie field in the 725 ClientHello is present in DTLS 1.3 but is ignored by a DTLS 1.3 726 compliant server implementation. 728 The exchange is shown in Figure 2. Note that the figure focuses on 729 the cookie exchange; all other extensions are omitted. 731 Client Server 732 ------ ------ 733 ClientHello ------> 735 <----- HelloRetryRequest 736 + cookie 738 ClientHello ------> 739 + cookie 741 [Rest of handshake] 743 Figure 2: DTLS Exchange with HelloRetryRequest contain the Cookie 744 Extension 746 The cookie extension is defined in Section 4.2.2 of 747 [I-D.ietf-tls-tls13]. When sending the initial ClientHello, the 748 client does not have a cookie yet. In this case, the cookie 749 extension is omitted and the legacy_cookie field in the ClientHello 750 message SHOULD be set to a zero length vector (i.e., a single zero 751 byte length field) and MUST be ignored by a server negotiating DTLS 752 1.3. 754 When responding to a HelloRetryRequest, the client MUST create a new 755 ClientHello message following the description in Section 4.1.2 of 756 [I-D.ietf-tls-tls13]. 758 If the HelloRetryRequest message is used, the initial ClientHello and 759 the HelloRetryRequest are included in the calculation of the 760 handshake_messages (for the CertificateVerify message) and 761 verify_data (for the Finished message). However, the computation of 762 the message hash for the HelloRetryRequest is done according to the 763 description in Section 4.4.1 of [I-D.ietf-tls-tls13]. 765 The handshake transcript is not reset with the second ClientHello and 766 a stateless server-cookie implementation requires the transcript of 767 the HelloRetryRequest to be stored in the cookie or the internal 768 state of the hash algorithm, since only the hash of the transcript is 769 required for the handshake to complete. 771 When the second ClientHello is received, the server can verify that 772 the cookie is valid and that the client can receive packets at the 773 given IP address. If the client's apparent IP address is embedded in 774 the cookie, this prevents an attacker from generating an acceptable 775 ClientHello apparently from another user. 777 One potential attack on this scheme is for the attacker to collect a 778 number of cookies from different addresses where it controls 779 endpoints and then reuse them to attack the server. The server can 780 defend against this attack by changing the secret value frequently, 781 thus invalidating those cookies. If the server wishes that 782 legitimate clients be able to handshake through the transition (e.g., 783 they received a cookie with Secret 1 and then sent the second 784 ClientHello after the server has changed to Secret 2), the server can 785 have a limited window during which it accepts both secrets. 786 [RFC5996] suggests adding a key identifier to cookies to detect this 787 case. An alternative approach is simply to try verifying with both 788 secrets. It is RECOMMENDED that servers implement a key rotation 789 scheme that allows the server to manage keys with overlapping 790 lifetime. 792 Alternatively, the server can store timestamps in the cookie and 793 reject those cookies that were not generated within a certain amount 794 of time. 796 DTLS servers SHOULD perform a cookie exchange whenever a new 797 handshake is being performed. If the server is being operated in an 798 environment where amplification is not a problem, the server MAY be 799 configured not to perform a cookie exchange. The default SHOULD be 800 that the exchange is performed, however. In addition, the server MAY 801 choose not to do a cookie exchange when a session is resumed. 802 Clients MUST be prepared to do a cookie exchange with every 803 handshake. 805 If a server receives a ClientHello with an invalid cookie, it MUST 806 NOT respond with a HelloRetryRequest. Restarting the handshake from 807 scratch, without a cookie, allows the client to recover from a 808 situation where it obtained a cookie that cannot be verified by the 809 server. As described in Section 4.1.4 of 810 [I-D.ietf-tls-tls13],clients SHOULD also abort the handshake with an 811 "unexpected_message" alert in response to any second 812 HelloRetryRequest which was sent in the same connection (i.e., where 813 the ClientHello was itself in response to a HelloRetryRequest). 815 5.2. DTLS Handshake Message Format 817 In order to support message loss, reordering, and message 818 fragmentation, DTLS modifies the TLS 1.3 handshake header: 820 enum { 821 hello_request_RESERVED(0), 822 client_hello(1), 823 server_hello(2), 824 hello_verify_request_RESERVED(3), 825 new_session_ticket(4), 826 end_of_early_data(5), 827 hello_retry_request(6), 828 encrypted_extensions(8), 829 certificate(11), 830 server_key_exchange_RESERVED(12), 831 certificate_request(13), 832 server_hello_done_RESERVED(14), 833 certificate_verify(15), 834 client_key_exchange_RESERVED(16), 835 finished(20), 836 key_update(24), 837 message_hash(254), 838 (255) 839 } HandshakeType; 841 struct { 842 HandshakeType msg_type; /* handshake type */ 843 uint24 length; /* bytes in message */ 844 uint16 message_seq; /* DTLS-required field */ 845 uint24 fragment_offset; /* DTLS-required field */ 846 uint24 fragment_length; /* DTLS-required field */ 847 select (HandshakeType) { 848 case client_hello: ClientHello; 849 case server_hello: ServerHello; 850 case end_of_early_data: EndOfEarlyData; 851 case hello_retry_request: HelloRetryRequest; 852 case encrypted_extensions: EncryptedExtensions; 853 case certificate_request: CertificateRequest; 854 case certificate: Certificate; 855 case certificate_verify: CertificateVerify; 856 case finished: Finished; 857 case new_session_ticket: NewSessionTicket; 858 case key_update: KeyUpdate; 859 } body; 860 } Handshake; 862 The first message each side transmits in each association always has 863 message_seq = 0. Whenever a new message is generated, the 864 message_seq value is incremented by one. When a message is 865 retransmitted, the old message_seq value is re-used, i.e., not 866 incremented. From the perspective of the DTLS record layer, the 867 retransmission is a new record. This record will have a new 868 DTLSPlaintext.sequence_number value. 870 DTLS implementations maintain (at least notionally) a 871 next_receive_seq counter. This counter is initially set to zero. 872 When a handshake message is received, if its message_seq value 873 matches next_receive_seq, next_receive_seq is incremented and the 874 message is processed. If the sequence number is less than 875 next_receive_seq, the message MUST be discarded. If the sequence 876 number is greater than next_receive_seq, the implementation SHOULD 877 queue the message but MAY discard it. (This is a simple space/ 878 bandwidth tradeoff). 880 In addition to the handshake messages that are deprecated by the TLS 881 1.3 specification DTLS 1.3 furthermore deprecates the 882 HelloVerifyRequest message originally defined in DTLS 1.0. DTLS 883 1.3-compliant implements MUST NOT use the HelloVerifyRequest to 884 execute a return-routability check. A dual-stack DTLS 1.2/DTLS 1.3 885 client MUST, however, be prepared to interact with a DTLS 1.2 server. 887 5.3. ClientHello Message 889 The format of the ClientHello used by a DTLS 1.3 client differs from 890 the TLS 1.3 ClientHello format as shown below. 892 uint16 ProtocolVersion; 893 opaque Random[32]; 895 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 897 struct { 898 ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2 899 Random random; 900 opaque legacy_session_id<0..32>; 901 opaque legacy_cookie<0..2^8-1>; // DTLS 902 CipherSuite cipher_suites<2..2^16-2>; 903 opaque legacy_compression_methods<1..2^8-1>; 904 Extension extensions<0..2^16-1>; 905 } ClientHello; 907 legacy_version: In previous versions of DTLS, this field was used 908 for version negotiation and represented the highest version number 909 supported by the client. Experience has shown that many servers 910 do not properly implement version negotiation, leading to "version 911 intolerance" in which the server rejects an otherwise acceptable 912 ClientHello with a version number higher than it supports. In 913 DTLS 1.3, the client indicates its version preferences in the 914 "supported_versions" extension (see Section 4.2.1 of 916 [I-D.ietf-tls-tls13]) and the legacy_version field MUST be set to 917 {254, 253}, which was the version number for DTLS 1.2. 919 random: Same as for TLS 1.3 921 legacy_session_id: Same as for TLS 1.3 923 legacy_cookie: A DTLS 1.3-only client MUST set the legacy_cookie 924 field to zero length. 926 cipher_suites: Same as for TLS 1.3 928 legacy_compression_methods: Same as for TLS 1.3 930 extensions: Same as for TLS 1.3 932 5.4. Handshake Message Fragmentation and Reassembly 934 Each DTLS message MUST fit within a single transport layer datagram. 935 However, handshake messages are potentially bigger than the maximum 936 record size. Therefore, DTLS provides a mechanism for fragmenting a 937 handshake message over a number of records, each of which can be 938 transmitted separately, thus avoiding IP fragmentation. 940 When transmitting the handshake message, the sender divides the 941 message into a series of N contiguous data ranges. These ranges MUST 942 NOT be larger than the maximum handshake fragment size and MUST 943 jointly contain the entire handshake message. The ranges MUST NOT 944 overlap. The sender then creates N handshake messages, all with the 945 same message_seq value as the original handshake message. Each new 946 message is labeled with the fragment_offset (the number of bytes 947 contained in previous fragments) and the fragment_length (the length 948 of this fragment). The length field in all messages is the same as 949 the length field of the original message. An unfragmented message is 950 a degenerate case with fragment_offset=0 and fragment_length=length. 952 When a DTLS implementation receives a handshake message fragment, it 953 MUST buffer it until it has the entire handshake message. DTLS 954 implementations MUST be able to handle overlapping fragment ranges. 955 This allows senders to retransmit handshake messages with smaller 956 fragment sizes if the PMTU estimate changes. 958 Note that as with TLS, multiple handshake messages may be placed in 959 the same DTLS record, provided that there is room and that they are 960 part of the same flight. Thus, there are two acceptable ways to pack 961 two DTLS messages into the same datagram: in the same record or in 962 separate records. 964 5.5. DTLS Handshake Flights 966 DTLS messages are grouped into a series of message flights, according 967 to the diagrams below. 969 Client Server 971 ClientHello +----------+ 972 + key_share* | Flight 1 | 973 + pre_shared_key* --------> +----------+ 975 +----------+ 976 <-------- HelloRetryRequest | Flight 2 | 977 + cookie +----------+ 979 ClientHello +----------+ 980 + key_share* | Flight 3 | 981 + pre_shared_key* --------> +----------+ 982 + cookie 984 ServerHello 985 + key_share* 986 + pre_shared_key* +----------+ 987 {EncryptedExtensions} | Flight 4 | 988 {CertificateRequest*} +----------+ 989 {Certificate*} 990 {CertificateVerify*} 991 <-------- {Finished} 992 [Application Data*] 994 {Certificate*} +----------+ 995 {CertificateVerify*} | Flight 5 | 996 {Finished} --------> +----------+ 997 [Application Data] 999 +----------+ 1000 <-------- [Ack] | Flight 6 | 1001 [Application Data*] +----------+ 1003 [Application Data] <-------> [Application Data] 1005 Figure 3: Message Flights for full DTLS Handshake (with Cookie 1006 Exchange) 1008 ClientHello +----------+ 1009 + pre_shared_key | Flight 1 | 1010 + key_share* --------> +----------+ 1012 ServerHello 1013 + pre_shared_key +----------+ 1014 + key_share* | Flight 2 | 1015 {EncryptedExtensions} +----------+ 1016 <-------- {Finished} 1017 [Application Data*] 1018 +----------+ 1019 {Finished} --------> | Flight 3 | 1020 [Application Data*] +----------+ 1022 +----------+ 1023 <-------- [Ack] | Flight 4 | 1024 [Application Data*] +----------+ 1026 [Application Data] <-------> [Application Data] 1028 Figure 4: Message Flights for Resumption and PSK Handshake (without 1029 Cookie Exchange) 1031 Client Server 1033 ClientHello 1034 + early_data 1035 + psk_key_exchange_modes +----------+ 1036 + key_share* | Flight 1 | 1037 + pre_shared_key +----------+ 1038 (Application Data*) --------> 1040 ServerHello 1041 + pre_shared_key 1042 + key_share* +----------+ 1043 {EncryptedExtensions} | Flight 2 | 1044 {Finished} +----------+ 1045 <-------- [Application Data*] 1047 +----------+ 1048 (EndOfEarlyData) | Flight 3 | 1049 {Finished} --------> +----------+ 1050 [Application Data*] 1051 +----------+ 1052 <-------- [Ack] | Flight 4 | 1053 [Application Data*] +----------+ 1055 [Application Data] <-------> [Application Data] 1057 Figure 5: Message Flights for the Zero-RTT Handshake 1059 Client Server 1061 +----------+ 1062 <-------- [NewSessionTicket] | Flight 1 | 1063 +----------+ 1065 +----------+ 1066 [Ack] --------> | Flight 2 | 1067 +----------+ 1069 Figure 6: Message Flights for New Session Ticket Message 1071 Note: The application data sent by the client is not included in the 1072 timeout and retransmission calculation. 1074 5.6. Timeout and Retransmission 1076 5.6.1. State Machine 1078 DTLS uses a simple timeout and retransmission scheme with the state 1079 machine shown in Figure 7. Because DTLS clients send the first 1080 message (ClientHello), they start in the PREPARING state. DTLS 1081 servers start in the WAITING state, but with empty buffers and no 1082 retransmit timer. 1084 +-----------+ 1085 | PREPARING | 1086 +----------> | | 1087 | | | 1088 | +-----------+ 1089 | | 1090 | | Buffer next flight 1091 | | 1092 | \|/ 1093 | +-----------+ 1094 | | | 1095 | | SENDING |<------------------+ 1096 | | | | 1097 | +-----------+ | 1098 Receive | | | 1099 next | | Send flight or partial | 1100 flight | | flight | 1101 | +---------------+ | 1102 | | | Set retransmit timer | 1103 | | \|/ | 1104 | | +-----------+ | 1105 | | | | | 1106 +--)---------| WAITING |-------------------+ 1107 | | +----->| | Timer expires | 1108 | | | +-----------+ | 1109 | | | | | | | 1110 | | | | | | | 1111 | | +----------+ | +--------------------+ 1112 | | Receive record | Read retransmit or ACK 1113 Receive | | Send ACK | 1114 last | | | 1115 flight | | | Receive ACK 1116 | | | for last flight 1117 \|/\|/ | 1118 | 1119 +-----------+ | 1120 | | <---------+ 1121 | FINISHED | 1122 | | 1123 +-----------+ 1124 | /|\ 1125 | | 1126 | | 1127 +---+ 1129 Server read retransmit 1130 Retransmit ACK 1132 Figure 7: DTLS Timeout and Retransmission State Machine 1134 The state machine has three basic states. 1136 In the PREPARING state, the implementation does whatever computations 1137 are necessary to prepare the next flight of messages. It then 1138 buffers them up for transmission (emptying the buffer first) and 1139 enters the SENDING state. 1141 In the SENDING state, the implementation transmits the buffered 1142 flight of messages. If the implementation has received one or more 1143 ACKs Section 7 from the peer, then it SHOULD omit any messages or 1144 message fragments which have already been ACKed. Once the messages 1145 have been sent, the implementation then enters the FINISHED state if 1146 this is the last flight in the handshake. Or, if the implementation 1147 expects to receive more messages, it sets a retransmit timer and then 1148 enters the WAITING state. 1150 There are four ways to exit the WAITING state: 1152 1. The retransmit timer expires: the implementation transitions to 1153 the SENDING state, where it retransmits the flight, resets the 1154 retransmit timer, and returns to the WAITING state. 1156 2. The implementation reads a ACK from the peer: upon receiving an 1157 ACK for a partial flight (as mentioned in Section 7.1, the 1158 implementation transitions to the SENDING state, where it 1159 retransmits the unacked portion of the flight, resets the 1160 retransmit timer, and returns to the WAITING state. Upon 1161 receiving an ACK for a complete flight, the implementation 1162 cancels all retransmissions and either remains in WAITING, or, if 1163 the ACK was for the final flight, transitions to FINISHED. 1165 3. The implementation reads a retransmitted flight from the peer: 1166 the implementation transitions to the SENDING state, where it 1167 retransmits the flight, resets the retransmit timer, and returns 1168 to the WAITING state. The rationale here is that the receipt of 1169 a duplicate message is the likely result of timer expiry on the 1170 peer and therefore suggests that part of one's previous flight 1171 was lost. 1173 4. The implementation receives some or all next flight of messages: 1174 if this is the final flight of messages, the implementation 1175 transitions to FINISHED. If the implementation needs to send a 1176 new flight, it transitions to the PREPARING state. Partial reads 1177 (whether partial messages or only some of the messages in the 1178 flight) may also trigger the implementation to send an ACK, as 1179 described in Section 7.1. 1181 Because DTLS clients send the first message (ClientHello), they start 1182 in the PREPARING state. DTLS servers start in the WAITING state, but 1183 with empty buffers and no retransmit timer. 1185 In addition, for at least twice the default Maximum Segment Lifetime 1186 (MSL) defined for [RFC0793], when in the FINISHED state, the server 1187 MUST respond to retransmission of the client's second flight with a 1188 retransmit of its ACK. 1190 Note that because of packet loss, it is possible for one side to be 1191 sending application data even though the other side has not received 1192 the first side's Finished message. Implementations MUST either 1193 discard or buffer all application data packets for the new epoch 1194 until they have received the Finished message for that epoch. 1195 Implementations MAY treat receipt of application data with a new 1196 epoch prior to receipt of the corresponding Finished message as 1197 evidence of reordering or packet loss and retransmit their final 1198 flight immediately, shortcutting the retransmission timer. 1200 5.6.2. Timer Values 1202 Though timer values are the choice of the implementation, mishandling 1203 of the timer can lead to serious congestion problems; for example, if 1204 many instances of a DTLS time out early and retransmit too quickly on 1205 a congested link. Implementations SHOULD use an initial timer value 1206 of 100 msec (the minimum defined in RFC 6298 [RFC6298]) and double 1207 the value at each retransmission, up to no less than the RFC 6298 1208 maximum of 60 seconds. Application specific profiles, such as those 1209 used for the Internet of Things environment, may recommend longer 1210 timer values. Note that we recommend a 100 msec timer rather than 1211 the 3-second RFC 6298 default in order to improve latency for time- 1212 sensitive applications. Because DTLS only uses retransmission for 1213 handshake and not dataflow, the effect on congestion should be 1214 minimal. 1216 Implementations SHOULD retain the current timer value until a 1217 transmission without loss occurs, at which time the value may be 1218 reset to the initial value. After a long period of idleness, no less 1219 than 10 times the current timer value, implementations may reset the 1220 timer to the initial value. One situation where this might occur is 1221 when a rehandshake is used after substantial data transfer. 1223 5.7. CertificateVerify and Finished Messages 1225 CertificateVerify and Finished messages have the same format as in 1226 TLS 1.3. Hash calculations include entire handshake messages, 1227 including DTLS-specific fields: message_seq, fragment_offset, and 1228 fragment_length. However, in order to remove sensitivity to 1229 handshake message fragmentation, the CertificateVerify and the 1230 Finished messages MUST be computed as if each handshake message had 1231 been sent as a single fragment following the algorithm described in 1232 Section 4.4.3 and Section 4.4.4 of [I-D.ietf-tls-tls13], 1233 respectively. 1235 5.8. Alert Messages 1237 Note that Alert messages are not retransmitted at all, even when they 1238 occur in the context of a handshake. However, a DTLS implementation 1239 which would ordinarily issue an alert SHOULD generate a new alert 1240 message if the offending record is received again (e.g., as a 1241 retransmitted handshake message). Implementations SHOULD detect when 1242 a peer is persistently sending bad messages and terminate the local 1243 connection state after such misbehavior is detected. 1245 5.9. Establishing New Associations with Existing Parameters 1247 If a DTLS client-server pair is configured in such a way that 1248 repeated connections happen on the same host/port quartet, then it is 1249 possible that a client will silently abandon one connection and then 1250 initiate another with the same parameters (e.g., after a reboot). 1251 This will appear to the server as a new handshake with epoch=0. In 1252 cases where a server believes it has an existing association on a 1253 given host/port quartet and it receives an epoch=0 ClientHello, it 1254 SHOULD proceed with a new handshake but MUST NOT destroy the existing 1255 association until the client has demonstrated reachability either by 1256 completing a cookie exchange or by completing a complete handshake 1257 including delivering a verifiable Finished message. After a correct 1258 Finished message is received, the server MUST abandon the previous 1259 association to avoid confusion between two valid associations with 1260 overlapping epochs. The reachability requirement prevents off-path/ 1261 blind attackers from destroying associations merely by sending forged 1262 ClientHellos. 1264 Note: it is not always possible to distinguish which association a 1265 given packet is from. For instance, if the client performs a 1266 handshake, abandons the connection, and then immediately starts a new 1267 handshake, it may not be possible to tell which connection a given 1268 protected record is for. In these cases, trial decryption MAY be 1269 necessary, though implementations could also use some sort of 1270 connection identifier, such as the one specified in 1271 [I-D.rescorla-tls-dtls-connection-id]. 1273 6. Example of Handshake with Timeout and Retransmission 1275 The following is an example of a handshake with lost packets and 1276 retransmissions. 1278 Client Server 1279 ------ ------ 1281 Record 0 --------> 1282 ClientHello 1283 (message_seq=0) 1284 +cookie 1286 X<----- Record 0 1287 (lost) ServerHello 1288 (message_seq=1) 1289 EncryptedExtensions 1290 (message_seq=2) 1291 Certificate 1292 (message_seq=3) 1294 <-------- Record 1 1295 CertificateVerify 1296 (message_seq=4) 1297 Finished 1298 (message_seq=5) 1300 Record 1 --------> 1301 ACK [1] 1303 <-------- Record 2 1304 ServerHello 1305 (message_seq=1) 1306 EncryptedExtensions 1307 (message_seq=2) 1308 Certificate 1309 (message_seq=3) 1311 Record 2 --------> 1312 Certificate 1313 (message_seq=2) 1314 CertificateVerify 1315 (message_seq=3) 1316 Finished 1317 (message_seq=4) 1319 <-------- Record 3 1320 ACK [2] 1322 Figure 8: Example DTLS Exchange illustrating Message Loss 1324 6.1. Epoch Values and Rekeying 1326 A recipient of a DTLS message needs to select the correct keying 1327 material in order to process an incoming message. With the 1328 possibility of message loss and re-order an identifier is needed to 1329 determine which cipher state has been used to protect the record 1330 payload. The epoch value fulfills this role in DTLS. In addition to 1331 the key derivation steps described in Section 7 of 1332 [I-D.ietf-tls-tls13] triggered by the states during the handshake a 1333 sender may want to rekey at any time during the lifetime of the 1334 connection and has to have a way to indicate that it is updating its 1335 sending cryptographic keys. 1337 This version of DTLS assigns dedicated epoch values to messages in 1338 the protocol exchange to allow identification of the correct cipher 1339 state: 1341 - epoch value (0) is used with unencrypted messages. There are 1342 three unencrypted messages in DTLS, namely ClientHello, 1343 ServerHello, and HelloRetryRequest. 1345 - epoch value (1) is used for messages protected using keys derived 1346 from early_traffic_secret. This includes early data sent by the 1347 client and the EndOfEarlyData message. 1349 - epoch value (2) is used for messages protected using keys derived 1350 from the handshake_traffic_secret. Messages transmitted during 1351 the initial handshake, such as EncryptedExtensions, 1352 CertificateRequest, Certificate, CertificateVerify, and Finished 1353 belong to this category. Note, however, post-handshake are 1354 protected under the appropriate application traffic key and are 1355 not included in this category. 1357 - epoch value (3) is used for payloads protected using keys derived 1358 from the initial traffic_secret_0. This may include handshake 1359 messages, such as post-handshake messages (e.g., a 1360 NewSessionTicket message). 1362 - epoch value (4 to 2^16-1) is used for payloads protected using 1363 keys from the traffic_secret_N (N>0). 1365 Using these reserved epoch values a receiver knows what cipher state 1366 has been used to encrypt and integrity protect a message. 1367 Implementations that receive a payload with an epoch value for which 1368 no corresponding cipher state can be determined MUST generate a 1369 "unexpected_message" alert. For example, client incorrectly uses 1370 epoch value 5 when sending early application data in a 0-RTT 1371 exchange. A server will not be able to compute the appropriate keys 1372 and will therefore have to respond with an alert. 1374 Note that epoch values do not wrap. If a DTLS implementation would 1375 need to wrap the epoch value, it MUST terminate the connection. 1377 The traffic key calculation is described in Section 7.3 of 1378 [I-D.ietf-tls-tls13]. 1380 Figure 9 illustrates the epoch values in an example DTLS handshake. 1382 Client Server 1383 ------ ------ 1385 ClientHello 1386 (epoch=0) 1387 --------> 1389 <-------- HelloRetryRequest 1390 (epoch=0) 1392 ClientHello --------> 1393 (epoch=0) 1395 <-------- ServerHello 1396 (epoch=0) 1397 {EncryptedExtensions} 1398 (epoch=2) 1399 {Certificate} 1400 (epoch=2) 1401 {CertificateVerify} 1402 (epoch=2) 1403 {Finished} 1404 (epoch=2) 1406 {Certificate} --------> 1407 (epoch=2) 1408 {CertificateVerify} 1409 (epoch=2) 1410 {Finished} 1411 (epoch=2) 1413 <-------- [Ack] 1414 (epoch=3) 1416 [Application Data] --------> 1417 (epoch=3) 1418 <-------- [Application Data] 1419 (epoch=3) 1421 Some time later ... 1422 (Post-Handshake Message Exchange) 1424 <-------- [NewSessionTicket] 1425 (epoch=3) 1427 [Ack] --------> 1428 (epoch=3) 1430 Some time later ... 1431 (Rekeying) 1433 <-------- [Application Data] 1434 (epoch=4) 1435 [Application Data] --------> 1436 (epoch=4) 1438 Figure 9: Example DTLS Exchange with Epoch Information 1440 7. ACK Message 1442 The ACK message is used by an endpoint to indicate handshake- 1443 containing the TLS records it has received from the other side. ACK 1444 is not a handshake message but is rather a separate content type, 1445 with code point TBD (proposed, 25). This avoids it consuming space 1446 in the handshake message sequence. Note that ACKs can still be 1447 piggybacked on the same UDP datagram as handshake records. 1449 struct { 1450 uint64 record_numbers<0..2^16-1>; 1451 } ACK; 1453 record_numbers: a list of the records containing handshake messages 1454 in the current flight which the endpoint has received, in 1455 numerically increasing order. ACKs only cover the current 1456 outstanding flight (this is possible because DTLS is generally a 1457 lockstep protocol). Thus, an ACK from the server would not cover 1458 both the ClientHello and the client's Certificate. 1459 Implementations can accomplish this by clearing their ACK list 1460 upon receiving the start of the next flight. 1462 ACK records MUST be sent with an epoch that is equal to or higher 1463 than the record which is being acknowledged. Implementations SHOULD 1464 simply use the current key. 1466 7.1. Sending ACKs 1468 When an implementation receives a partial flight, it SHOULD generate 1469 an ACK that covers the messages from that flight which it has 1470 received so far. Implementations have some discretion about when to 1471 generate ACKs, but it is RECOMMENDED that they do so under two 1472 circumstances: 1474 - When they receive a message or fragment which is out of order, 1475 either because it is not the next expected message or because it 1476 is not the next piece of the current message. Implementations 1477 MUST NOT send ACKs for handshake messages which they discard as 1478 out-of-order, because otherwise those messages will not be 1479 retransmitted. 1481 - When they have received part of a flight and do not immediately 1482 receive the rest of the flight (which may be in the same UDP 1483 datagram). A reasonable approach here is to set a timer for 1/4 1484 the current retransmit timer value when the first record in the 1485 flight is received and then send an ACK when that timer expires. 1487 In addition, implementations MUST send ACKs upon receiving all of any 1488 flight which they do not respond to with their own messages. 1489 Specifically, this means the client's final flight of the main 1490 handshake, the server's transmission of the NewSessionTicket, and 1491 KeyUpdate messages. ACKs SHOULD NOT be sent for other complete 1492 flights because they are implicitly acknowledged by the receipt of 1493 the next flight, which generally immediately follows the flight. 1494 Each NewSessionTicket or KeyUpdate is an individual flight; in 1495 particular, a KeyUpdate sent in response to a KeyUpdate with 1496 update_requested does not implicitly acknowledge that message. 1497 Implementations MAY ACK the records corresponding to each 1498 transmission of that flight or simply ACK the most recent one. 1500 ACKs MUST NOT be sent for other records of any content type other 1501 than handshake or for records which cannot be unprotected. 1503 Note that in some cases it may be necessary to send an ACK which does 1504 not contain any record numbers. For instance, a client might receive 1505 an EncryptedExtensions message prior to receiving a ServerHello. 1506 Because it cannot decrypt the EncryptedExtensions, it cannot safely 1507 ACK it (as it might be damaged). If the client does not send an ACK, 1508 the server will eventually retransmit its first flight, but this 1509 might take far longer than the actual round trip time between client 1510 and server. Having the client send an empty ACK shortcuts this 1511 process. 1513 7.2. Receiving ACKs 1515 When an implementation receives an ACK, it SHOULD record that the 1516 messages or message fragments sent in the records being ACKed were 1517 received and omit them from any future retransmissions. Upon receipt 1518 of an ACK for only some messages from a flight, an implementation 1519 SHOULD retransmit the remaining messages or fragments. Note that 1520 this requires implementations to track which messages appear in which 1521 records. Once all the messages in a flight have been acknowledged, 1522 the implementation MUST cancel all retransmissions of that flight. 1523 As noted above, the receipt of any packet responding to a given 1524 flight MUST be taken as an implicit ACK for the entire flight. 1526 8. Key Updates 1528 DTLS 1.3 implementations MUST send a KeyUpdate message prior to 1529 updating the keys they are using to protect application data traffic. 1530 As with other handshake messages with no built-in response, 1531 KeyUpdates MUST be acknowledged. In order to facilitate epoch 1532 reconstruction Section 4.1.2 implementations MUST NOT send a new 1533 KeyUpdate until the previous KeyUpdate has been acknowledged (this 1534 avoids having too many epochs in active use). 1536 Due to loss and/or re-ordering, DTLS 1.3 implementations may receive 1537 a record with a different epoch than the current one. They SHOULD 1538 attempt to process those records with that epoch (see Section 4.1.2 1539 for information on determining the correct epoch), but MAY opt to 1540 discard such out-of-epoch records. Implementations SHOULD NOT 1541 discard the keys for their current epoch prior to receiving a 1542 KeyUpdate. 1544 Although KeyUpdate MUST be ACKed, it is possible for the ACK to be 1545 lost, in which case the sender of the KeyUpdate will retransmit it. 1546 Implementations MUST retain the ability to ACK the KeyUpdate for up 1547 to 2MSL. It is RECOMMENDED that they do so by retaining the pre- 1548 update keying material, but they MAY do so by responding to messages 1549 which appear to be out-of-epoch with a canned ACK message; in this 1550 case, implementations SHOULD rate limit how often they send such 1551 ACKs. 1553 9. Application Data Protocol 1555 Application data messages are carried by the record layer and are 1556 fragmented and encrypted based on the current connection state. The 1557 messages are treated as transparent data to the record layer. 1559 10. Security Considerations 1561 Security issues are discussed primarily in [I-D.ietf-tls-tls13]. 1563 The primary additional security consideration raised by DTLS is that 1564 of denial of service. DTLS includes a cookie exchange designed to 1565 protect against denial of service. However, implementations that do 1566 not use this cookie exchange are still vulnerable to DoS. In 1567 particular, DTLS servers that do not use the cookie exchange may be 1568 used as attack amplifiers even if they themselves are not 1569 experiencing DoS. Therefore, DTLS servers SHOULD use the cookie 1570 exchange unless there is good reason to believe that amplification is 1571 not a threat in their environment. Clients MUST be prepared to do a 1572 cookie exchange with every handshake. 1574 Unlike TLS implementations, DTLS implementations SHOULD NOT respond 1575 to invalid records by terminating the connection. 1577 If implementations process out-of-epoch records as recommended in 1578 Section 8, then this creates a denial of service risk since an 1579 adversary could inject packets with fake epoch values, forcing the 1580 recipient to compute the next-generation application_traffic_secret 1581 using the HKDF-Expand-Label construct to only find out that the 1582 message was does not pass the AEAD cipher processing. The impact of 1583 this attack is small since the HKDF-Expand-Label only performs 1584 symmetric key hashing operations. Implementations which are 1585 concerned about this form of attack can discard out-of-epoch records. 1587 11. Changes to DTLS 1.2 1589 Since TLS 1.3 introduces a large number of changes to TLS 1.2, the 1590 list of changes from DTLS 1.2 to DTLS 1.3 is equally large. For this 1591 reason this section focuses on the most important changes only. 1593 - New handshake pattern, which leads to a shorter message exchange 1595 - Support for AEAD-only ciphers 1597 - HelloRetryRequest of TLS 1.3 used instead of HelloVerifyRequest 1599 - More flexible ciphersuite negotiation 1601 - New session resumption mechanism 1603 - PSK authentication redefined 1605 - New key derivation hierarchy utilizing a new key derivation 1606 construct 1608 - Removed support for weaker and older cryptographic algorithms 1610 - Improved version negotation 1612 12. IANA Considerations 1614 IANA is requested to allocate a new value in the TLS ContentType 1615 Registry for the ACK message defined in Section 7, with content type 1616 25. 1618 13. References 1620 13.1. Normative References 1622 [I-D.ietf-tls-tls13] 1623 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1624 Version 1.3", draft-ietf-tls-tls13-21 (work in progress), 1625 July 2017. 1627 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1628 DOI 10.17487/RFC0768, August 1980, 1629 . 1631 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1632 RFC 793, DOI 10.17487/RFC0793, September 1981, 1633 . 1635 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1636 DOI 10.17487/RFC1191, November 1990, 1637 . 1639 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1640 Requirement Levels", BCP 14, RFC 2119, 1641 DOI 10.17487/RFC2119, March 1997, 1642 . 1644 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1645 Control Message Protocol (ICMPv6) for the Internet 1646 Protocol Version 6 (IPv6) Specification", STD 89, 1647 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1648 . 1650 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1651 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1652 . 1654 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 1655 "Computing TCP's Retransmission Timer", RFC 6298, 1656 DOI 10.17487/RFC6298, June 2011, 1657 . 1659 13.2. Informative References 1661 [I-D.rescorla-tls-dtls-connection-id] 1662 Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom, 1663 "The Datagram Transport Layer Security (DTLS) Connection 1664 Identifier", draft-rescorla-tls-dtls-connection-id-02 1665 (work in progress), November 2017. 1667 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 1668 Protocol", RFC 2522, DOI 10.17487/RFC2522, March 1999, 1669 . 1671 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1672 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1673 . 1675 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1676 Congestion Control Protocol (DCCP)", RFC 4340, 1677 DOI 10.17487/RFC4340, March 2006, 1678 . 1680 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1681 (TLS) Protocol Version 1.1", RFC 4346, 1682 DOI 10.17487/RFC4346, April 2006, 1683 . 1685 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1686 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 1687 . 1689 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 1690 the Datagram Congestion Control Protocol (DCCP)", 1691 RFC 5238, DOI 10.17487/RFC5238, May 2008, 1692 . 1694 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1695 (TLS) Protocol Version 1.2", RFC 5246, 1696 DOI 10.17487/RFC5246, August 2008, 1697 . 1699 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1700 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1701 RFC 5996, DOI 10.17487/RFC5996, September 2010, 1702 . 1704 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1705 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1706 January 2012, . 1708 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1709 "Recommendations for Secure Use of Transport Layer 1710 Security (TLS) and Datagram Transport Layer Security 1711 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1712 2015, . 1714 [RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme 1715 Updates for Secure Real-time Transport Protocol (SRTP) 1716 Extension for Datagram Transport Layer Security (DTLS)", 1717 RFC 7983, DOI 10.17487/RFC7983, September 2016, 1718 . 1720 13.3. URIs 1722 [1] mailto:tls@ietf.org 1724 [2] https://www1.ietf.org/mailman/listinfo/tls 1726 [3] https://www.ietf.org/mail-archive/web/tls/current/index.html 1728 Appendix A. History 1730 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 1732 IETF Drafts draft-03 - Only update keys after KeyUpdate is ACKed. 1734 draft-02 - Shorten the protected record header and introduce an 1735 ultra-short version of the record header. - Reintroduce KeyUpdate, 1736 which works properly now that we have ACK. - Clarify the ACK rules. 1738 draft-01 - Restructured the ACK to contain a list of packets and also 1739 be a record rather than a handshake message. 1741 draft-00 - First IETF Draft 1743 Personal Drafts draft-01 - Alignment with version -19 of the TLS 1.3 1744 specification 1746 draft-00 1748 - Initial version using TLS 1.3 as a baseline. 1750 - Use of epoch values instead of KeyUpdate message 1752 - Use of cookie extension instead of cookie field in ClientHello and 1753 HelloVerifyRequest messages 1755 - Added ACK message 1757 - Text about sequence number handling 1759 Appendix B. Working Group Information 1761 The discussion list for the IETF TLS working group is located at the 1762 e-mail address tls@ietf.org [1]. Information on the group and 1763 information on how to subscribe to the list is at 1764 https://www1.ietf.org/mailman/listinfo/tls [2] 1766 Archives of the list can be found at: https://www.ietf.org/mail- 1767 archive/web/tls/current/index.html [3] 1769 Appendix C. Contributors 1771 Many people have contributed to previous DTLS versions and they are 1772 acknowledged in prior versions of DTLS specifications. 1774 For this version of the document we would like to thank: 1776 * Ilari Liusvaara 1777 Independent 1778 ilariliusvaara@welho.com 1780 * Martin Thomson 1781 Mozilla 1782 martin.thomson@gmail.com 1784 Authors' Addresses 1786 Eric Rescorla 1787 RTFM, Inc. 1789 EMail: ekr@rtfm.com 1791 Hannes Tschofenig 1792 ARM Limited 1794 EMail: hannes.tschofenig@arm.com 1796 Nagendra Modadugu 1797 Google, Inc. 1799 EMail: nagendra@cs.stanford.edu