idnits 2.17.1 draft-ietf-tls-dtls13-27.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: With these exceptions, the DTLS message formats, flows, and logic are the same as those of TLS 1.3. DTLS implementations SHOULD not use the TLS 1.3 "compatibility mode" described in [I-D.ietf-tls-tls13], Section D.4 and DTLS servers SHOULD ignore the "session_id" value generated by the client rather than sending ChangeCipherSpec messages. Implementations MUST still ignore ChangeCipherSpec messages received during the handshake and at all other times SHOULD treat them as if they had failed to deprotect. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 02, 2018) is 2125 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 951 -- Looks like a reference, but probably isn't: '2' on line 1960 == Missing Reference: 'ACK' is mentioned on line 1485, but not defined == Missing Reference: 'NewSessionTicket' is mentioned on line 1482, but not defined -- Looks like a reference, but probably isn't: '1' on line 1958 -- Looks like a reference, but probably isn't: '3' on line 1963 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-21 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-13) exists of draft-ietf-tls-dtls-connection-id-00 -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 1 error (**), 0 flaws (~~), 7 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: January 3, 2019 N. Modadugu 7 Google, Inc. 8 July 02, 2018 10 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 11 draft-ietf-tls-dtls13-27 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 January 3, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 73 3. DTLS Design Rationale and Overview . . . . . . . . . . . . . 5 74 3.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 6 75 3.1.1. Reordering . . . . . . . . . . . . . . . . . . . . . 7 76 3.1.2. Message Size . . . . . . . . . . . . . . . . . . . . 7 77 3.2. Replay Detection . . . . . . . . . . . . . . . . . . . . 7 78 4. The DTLS Record Layer . . . . . . . . . . . . . . . . . . . . 7 79 4.1. Determining the Header Format . . . . . . . . . . . . . . 10 80 4.2. Sequence Number and Epoch . . . . . . . . . . . . . . . . 11 81 4.2.1. Processing Guidlines . . . . . . . . . . . . . . . . 11 82 4.2.2. Reconstructing the Sequence Number and Epoch . . . . 12 83 4.3. Transport Layer Mapping . . . . . . . . . . . . . . . . . 12 84 4.4. PMTU Issues . . . . . . . . . . . . . . . . . . . . . . . 13 85 4.5. Record Payload Protection . . . . . . . . . . . . . . . . 15 86 4.5.1. Anti-Replay . . . . . . . . . . . . . . . . . . . . . 15 87 4.5.2. Handling Invalid Records . . . . . . . . . . . . . . 15 88 5. The DTLS Handshake Protocol . . . . . . . . . . . . . . . . . 16 89 5.1. Denial-of-Service Countermeasures . . . . . . . . . . . . 17 90 5.2. DTLS Handshake Message Format . . . . . . . . . . . . . . 19 91 5.3. ClientHello Message . . . . . . . . . . . . . . . . . . . 21 92 5.4. Handshake Message Fragmentation and Reassembly . . . . . 22 93 5.5. DTLS Handshake Flights . . . . . . . . . . . . . . . . . 23 94 5.6. Timeout and Retransmission . . . . . . . . . . . . . . . 26 95 5.6.1. State Machine . . . . . . . . . . . . . . . . . . . . 26 96 5.6.2. Timer Values . . . . . . . . . . . . . . . . . . . . 28 98 5.7. CertificateVerify and Finished Messages . . . . . . . . . 29 99 5.8. Alert Messages . . . . . . . . . . . . . . . . . . . . . 29 100 5.9. Establishing New Associations with Existing Parameters . 29 101 6. Example of Handshake with Timeout and Retransmission . . . . 30 102 6.1. Epoch Values and Rekeying . . . . . . . . . . . . . . . . 32 103 7. ACK Message . . . . . . . . . . . . . . . . . . . . . . . . . 34 104 7.1. Sending ACKs . . . . . . . . . . . . . . . . . . . . . . 35 105 7.2. Receiving ACKs . . . . . . . . . . . . . . . . . . . . . 36 106 8. Key Updates . . . . . . . . . . . . . . . . . . . . . . . . . 36 107 9. Connection ID Updates . . . . . . . . . . . . . . . . . . . . 36 108 9.1. ID Example . . . . . . . . . . . . . . . . . . . . . . . 37 109 10. Application Data Protocol . . . . . . . . . . . . . . . . . . 38 110 11. Security Considerations . . . . . . . . . . . . . . . . . . . 39 111 12. Changes to DTLS 1.2 . . . . . . . . . . . . . . . . . . . . . 40 112 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 113 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 114 14.1. Normative References . . . . . . . . . . . . . . . . . . 41 115 14.2. Informative References . . . . . . . . . . . . . . . . . 42 116 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 44 117 Appendix B. Working Group Information . . . . . . . . . . . . . 44 118 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 45 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 121 1. Introduction 123 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH 125 The source for this draft is maintained in GitHub. Suggested changes 126 should be submitted as pull requests at https://github.com/tlswg/ 127 dtls13-spec. Instructions are on that page as well. Editorial 128 changes can be managed in GitHub, but any substantive change should 129 be discussed on the TLS mailing list. 131 The primary goal of the TLS protocol is to provide privacy and data 132 integrity between two communicating peers. The TLS protocol is 133 composed of two layers: the TLS Record Protocol and the TLS Handshake 134 Protocol. However, TLS must run over a reliable transport channel - 135 typically TCP [RFC0793]. 137 There are applications that utilize UDP [RFC0768] as a transport and 138 to offer communication security protection for those applications the 139 Datagram Transport Layer Security (DTLS) protocol has been designed. 140 DTLS is deliberately designed to be as similar to TLS as possible, 141 both to minimize new security invention and to maximize the amount of 142 code and infrastructure reuse. 144 DTLS 1.0 [RFC4347] was originally defined as a delta from TLS 1.1 145 [RFC4346] and DTLS 1.2 [RFC6347] was defined as a series of deltas to 146 TLS 1.2 [RFC5246]. There is no DTLS 1.1; that version number was 147 skipped in order to harmonize version numbers with TLS. This 148 specification describes the most current version of the DTLS protocol 149 aligning with the efforts around TLS 1.3 [I-D.ietf-tls-tls13]. 151 Implementations that speak both DTLS 1.2 and DTLS 1.3 can 152 interoperate with those that speak only DTLS 1.2 (using DTLS 1.2 of 153 course), just as TLS 1.3 implementations can interoperate with TLS 154 1.2 (see Appendix D of [I-D.ietf-tls-tls13] for details). While 155 backwards compatibility with DTLS 1.0 is possible the use of DTLS 1.0 156 is not recommended as explained in Section 3.1.2 of RFC 7525 157 [RFC7525]. 159 2. Conventions and Terminology 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 163 "OPTIONAL" in this document are to be interpreted as described in BCP 164 14 [RFC2119] [RFC8174] when, and only when, they appear in all 165 capitals, as shown here. 167 The following terms are used: 169 - client: The endpoint initiating the DTLS connection. 171 - connection: A transport-layer connection between two endpoints. 173 - endpoint: Either the client or server of the connection. 175 - handshake: An initial negotiation between client and server that 176 establishes the parameters of their transactions. 178 - peer: An endpoint. When discussing a particular endpoint, "peer" 179 refers to the endpoint that is remote to the primary subject of 180 discussion. 182 - receiver: An endpoint that is receiving records. 184 - sender: An endpoint that is transmitting records. 186 - session: An association between a client and a server resulting 187 from a handshake. 189 - server: The endpoint which did not initiate the DTLS connection. 191 The reader is assumed to be familiar with the TLS 1.3 specification 192 since this document is defined as a delta from TLS 1.3. As in TLS 193 1.3 the HelloRetryRequest has the same format as a ServerHello 194 message but for convenience we use the term HelloRetryRequest 195 throughout this document as if it were a distinct message. 197 Figures in this document illustrate various combinations of the DTLS 198 protocol exchanges and the symbols have the following meaning: 200 - '+' indicates noteworthy extensions sent in the previously noted 201 message. 203 - '*' indicates optional or situation-dependent messages/extensions 204 that are not always sent. 206 - '{}' indicates messages protected using keys derived from a 207 [sender]_handshake_traffic_secret. 209 - '[]' indicates messages protected using keys derived from 210 traffic_secret_N. 212 3. DTLS Design Rationale and Overview 214 The basic design philosophy of DTLS is to construct "TLS over 215 datagram transport". Datagram transport does not require nor provide 216 reliable or in-order delivery of data. The DTLS protocol preserves 217 this property for application data. Applications such as media 218 streaming, Internet telephony, and online gaming use datagram 219 transport for communication due to the delay-sensitive nature of 220 transported data. The behavior of such applications is unchanged 221 when the DTLS protocol is used to secure communication, since the 222 DTLS protocol does not compensate for lost or re-ordered data 223 traffic. 225 TLS cannot be used directly in datagram environments for the 226 following five reasons: 228 1. TLS does not allow independent decryption of individual records. 229 Because the integrity check indirectly depends on a sequence 230 number, if record N is not received, then the integrity check on 231 record N+1 will be based on the wrong sequence number and thus 232 will fail. DTLS solves this problem by adding explicit sequence 233 numbers. 235 2. The TLS handshake is a lock-step cryptographic handshake. 236 Messages must be transmitted and received in a defined order; any 237 other order is an error. This is incompatible with reordering 238 and message loss. 240 3. Not all TLS 1.3 handshake messages (such as the NewSessionTicket 241 message) are acknowledged. Hence, a new acknowledgement message 242 has to be added to detect message loss. 244 4. Handshake messages are potentially larger than any given 245 datagram, thus creating the problem of IP fragmentation. 247 5. Datagram transport protocols, like UDP, are susceptible to 248 abusive behavior effecting denial of service attacks against 249 nonparticipants, and require a return-routability check with the 250 help of cookies to be integrated into the handshake. A detailed 251 discussion of countermeasures can be found in Section 5.1. 253 3.1. Packet Loss 255 DTLS uses a simple retransmission timer to handle packet loss. 256 Figure 1 demonstrates the basic concept, using the first phase of the 257 DTLS handshake: 259 Client Server 260 ------ ------ 261 ClientHello ------> 263 X<-- HelloRetryRequest 264 (lost) 266 [Timer Expires] 268 ClientHello ------> 269 (retransmit) 271 Figure 1: DTLS retransmission example 273 Once the client has transmitted the ClientHello message, it expects 274 to see a HelloRetryRequest or a ServerHello from the server. 275 However, if the server's message is lost, the client knows that 276 either the ClientHello or the response from the server has been lost 277 and retransmits. When the server receives the retransmission, it 278 knows to retransmit. 280 The server also maintains a retransmission timer and retransmits when 281 that timer expires. 283 Note that timeout and retransmission do not apply to the 284 HelloRetryRequest since this would require creating state on the 285 server. The HelloRetryRequest is designed to be small enough that it 286 will not itself be fragmented, thus avoiding concerns about 287 interleaving multiple HelloRetryRequests. 289 3.1.1. Reordering 291 In DTLS, each handshake message is assigned a specific sequence 292 number within that handshake. When a peer receives a handshake 293 message, it can quickly determine whether that message is the next 294 message it expects. If it is, then it processes it. If not, it 295 queues it for future handling once all previous messages have been 296 received. 298 3.1.2. Message Size 300 TLS and DTLS handshake messages can be quite large (in theory up to 301 2^24-1 bytes, in practice many kilobytes). By contrast, UDP 302 datagrams are often limited to less than 1500 bytes if IP 303 fragmentation is not desired. In order to compensate for this 304 limitation, each DTLS handshake message may be fragmented over 305 several DTLS records, each of which is intended to fit in a single IP 306 datagram. Each DTLS handshake message contains both a fragment 307 offset and a fragment length. Thus, a recipient in possession of all 308 bytes of a handshake message can reassemble the original unfragmented 309 message. 311 3.2. Replay Detection 313 DTLS optionally supports record replay detection. The technique used 314 is the same as in IPsec AH/ESP, by maintaining a bitmap window of 315 received records. Records that are too old to fit in the window and 316 records that have previously been received are silently discarded. 317 The replay detection feature is optional, since packet duplication is 318 not always malicious, but can also occur due to routing errors. 319 Applications may conceivably detect duplicate packets and accordingly 320 modify their data transmission strategy. 322 4. The DTLS Record Layer 324 The DTLS record layer is different from the TLS 1.3 record layer. 326 1. The DTLSCiphertext structure omits the superfluous version number 327 and type fields. 329 2. DTLS adds an explicit epoch and sequence number to the TLS record 330 header. This sequence number allows the recipient to correctly 331 verify the DTLS MAC. However, the number of bits used for the 332 epoch and sequence number fields in the DTLSCiphertext structure 333 have been reduced. 335 3. The DTLSCiphertext structure has a variable length header. 337 Note that the DTLS 1.3 record layer is different from the DTLS 1.2 338 record layer. 340 DTLSPlaintext records are used to send unprotected records and 341 DTLSCiphertext records are used to send protected records. 343 The DTLS record formats are shown below. Unless explicitly stated 344 the meaning of the fields is unchanged from previous TLS / DTLS 345 versions. 347 struct { 348 ContentType type; 349 ProtocolVersion legacy_record_version; 350 uint16 epoch = 0 // DTLS field 351 uint48 sequence_number; // DTLS field 352 uint16 length; 353 opaque fragment[DTLSPlaintext.length]; 354 } DTLSPlaintext; 356 struct { 357 opaque content[DTLSPlaintext.length]; 358 ContentType type; 359 uint8 zeros[length_of_padding]; 360 } DTLSInnerPlaintext; 362 struct { 363 opaque unified_hdr[variable]; 364 opaque encrypted_record[length]; 365 } DTLSCiphertext; 366 [[OPEN ISSUE: Should we try to find some way to render this?]] 368 Figure 2: DTLS 1.3 Record Format 370 unified_hdr: The unified_hdr is a field of variable length, as shown 371 in Figure 3. 373 encrypted_record: Identical to the encrypted_record field in a TLS 374 1.3 record. 376 The DTLSCiphertext header is tightly bit-packed, as shown below: 378 0 1 2 3 4 5 6 7 379 +-+-+-+-+-+-+-+-+ 380 |0|0|1|C|L|X|X|X| 381 +-+-+-+-+-+-+-+-+ 382 |Ep.| 14 bit | Legend: 383 +-+-+ | 384 |Sequence Number| Ep. - Epoch 385 +-+-+-+-+-+-+-+-+ C - CID present 386 | Connection ID | L - Length present 387 | (if any, | X - Reserved 388 / length as / 389 | negotiated) | 390 +-+-+-+-+-+-+-+-+ 391 | 16 bit Length | 392 | (if present) | 393 +-+-+-+-+-+-+-+-+ 395 Figure 3: DTLS 1.3 CipherText Header 397 Ep. The low order two bits of the epoch. 399 sequence number: The low order 14 bits of the record sequence 400 number. 402 length: Identical to the length field in a TLS 1.3 record. 404 connection ID: Variable length connection ID. The connection ID 405 concept is described in [I-D.ietf-tls-dtls-connection-id]. An 406 example can be found in Section 9.1. 408 As with previous versions of DTLS, multiple DTLSPlaintext and 409 DTLSCiphertext records can be included in the same underlying 410 transport datagram. 412 Figure 4 illustrates different record layer header types. 414 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 415 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 416 | Content Type | |0|0|1|C|L|X|X|X| |0|0|1|0|0|X|X|X| 417 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 418 | 16 bit | |E|E| 14 bit | |E|E| 14 bit | 419 | Version | +-+-+ | +-+-+ | 420 +-+-+-+-+-+-+-+-+ |Sequence Number| |Sequence Number| 421 | 16 bit | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 422 | Epoch | | | | | 423 +-+-+-+-+-+-+-+-+ / Connection ID / | Encrypted | 424 | | | | / Record / 425 | | +-+-+-+-+-+-+-+-+ | | 426 | 48 bit | | 16 bit | +-+-+-+-+-+-+-+-+ 427 |Sequence Number| | Length | 428 | | +-+-+-+-+-+-+-+-+ DTLSCiphertext 429 | | | | Structure 430 +-+-+-+-+-+-+-+-+ | Encrypted | (minimal) 431 | 16 bit | / Record / 432 | Length | | | 433 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 434 | | 435 | | DTLSCiphertext 436 / Fragment / Structure 437 | | (full) 438 +-+-+-+-+-+-+-+-+ 440 DTLSPlaintext 441 Structure 443 Figure 4: Header Examples 445 The length field may be omitted and therefore the record consumes the 446 entire rest of the datagram in the lower level transport. In this 447 case it is not possible to have multiple DTLSCiphertext format 448 records without length fields in the same datagram. 450 Omitting the length field MUST only be used for data which is 451 protected with one of the application_traffic_secret values, and not 452 for messages protected with either [sender]_handshake_traffic_sercret 453 or [sender]_early_traffic_secret values. When using an 454 [sender]_application_traffic_secret for message protection, 455 Implementations MAY include the length field at their discretion. 457 4.1. Determining the Header Format 459 Implementations can distinguish the two header formats by examining 460 the first byte: 462 - If the first byte is alert(21), handshake(22), or ack(proposed, 463 25), the record MUST be interpreted as a DTLSPlaintext record. 465 - If the first byte is any other other value, then receivers MUST 466 check to see if the leading bits of the first byte are 001. If 467 so, the implementation MUST process the record as DTLSCiphertext; 468 the true content type will be inside the protected portion. 470 - Otherwise, the record MUST be rejected as if it had failed 471 deprotection, as described in Section 4.5.2. 473 4.2. Sequence Number and Epoch 475 4.2.1. Processing Guidlines 477 DTLS uses an explicit sequence number, rather than an implicit one, 478 carried in the sequence_number field of the record. Sequence numbers 479 are maintained separately for each epoch, with each sequence_number 480 initially being 0 for each epoch. 482 The epoch number is initially zero and is incremented each time 483 keying material changes and a sender aims to rekey. More details are 484 provided in Section 6.1. 486 Because DTLS records may be reordered, a record from epoch 1 may be 487 received after epoch 2 has begun. In general, implementations SHOULD 488 discard packets from earlier epochs, but if packet loss causes 489 noticeable problems implementations MAY choose to retain keying 490 material from previous epochs for up to the default MSL specified for 491 TCP [RFC0793] to allow for packet reordering. (Note that the 492 intention here is that implementers use the current guidance from the 493 IETF for MSL, as specified in [RFC0793] or successors not that they 494 attempt to interrogate the MSL that the system TCP stack is using.) 495 Until the handshake has completed, implementations MUST accept 496 packets from the old epoch. 498 Conversely, it is possible for records that are protected with the 499 new epoch to be received prior to the completion of a handshake. For 500 instance, the server may send its Finished message and then start 501 transmitting data. Implementations MAY either buffer or discard such 502 packets, though when DTLS is used over reliable transports (e.g., 503 SCTP [RFC4960]), they SHOULD be buffered and processed once the 504 handshake completes. Note that TLS's restrictions on when packets 505 may be sent still apply, and the receiver treats the packets as if 506 they were sent in the right order. In particular, it is still 507 impermissible to send data prior to completion of the first 508 handshake. 510 Note that some care needs to be taken during the handshake to ensure 511 that retransmitted messages use the right epoch and keying material. 513 Implementations MUST either abandon an association or re-key prior to 514 allowing the sequence number to wrap. 516 Implementations MUST NOT allow the epoch to wrap, but instead MUST 517 establish a new association, terminating the old association. 519 4.2.2. Reconstructing the Sequence Number and Epoch 521 When receiving protected DTLS records message, the recipient does not 522 have a full epoch or sequence number value and so there is some 523 opportunity for ambiguity. Because the full epoch and sequence 524 number are used to compute the per-record nonce, failure to 525 reconstruct these values leads to failure to deprotect the record, 526 and so implementations MAY use a mechanism of their choice to 527 determine the full values. This section provides an algorithm which 528 is comparatively simple and which implementations are RECOMMENDED to 529 follow. 531 If the epoch bits match those of the current epoch, then 532 implementations SHOULD reconstruct the sequence number by computing 533 the full sequence number which is numerically closest to one plus the 534 sequence number of the highest successfully deprotected record. 536 During the handshake phase, the epoch bits unambiguously indicate the 537 correct key to use. After the handshake is complete, if the epoch 538 bits do not match those from the current epoch implementations SHOULD 539 use the most recent past epoch which has matching bits, and then 540 reconstruct the sequence number as described above. 542 4.3. Transport Layer Mapping 544 DTLS messages MAY be fragmentmented into multiple DTLS records. Each 545 DTLS record MUST fit within a single datagram. In order to avoid IP 546 fragmentation, clients of the DTLS record layer SHOULD attempt to 547 size records so that they fit within any PMTU estimates obtained from 548 the record layer. 550 Multiple DTLS records MAY be placed in a single datagram. They are 551 simply encoded consecutively. The DTLS record framing is sufficient 552 to determine the boundaries. Note, however, that the first byte of 553 the datagram payload MUST be the beginning of a record. Records MUST 554 NOT span datagrams. 556 DTLS records, as defined in this document, do not contain any 557 association identifiers and applications must arrange to multiplex 558 between associations. With UDP, the host/port number is used to look 559 up the appropriate security association for incoming records. 560 However, the Connection ID extension defined in 561 [I-D.ietf-tls-dtls-connection-id] adds an association identifier to 562 DTLS records. 564 Some transports, such as DCCP [RFC4340], provide their own sequence 565 numbers. When carried over those transports, both the DTLS and the 566 transport sequence numbers will be present. Although this introduces 567 a small amount of inefficiency, the transport layer and DTLS sequence 568 numbers serve different purposes; therefore, for conceptual 569 simplicity, it is superior to use both sequence numbers. 571 Some transports provide congestion control for traffic carried over 572 them. If the congestion window is sufficiently narrow, DTLS 573 handshake retransmissions may be held rather than transmitted 574 immediately, potentially leading to timeouts and spurious 575 retransmission. When DTLS is used over such transports, care should 576 be taken not to overrun the likely congestion window. [RFC5238] 577 defines a mapping of DTLS to DCCP that takes these issues into 578 account. 580 4.4. PMTU Issues 582 In general, DTLS's philosophy is to leave PMTU discovery to the 583 application. However, DTLS cannot completely ignore PMTU for three 584 reasons: 586 - The DTLS record framing expands the datagram size, thus lowering 587 the effective PMTU from the application's perspective. 589 - In some implementations, the application may not directly talk to 590 the network, in which case the DTLS stack may absorb ICMP 591 [RFC1191] "Datagram Too Big" indications or ICMPv6 [RFC4443] 592 "Packet Too Big" indications. 594 - The DTLS handshake messages can exceed the PMTU. 596 In order to deal with the first two issues, the DTLS record layer 597 SHOULD behave as described below. 599 If PMTU estimates are available from the underlying transport 600 protocol, they should be made available to upper layer protocols. In 601 particular: 603 - For DTLS over UDP, the upper layer protocol SHOULD be allowed to 604 obtain the PMTU estimate maintained in the IP layer. 606 - For DTLS over DCCP, the upper layer protocol SHOULD be allowed to 607 obtain the current estimate of the PMTU. 609 - For DTLS over TCP or SCTP, which automatically fragment and 610 reassemble datagrams, there is no PMTU limitation. However, the 611 upper layer protocol MUST NOT write any record that exceeds the 612 maximum record size of 2^14 bytes. 614 The DTLS record layer SHOULD allow the upper layer protocol to 615 discover the amount of record expansion expected by the DTLS 616 processing. 618 If there is a transport protocol indication (either via ICMP or via a 619 refusal to send the datagram as in Section 14 of [RFC4340]), then the 620 DTLS record layer MUST inform the upper layer protocol of the error. 622 The DTLS record layer SHOULD NOT interfere with upper layer protocols 623 performing PMTU discovery, whether via [RFC1191] or [RFC4821] 624 mechanisms. In particular: 626 - Where allowed by the underlying transport protocol, the upper 627 layer protocol SHOULD be allowed to set the state of the DF bit 628 (in IPv4) or prohibit local fragmentation (in IPv6). 630 - If the underlying transport protocol allows the application to 631 request PMTU probing (e.g., DCCP), the DTLS record layer SHOULD 632 honor this request. 634 The final issue is the DTLS handshake protocol. From the perspective 635 of the DTLS record layer, this is merely another upper layer 636 protocol. However, DTLS handshakes occur infrequently and involve 637 only a few round trips; therefore, the handshake protocol PMTU 638 handling places a premium on rapid completion over accurate PMTU 639 discovery. In order to allow connections under these circumstances, 640 DTLS implementations SHOULD follow the following rules: 642 - If the DTLS record layer informs the DTLS handshake layer that a 643 message is too big, it SHOULD immediately attempt to fragment it, 644 using any existing information about the PMTU. 646 - If repeated retransmissions do not result in a response, and the 647 PMTU is unknown, subsequent retransmissions SHOULD back off to a 648 smaller record size, fragmenting the handshake message as 649 appropriate. This standard does not specify an exact number of 650 retransmits to attempt before backing off, but 2-3 seems 651 appropriate. 653 4.5. Record Payload Protection 655 Like TLS, DTLS transmits data as a series of protected records. The 656 rest of this section describes the details of that format. 658 4.5.1. Anti-Replay 660 Each DTLS record contains a sequence number to provide replay 661 protection. Sequence number verification SHOULD be performed using 662 the following sliding window procedure, borrowed from Section 3.4.3 663 of [RFC4303]. 665 The received packet counter for a session MUST be initialized to zero 666 when that session is established. For each received record, the 667 receiver MUST verify that the record contains a sequence number that 668 does not duplicate the sequence number of any other record received 669 during the lifetime of the session. This SHOULD be the first check 670 applied to a packet after it has been matched to a session, to speed 671 up the rejection of duplicate records. 673 Duplicates are rejected through the use of a sliding receive window. 674 (How the window is implemented is a local matter, but the following 675 text describes the functionality that the implementation must 676 exhibit.) A minimum window size of 32 MUST be supported, but a 677 window size of 64 is preferred and SHOULD be employed as the default. 678 Another window size (larger than the minimum) MAY be chosen by the 679 receiver. (The receiver does not notify the sender of the window 680 size.) 682 The "right" edge of the window represents the highest validated 683 sequence number value received on the session. Records that contain 684 sequence numbers lower than the "left" edge of the window are 685 rejected. Packets falling within the window are checked against a 686 list of received packets within the window. An efficient means for 687 performing this check, based on the use of a bit mask, is described 688 in Section 3.4.3 of [RFC4303]. 690 If the received record falls within the window and is new, or if the 691 packet is to the right of the window, then the receiver proceeds to 692 MAC verification. If the MAC validation fails, the receiver MUST 693 discard the received record as invalid. The receive window is 694 updated only if the MAC verification succeeds. 696 4.5.2. Handling Invalid Records 698 Unlike TLS, DTLS is resilient in the face of invalid records (e.g., 699 invalid formatting, length, MAC, etc.). In general, invalid records 700 SHOULD be silently discarded, thus preserving the association; 701 however, an error MAY be logged for diagnostic purposes. 702 Implementations which choose to generate an alert instead, MUST 703 generate error alerts to avoid attacks where the attacker repeatedly 704 probes the implementation to see how it responds to various types of 705 error. Note that if DTLS is run over UDP, then any implementation 706 which does this will be extremely susceptible to denial-of-service 707 (DoS) attacks because UDP forgery is so easy. Thus, this practice is 708 NOT RECOMMENDED for such transports, both to increase the reliability 709 of DTLS service and to avoid the risk of spoofing attacks sending 710 traffic to unrelated third parties. 712 If DTLS is being carried over a transport that is resistant to 713 forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts 714 because an attacker will have difficulty forging a datagram that will 715 not be rejected by the transport layer. 717 5. The DTLS Handshake Protocol 719 DTLS 1.3 re-uses the TLS 1.3 handshake messages and flows, with the 720 following changes: 722 1. To handle message loss, reordering, and fragmentation 723 modifications to the handshake header are necessary. 725 2. Retransmission timers are introduced to handle message loss. 727 3. A new ACK content type has been added for reliable message 728 delivery of handshake messages. 730 Note that TLS 1.3 already supports a cookie extension, which is used 731 to prevent denial-of-service attacks. This DoS prevention mechanism 732 is described in more detail below since UDP-based protocols are more 733 vulnerable to amplification attacks than a connection-oriented 734 transport like TCP that performs return-routability checks as part of 735 the connection establishment. 737 With these exceptions, the DTLS message formats, flows, and logic are 738 the same as those of TLS 1.3. DTLS implementations SHOULD not use 739 the TLS 1.3 "compatibility mode" described in [I-D.ietf-tls-tls13], 740 Section D.4 and DTLS servers SHOULD ignore the "session_id" value 741 generated by the client rather than sending ChangeCipherSpec 742 messages. Implementations MUST still ignore ChangeCipherSpec 743 messages received during the handshake and at all other times SHOULD 744 treat them as if they had failed to deprotect. 746 5.1. Denial-of-Service Countermeasures 748 Datagram security protocols are extremely susceptible to a variety of 749 DoS attacks. Two attacks are of particular concern: 751 1. An attacker can consume excessive resources on the server by 752 transmitting a series of handshake initiation requests, causing 753 the server to allocate state and potentially to perform expensive 754 cryptographic operations. 756 2. An attacker can use the server as an amplifier by sending 757 connection initiation messages with a forged source of the 758 victim. The server then sends its response to the victim 759 machine, thus flooding it. Depending on the selected ciphersuite 760 this response message can be quite large, as it is the case for a 761 Certificate message. 763 In order to counter both of these attacks, DTLS borrows the stateless 764 cookie technique used by Photuris [RFC2522] and IKE [RFC7296]. When 765 the client sends its ClientHello message to the server, the server 766 MAY respond with a HelloRetryRequest message. The HelloRetryRequest 767 message, as well as the cookie extension, is defined in TLS 1.3. The 768 HelloRetryRequest message contains a stateless cookie generated using 769 the technique of [RFC2522]. The client MUST retransmit the 770 ClientHello with the cookie added as an extension. The server then 771 verifies the cookie and proceeds with the handshake only if it is 772 valid. This mechanism forces the attacker/client to be able to 773 receive the cookie, which makes DoS attacks with spoofed IP addresses 774 difficult. This mechanism does not provide any defence against DoS 775 attacks mounted from valid IP addresses. 777 The DTLS 1.3 specification changes the way how cookies are exchanged 778 compared to DTLS 1.2. DTLS 1.3 re-uses the HelloRetryRequest message 779 and conveys the cookie to the client via an extension. The client 780 receiving the cookie uses the same extension to place the cookie 781 subsequently into a ClientHello message. DTLS 1.2 on the other hand 782 used a separate message, namely the HelloVerifyRequest, to pass a 783 cookie to the client and did not utilize the extension mechanism. 784 For backwards compatibility reason the cookie field in the 785 ClientHello is present in DTLS 1.3 but is ignored by a DTLS 1.3 786 compliant server implementation. 788 The exchange is shown in Figure 5. Note that the figure focuses on 789 the cookie exchange; all other extensions are omitted. 791 Client Server 792 ------ ------ 793 ClientHello ------> 795 <----- HelloRetryRequest 796 + cookie 798 ClientHello ------> 799 + cookie 801 [Rest of handshake] 803 Figure 5: DTLS exchange with HelloRetryRequest containing the 804 "cookie" extension 806 The cookie extension is defined in Section 4.2.2 of 807 [I-D.ietf-tls-tls13]. When sending the initial ClientHello, the 808 client does not have a cookie yet. In this case, the cookie 809 extension is omitted and the legacy_cookie field in the ClientHello 810 message SHOULD be set to a zero length vector (i.e., a single zero 811 byte length field) and MUST be ignored by a server negotiating DTLS 812 1.3. 814 When responding to a HelloRetryRequest, the client MUST create a new 815 ClientHello message following the description in Section 4.1.2 of 816 [I-D.ietf-tls-tls13]. 818 If the HelloRetryRequest message is used, the initial ClientHello and 819 the HelloRetryRequest are included in the calculation of the 820 Transcript-Hash. The computation of the message hash for the 821 HelloRetryRequest is done according to the description in 822 Section 4.4.1 of [I-D.ietf-tls-tls13]. 824 The handshake transcript is not reset with the second ClientHello and 825 a stateless server-cookie implementation requires the transcript of 826 the HelloRetryRequest to be stored in the cookie or the internal 827 state of the hash algorithm, since only the hash of the transcript is 828 required for the handshake to complete. 830 When the second ClientHello is received, the server can verify that 831 the cookie is valid and that the client can receive packets at the 832 given IP address. If the client's apparent IP address is embedded in 833 the cookie, this prevents an attacker from generating an acceptable 834 ClientHello apparently from another user. 836 One potential attack on this scheme is for the attacker to collect a 837 number of cookies from different addresses where it controls 838 endpoints and then reuse them to attack the server. The server can 839 defend against this attack by changing the secret value frequently, 840 thus invalidating those cookies. If the server wishes that 841 legitimate clients be able to handshake through the transition (e.g., 842 they received a cookie with Secret 1 and then sent the second 843 ClientHello after the server has changed to Secret 2), the server can 844 have a limited window during which it accepts both secrets. 845 [RFC7296] suggests adding a key identifier to cookies to detect this 846 case. An alternative approach is simply to try verifying with both 847 secrets. It is RECOMMENDED that servers implement a key rotation 848 scheme that allows the server to manage keys with overlapping 849 lifetime. 851 Alternatively, the server can store timestamps in the cookie and 852 reject those cookies that were not generated within a certain amount 853 of time. 855 DTLS servers SHOULD perform a cookie exchange whenever a new 856 handshake is being performed. If the server is being operated in an 857 environment where amplification is not a problem, the server MAY be 858 configured not to perform a cookie exchange. The default SHOULD be 859 that the exchange is performed, however. In addition, the server MAY 860 choose not to do a cookie exchange when a session is resumed. 861 Clients MUST be prepared to do a cookie exchange with every 862 handshake. 864 If a server receives a ClientHello with an invalid cookie, it MUST 865 NOT respond with a HelloRetryRequest. Restarting the handshake from 866 scratch, without a cookie, allows the client to recover from a 867 situation where it obtained a cookie that cannot be verified by the 868 server. As described in Section 4.1.4 of [I-D.ietf-tls-tls13], 869 clients SHOULD also abort the handshake with an "unexpected_message" 870 alert in response to any second HelloRetryRequest which was sent in 871 the same connection (i.e., where the ClientHello was itself in 872 response to a HelloRetryRequest). 874 5.2. DTLS Handshake Message Format 876 In order to support message loss, reordering, and message 877 fragmentation, DTLS modifies the TLS 1.3 handshake header: 879 enum { 880 hello_request_RESERVED(0), 881 client_hello(1), 882 server_hello(2), 883 hello_verify_request_RESERVED(3), 884 new_session_ticket(4), 885 end_of_early_data(5), 886 hello_retry_request_RESERVED(6), 887 encrypted_extensions(8), 888 certificate(11), 889 server_key_exchange_RESERVED(12), 890 certificate_request(13), 891 server_hello_done_RESERVED(14), 892 certificate_verify(15), 893 client_key_exchange_RESERVED(16), 894 finished(20), 895 key_update(24), 896 message_hash(254), 897 (255) 898 } HandshakeType; 900 struct { 901 HandshakeType msg_type; /* handshake type */ 902 uint24 length; /* bytes in message */ 903 uint16 message_seq; /* DTLS-required field */ 904 uint24 fragment_offset; /* DTLS-required field */ 905 uint24 fragment_length; /* DTLS-required field */ 906 select (HandshakeType) { 907 case client_hello: ClientHello; 908 case server_hello: ServerHello; 909 case end_of_early_data: EndOfEarlyData; 910 case encrypted_extensions: EncryptedExtensions; 911 case certificate_request: CertificateRequest; 912 case certificate: Certificate; 913 case certificate_verify: CertificateVerify; 914 case finished: Finished; 915 case new_session_ticket: NewSessionTicket; 916 case key_update: KeyUpdate; 917 } body; 918 } Handshake; 920 The first message each side transmits in each association always has 921 message_seq = 0. Whenever a new message is generated, the 922 message_seq value is incremented by one. When a message is 923 retransmitted, the old message_seq value is re-used, i.e., not 924 incremented. From the perspective of the DTLS record layer, the 925 retransmission is a new record. This record will have a new 926 DTLSPlaintext.sequence_number value. 928 DTLS implementations maintain (at least notionally) a 929 next_receive_seq counter. This counter is initially set to zero. 930 When a handshake message is received, if its message_seq value 931 matches next_receive_seq, next_receive_seq is incremented and the 932 message is processed. If the sequence number is less than 933 next_receive_seq, the message MUST be discarded. If the sequence 934 number is greater than next_receive_seq, the implementation SHOULD 935 queue the message but MAY discard it. (This is a simple space/ 936 bandwidth tradeoff). 938 In addition to the handshake messages that are deprecated by the TLS 939 1.3 specification DTLS 1.3 furthermore deprecates the 940 HelloVerifyRequest message originally defined in DTLS 1.0. DTLS 941 1.3-compliant implements MUST NOT use the HelloVerifyRequest to 942 execute a return-routability check. A dual-stack DTLS 1.2/DTLS 1.3 943 client MUST, however, be prepared to interact with a DTLS 1.2 server. 945 5.3. ClientHello Message 947 The format of the ClientHello used by a DTLS 1.3 client differs from 948 the TLS 1.3 ClientHello format as shown below. 950 uint16 ProtocolVersion; 951 opaque Random[32]; 953 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 955 struct { 956 ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2 957 Random random; 958 opaque legacy_session_id<0..32>; 959 opaque legacy_cookie<0..2^8-1>; // DTLS 960 CipherSuite cipher_suites<2..2^16-2>; 961 opaque legacy_compression_methods<1..2^8-1>; 962 Extension extensions<8..2^16-1>; 963 } ClientHello; 965 legacy_version: In previous versions of DTLS, this field was used 966 for version negotiation and represented the highest version number 967 supported by the client. Experience has shown that many servers 968 do not properly implement version negotiation, leading to "version 969 intolerance" in which the server rejects an otherwise acceptable 970 ClientHello with a version number higher than it supports. In 971 DTLS 1.3, the client indicates its version preferences in the 972 "supported_versions" extension (see Section 4.2.1 of 973 [I-D.ietf-tls-tls13]) and the legacy_version field MUST be set to 974 {254, 253}, which was the version number for DTLS 1.2. 976 random: Same as for TLS 1.3. 978 legacy_session_id: Same as for TLS 1.3. 980 legacy_cookie: A DTLS 1.3-only client MUST set the legacy_cookie 981 field to zero length. 983 cipher_suites: Same as for TLS 1.3. 985 legacy_compression_methods: Same as for TLS 1.3. 987 extensions: Same as for TLS 1.3. 989 5.4. Handshake Message Fragmentation and Reassembly 991 Each DTLS message MUST fit within a single transport layer datagram. 992 However, handshake messages are potentially bigger than the maximum 993 record size. Therefore, DTLS provides a mechanism for fragmenting a 994 handshake message over a number of records, each of which can be 995 transmitted separately, thus avoiding IP fragmentation. 997 When transmitting the handshake message, the sender divides the 998 message into a series of N contiguous data ranges. These ranges MUST 999 NOT be larger than the maximum handshake fragment size and MUST 1000 jointly contain the entire handshake message. The ranges MUST NOT 1001 overlap. The sender then creates N handshake messages, all with the 1002 same message_seq value as the original handshake message. Each new 1003 message is labeled with the fragment_offset (the number of bytes 1004 contained in previous fragments) and the fragment_length (the length 1005 of this fragment). The length field in all messages is the same as 1006 the length field of the original message. An unfragmented message is 1007 a degenerate case with fragment_offset=0 and fragment_length=length. 1009 When a DTLS implementation receives a handshake message fragment, it 1010 MUST buffer it until it has the entire handshake message. DTLS 1011 implementations MUST be able to handle overlapping fragment ranges. 1012 This allows senders to retransmit handshake messages with smaller 1013 fragment sizes if the PMTU estimate changes. 1015 Note that as with TLS, multiple handshake messages may be placed in 1016 the same DTLS record, provided that there is room and that they are 1017 part of the same flight. Thus, there are two acceptable ways to pack 1018 two DTLS messages into the same datagram: in the same record or in 1019 separate records. 1021 5.5. DTLS Handshake Flights 1023 DTLS messages are grouped into a series of message flights, according 1024 to the diagrams below. 1026 Client Server 1028 ClientHello +----------+ 1029 + key_share* | Flight 1 | 1030 + pre_shared_key* --------> +----------+ 1032 +----------+ 1033 <-------- HelloRetryRequest | Flight 2 | 1034 + cookie +----------+ 1036 ClientHello +----------+ 1037 + key_share* | Flight 3 | 1038 + pre_shared_key* --------> +----------+ 1039 + cookie 1041 ServerHello 1042 + key_share* 1043 + pre_shared_key* +----------+ 1044 {EncryptedExtensions} | Flight 4 | 1045 {CertificateRequest*} +----------+ 1046 {Certificate*} 1047 {CertificateVerify*} 1048 <-------- {Finished} 1049 [Application Data*] 1051 {Certificate*} +----------+ 1052 {CertificateVerify*} | Flight 5 | 1053 {Finished} --------> +----------+ 1054 [Application Data] 1056 +----------+ 1057 <-------- [ACK] | Flight 6 | 1058 [Application Data*] +----------+ 1060 [Application Data] <-------> [Application Data] 1062 Figure 6: Message flights for a full DTLS Handshake (with cookie 1063 exchange) 1065 ClientHello +----------+ 1066 + pre_shared_key | Flight 1 | 1067 + key_share* --------> +----------+ 1069 ServerHello 1070 + pre_shared_key +----------+ 1071 + key_share* | Flight 2 | 1072 {EncryptedExtensions} +----------+ 1073 <-------- {Finished} 1074 [Application Data*] 1075 +----------+ 1076 {Finished} --------> | Flight 3 | 1077 [Application Data*] +----------+ 1079 +----------+ 1080 <-------- [ACK] | Flight 4 | 1081 [Application Data*] +----------+ 1083 [Application Data] <-------> [Application Data] 1085 Figure 7: Message flights for resumption and PSK handshake (without 1086 cookie exchange) 1088 Client Server 1090 ClientHello 1091 + early_data 1092 + psk_key_exchange_modes +----------+ 1093 + key_share* | Flight 1 | 1094 + pre_shared_key +----------+ 1095 (Application Data*) --------> 1097 ServerHello 1098 + pre_shared_key 1099 + key_share* +----------+ 1100 {EncryptedExtensions} | Flight 2 | 1101 {Finished} +----------+ 1102 <-------- [Application Data*] 1104 +----------+ 1105 (EndOfEarlyData) | Flight 3 | 1106 {Finished} --------> +----------+ 1107 [Application Data*] 1108 +----------+ 1109 <-------- [ACK] | Flight 4 | 1110 [Application Data*] +----------+ 1112 [Application Data] <-------> [Application Data] 1114 Figure 8: Message flights for the Zero-RTT handshake 1116 Client Server 1118 +----------+ 1119 <-------- [NewSessionTicket] | Flight 1 | 1120 +----------+ 1122 +----------+ 1123 [ACK] --------> | Flight 2 | 1124 +----------+ 1126 Figure 9: Message flights for the new session ticket message 1128 Note: The application data sent by the client is not included in the 1129 timeout and retransmission calculation. 1131 5.6. Timeout and Retransmission 1133 5.6.1. State Machine 1135 DTLS uses a simple timeout and retransmission scheme with the state 1136 machine shown in Figure 10. Because DTLS clients send the first 1137 message (ClientHello), they start in the PREPARING state. DTLS 1138 servers start in the WAITING state, but with empty buffers and no 1139 retransmit timer. 1141 +-----------+ 1142 | PREPARING | 1143 +----------> | | 1144 | | | 1145 | +-----------+ 1146 | | 1147 | | Buffer next flight 1148 | | 1149 | \|/ 1150 | +-----------+ 1151 | | | 1152 | | SENDING |<------------------+ 1153 | | | | 1154 | +-----------+ | 1155 Receive | | | 1156 next | | Send flight or partial | 1157 flight | | flight | 1158 | +---------------+ | 1159 | | | Set retransmit timer | 1160 | | \|/ | 1161 | | +-----------+ | 1162 | | | | | 1163 +--)---------| WAITING |-------------------+ 1164 | | +----->| | Timer expires | 1165 | | | +-----------+ | 1166 | | | | | | | 1167 | | | | | | | 1168 | | +----------+ | +--------------------+ 1169 | | Receive record | Read retransmit or ACK 1170 Receive | | Send ACK | 1171 last | | | 1172 flight | | | Receive ACK 1173 | | | for last flight 1174 \|/\|/ | 1175 | 1176 +-----------+ | 1177 | | <---------+ 1178 | FINISHED | 1179 | | 1180 +-----------+ 1181 | /|\ 1182 | | 1183 | | 1184 +---+ 1186 Server read retransmit 1187 Retransmit ACK 1189 Figure 10: DTLS timeout and retransmission state machine 1191 The state machine has four basic states: PREPARING, SENDING, WAITING, 1192 and FINISHED. 1194 In the PREPARING state, the implementation does whatever computations 1195 are necessary to prepare the next flight of messages. It then 1196 buffers them up for transmission (emptying the buffer first) and 1197 enters the SENDING state. 1199 In the SENDING state, the implementation transmits the buffered 1200 flight of messages. If the implementation has received one or more 1201 ACKs (see Section 7) from the peer, then it SHOULD omit any messages 1202 or message fragments which have already been ACKed. Once the 1203 messages have been sent, the implementation then enters the FINISHED 1204 state if this is the last flight in the handshake. Or, if the 1205 implementation expects to receive more messages, it sets a retransmit 1206 timer and then enters the WAITING state. 1208 There are four ways to exit the WAITING state: 1210 1. The retransmit timer expires: the implementation transitions to 1211 the SENDING state, where it retransmits the flight, resets the 1212 retransmit timer, and returns to the WAITING state. 1214 2. The implementation reads a ACK from the peer: upon receiving an 1215 ACK for a partial flight (as mentioned in Section 7.1), the 1216 implementation transitions to the SENDING state, where it 1217 retransmits the unacked portion of the flight, resets the 1218 retransmit timer, and returns to the WAITING state. Upon 1219 receiving an ACK for a complete flight, the implementation 1220 cancels all retransmissions and either remains in WAITING, or, if 1221 the ACK was for the final flight, transitions to FINISHED. 1223 3. The implementation reads a retransmitted flight from the peer: 1224 the implementation transitions to the SENDING state, where it 1225 retransmits the flight, resets the retransmit timer, and returns 1226 to the WAITING state. The rationale here is that the receipt of 1227 a duplicate message is the likely result of timer expiry on the 1228 peer and therefore suggests that part of one's previous flight 1229 was lost. 1231 4. The implementation receives some or all next flight of messages: 1232 if this is the final flight of messages, the implementation 1233 transitions to FINISHED. If the implementation needs to send a 1234 new flight, it transitions to the PREPARING state. Partial reads 1235 (whether partial messages or only some of the messages in the 1236 flight) may also trigger the implementation to send an ACK, as 1237 described in Section 7.1. 1239 Because DTLS clients send the first message (ClientHello), they start 1240 in the PREPARING state. DTLS servers start in the WAITING state, but 1241 with empty buffers and no retransmit timer. 1243 In addition, for at least twice the default Maximum Segment Lifetime 1244 (MSL) defined for [RFC0793], when in the FINISHED state, the server 1245 MUST respond to retransmission of the client's second flight with a 1246 retransmit of its ACK. 1248 Note that because of packet loss, it is possible for one side to be 1249 sending application data even though the other side has not received 1250 the first side's Finished message. Implementations MUST either 1251 discard or buffer all application data packets for the new epoch 1252 until they have received the Finished message for that epoch. 1253 Implementations MAY treat receipt of application data with a new 1254 epoch prior to receipt of the corresponding Finished message as 1255 evidence of reordering or packet loss and retransmit their final 1256 flight immediately, shortcutting the retransmission timer. 1258 5.6.2. Timer Values 1260 Though timer values are the choice of the implementation, mishandling 1261 of the timer can lead to serious congestion problems; for example, if 1262 many instances of a DTLS time out early and retransmit too quickly on 1263 a congested link. Implementations SHOULD use an initial timer value 1264 of 100 msec (the minimum defined in RFC 6298 [RFC6298]) and double 1265 the value at each retransmission, up to no less than the RFC 6298 1266 maximum of 60 seconds. Application specific profiles, such as those 1267 used for the Internet of Things environment, may recommend longer 1268 timer values. Note that a 100 msec timer is recommend rather than 1269 the 3-second RFC 6298 default in order to improve latency for time- 1270 sensitive applications. Because DTLS only uses retransmission for 1271 handshake and not dataflow, the effect on congestion should be 1272 minimal. 1274 Implementations SHOULD retain the current timer value until a 1275 transmission without loss occurs, at which time the value may be 1276 reset to the initial value. After a long period of idleness, no less 1277 than 10 times the current timer value, implementations may reset the 1278 timer to the initial value. One situation where this might occur is 1279 when a rehandshake is used after substantial data transfer. 1281 5.7. CertificateVerify and Finished Messages 1283 CertificateVerify and Finished messages have the same format as in 1284 TLS 1.3. Hash calculations include entire handshake messages, 1285 including DTLS-specific fields: message_seq, fragment_offset, and 1286 fragment_length. However, in order to remove sensitivity to 1287 handshake message fragmentation, the CertificateVerify and the 1288 Finished messages MUST be computed as if each handshake message had 1289 been sent as a single fragment following the algorithm described in 1290 Section 4.4.3 and Section 4.4.4 of [I-D.ietf-tls-tls13], 1291 respectively. 1293 5.8. Alert Messages 1295 Note that Alert messages are not retransmitted at all, even when they 1296 occur in the context of a handshake. However, a DTLS implementation 1297 which would ordinarily issue an alert SHOULD generate a new alert 1298 message if the offending record is received again (e.g., as a 1299 retransmitted handshake message). Implementations SHOULD detect when 1300 a peer is persistently sending bad messages and terminate the local 1301 connection state after such misbehavior is detected. 1303 5.9. Establishing New Associations with Existing Parameters 1305 If a DTLS client-server pair is configured in such a way that 1306 repeated connections happen on the same host/port quartet, then it is 1307 possible that a client will silently abandon one connection and then 1308 initiate another with the same parameters (e.g., after a reboot). 1309 This will appear to the server as a new handshake with epoch=0. In 1310 cases where a server believes it has an existing association on a 1311 given host/port quartet and it receives an epoch=0 ClientHello, it 1312 SHOULD proceed with a new handshake but MUST NOT destroy the existing 1313 association until the client has demonstrated reachability either by 1314 completing a cookie exchange or by completing a complete handshake 1315 including delivering a verifiable Finished message. After a correct 1316 Finished message is received, the server MUST abandon the previous 1317 association to avoid confusion between two valid associations with 1318 overlapping epochs. The reachability requirement prevents off-path/ 1319 blind attackers from destroying associations merely by sending forged 1320 ClientHellos. 1322 Note: it is not always possible to distinguish which association a 1323 given packet is from. For instance, if the client performs a 1324 handshake, abandons the connection, and then immediately starts a new 1325 handshake, it may not be possible to tell which connection a given 1326 protected record is for. In these cases, trial decryption MAY be 1327 necessary, though implementations could also use some sort of 1328 connection identifier, such as the one specified in 1329 [I-D.rescorla-tls-dtls-connection-id]. 1331 6. Example of Handshake with Timeout and Retransmission 1333 The following is an example of a handshake with lost packets and 1334 retransmissions. 1336 Client Server 1337 ------ ------ 1339 Record 0 --------> 1340 ClientHello 1341 (message_seq=0) 1342 +cookie 1344 X<----- Record 0 1345 (lost) ServerHello 1346 (message_seq=1) 1347 EncryptedExtensions 1348 (message_seq=2) 1349 Certificate 1350 (message_seq=3) 1352 <-------- Record 1 1353 CertificateVerify 1354 (message_seq=4) 1355 Finished 1356 (message_seq=5) 1358 Record 1 --------> 1359 ACK [1] 1361 <-------- Record 2 1362 ServerHello 1363 (message_seq=1) 1364 EncryptedExtensions 1365 (message_seq=2) 1366 Certificate 1367 (message_seq=3) 1369 Record 2 --------> 1370 Certificate 1371 (message_seq=2) 1372 CertificateVerify 1373 (message_seq=3) 1374 Finished 1375 (message_seq=4) 1377 <-------- Record 3 1378 ACK [2] 1380 Figure 11: Example DTLS exchange illustrating message loss 1382 6.1. Epoch Values and Rekeying 1384 A recipient of a DTLS message needs to select the correct keying 1385 material in order to process an incoming message. With the 1386 possibility of message loss and re-order an identifier is needed to 1387 determine which cipher state has been used to protect the record 1388 payload. The epoch value fulfills this role in DTLS. In addition to 1389 the key derivation steps described in Section 7 of 1390 [I-D.ietf-tls-tls13] triggered by the states during the handshake a 1391 sender may want to rekey at any time during the lifetime of the 1392 connection and has to have a way to indicate that it is updating its 1393 sending cryptographic keys. 1395 This version of DTLS assigns dedicated epoch values to messages in 1396 the protocol exchange to allow identification of the correct cipher 1397 state: 1399 - epoch value (0) is used with unencrypted messages. There are 1400 three unencrypted messages in DTLS, namely ClientHello, 1401 ServerHello, and HelloRetryRequest. 1403 - epoch value (1) is used for messages protected using keys derived 1404 from client_early_traffic_secret. This includes early data sent 1405 by the client and the EndOfEarlyData message. 1407 - epoch value (2) is used for messages protected using keys derived 1408 from [sender]_handshake_traffic_secret. Messages transmitted 1409 during the initial handshake, such as EncryptedExtensions, 1410 CertificateRequest, Certificate, CertificateVerify, and Finished 1411 belong to this category. Note, however, post-handshake are 1412 protected under the appropriate application traffic key and are 1413 not included in this category. 1415 - epoch value (3) is used for payloads protected using keys derived 1416 from the initial traffic_secret_0. This may include handshake 1417 messages, such as post-handshake messages (e.g., a 1418 NewSessionTicket message). 1420 - epoch value (4 to 2^16-1) is used for payloads protected using 1421 keys from the traffic_secret_N (N>0). 1423 Using these reserved epoch values a receiver knows what cipher state 1424 has been used to encrypt and integrity protect a message. 1425 Implementations that receive a payload with an epoch value for which 1426 no corresponding cipher state can be determined MUST generate a 1427 "unexpected_message" alert. For example, client incorrectly uses 1428 epoch value 5 when sending early application data in a 0-RTT 1429 exchange. A server will not be able to compute the appropriate keys 1430 and will therefore have to respond with an alert. 1432 Note that epoch values do not wrap. If a DTLS implementation would 1433 need to wrap the epoch value, it MUST terminate the connection. 1435 The traffic key calculation is described in Section 7.3 of 1436 [I-D.ietf-tls-tls13]. 1438 Figure 12 illustrates the epoch values in an example DTLS handshake. 1440 Client Server 1441 ------ ------ 1443 ClientHello 1444 (epoch=0) 1445 --------> 1447 <-------- HelloRetryRequest 1448 (epoch=0) 1450 ClientHello --------> 1451 (epoch=0) 1453 <-------- ServerHello 1454 (epoch=0) 1455 {EncryptedExtensions} 1456 (epoch=2) 1457 {Certificate} 1458 (epoch=2) 1459 {CertificateVerify} 1460 (epoch=2) 1461 {Finished} 1462 (epoch=2) 1464 {Certificate} --------> 1465 (epoch=2) 1466 {CertificateVerify} 1467 (epoch=2) 1468 {Finished} 1469 (epoch=2) 1471 <-------- [ACK] 1472 (epoch=3) 1474 [Application Data] --------> 1475 (epoch=3) 1476 <-------- [Application Data] 1477 (epoch=3) 1479 Some time later ... 1480 (Post-Handshake Message Exchange) 1482 <-------- [NewSessionTicket] 1483 (epoch=3) 1485 [ACK] --------> 1486 (epoch=3) 1488 Some time later ... 1489 (Rekeying) 1491 <-------- [Application Data] 1492 (epoch=4) 1493 [Application Data] --------> 1494 (epoch=4) 1496 Figure 12: Example DTLS exchange with epoch information 1498 7. ACK Message 1500 The ACK message is used by an endpoint to indicate handshake- 1501 containing the TLS records it has received from the other side. ACK 1502 is not a handshake message but is rather a separate content type, 1503 with code point TBD (proposed, 25). This avoids it consuming space 1504 in the handshake message sequence. Note that ACKs can still be 1505 piggybacked on the same UDP datagram as handshake records. 1507 struct { 1508 uint64 record_numbers<0..2^16-1>; 1509 } ACK; 1511 record_numbers: a list of the records containing handshake messages 1512 in the current flight which the endpoint has received, in 1513 numerically increasing order. ACKs only cover the current 1514 outstanding flight (this is possible because DTLS is generally a 1515 lockstep protocol). Thus, an ACK from the server would not cover 1516 both the ClientHello and the client's Certificate. 1517 Implementations can accomplish this by clearing their ACK list 1518 upon receiving the start of the next flight. 1520 ACK records MUST be sent with an epoch that is equal to or higher 1521 than the record which is being acknowledged. Implementations SHOULD 1522 simply use the current key. 1524 7.1. Sending ACKs 1526 When an implementation receives a partial flight, it SHOULD generate 1527 an ACK that covers the messages from that flight which it has 1528 received so far. Implementations have some discretion about when to 1529 generate ACKs, but it is RECOMMENDED that they do so under two 1530 circumstances: 1532 - When they receive a message or fragment which is out of order, 1533 either because it is not the next expected message or because it 1534 is not the next piece of the current message. Implementations 1535 MUST NOT send ACKs for handshake messages which they discard as 1536 out-of-order, because otherwise those messages will not be 1537 retransmitted. 1539 - When they have received part of a flight and do not immediately 1540 receive the rest of the flight (which may be in the same UDP 1541 datagram). A reasonable approach here is to set a timer for 1/4 1542 the current retransmit timer value when the first record in the 1543 flight is received and then send an ACK when that timer expires. 1545 In addition, implementations MUST send ACKs upon receiving all of any 1546 flight which they do not respond to with their own messages. 1547 Specifically, this means the client's final flight of the main 1548 handshake, the server's transmission of the NewSessionTicket, and 1549 KeyUpdate messages. ACKs SHOULD NOT be sent for other complete 1550 flights because they are implicitly acknowledged by the receipt of 1551 the next flight, which generally immediately follows the flight. 1552 Each NewSessionTicket or KeyUpdate is an individual flight; in 1553 particular, a KeyUpdate sent in response to a KeyUpdate with 1554 update_requested does not implicitly acknowledge that message. 1555 Implementations MAY ACK the records corresponding to each 1556 transmission of that flight or simply ACK the most recent one. 1558 ACKs MUST NOT be sent for other records of any content type other 1559 than handshake or for records which cannot be unprotected. 1561 Note that in some cases it may be necessary to send an ACK which does 1562 not contain any record numbers. For instance, a client might receive 1563 an EncryptedExtensions message prior to receiving a ServerHello. 1564 Because it cannot decrypt the EncryptedExtensions, it cannot safely 1565 ACK it (as it might be damaged). If the client does not send an ACK, 1566 the server will eventually retransmit its first flight, but this 1567 might take far longer than the actual round trip time between client 1568 and server. Having the client send an empty ACK shortcuts this 1569 process. 1571 7.2. Receiving ACKs 1573 When an implementation receives an ACK, it SHOULD record that the 1574 messages or message fragments sent in the records being ACKed were 1575 received and omit them from any future retransmissions. Upon receipt 1576 of an ACK for only some messages from a flight, an implementation 1577 SHOULD retransmit the remaining messages or fragments. Note that 1578 this requires implementations to track which messages appear in which 1579 records. Once all the messages in a flight have been acknowledged, 1580 the implementation MUST cancel all retransmissions of that flight. 1581 As noted above, the receipt of any packet responding to a given 1582 flight MUST be taken as an implicit ACK for the entire flight. 1584 8. Key Updates 1586 As with TLS 1.3, DTLS 1.3 implementations send a KeyUpdate message to 1587 indicate that they are updating their sending keys. As with other 1588 handshake messages with no built-in response, KeyUpdates MUST be 1589 acknowledged. In order to facilitate epoch reconstruction 1590 Section 4.2.2 implementations MUST NOT send with the new keys or send 1591 a new KeyUpdate until the previous KeyUpdate has been acknowledged 1592 (this avoids having too many epochs in active use). 1594 Due to loss and/or re-ordering, DTLS 1.3 implementations may receive 1595 a record with an older epoch than the current one (the requirements 1596 above preclude receiving a newer record). They SHOULD attempt to 1597 process those records with that epoch (see Section 4.2.2 for 1598 information on determining the correct epoch), but MAY opt to discard 1599 such out-of-epoch records. 1601 Although KeyUpdate MUST be ACKed, it is possible for the ACK to be 1602 lost, in which case the sender of the KeyUpdate will retransmit it. 1603 Implementations MUST retain the ability to ACK the KeyUpdate for up 1604 to 2MSL. It is RECOMMENDED that they do so by retaining the pre- 1605 update keying material, but they MAY do so by responding to messages 1606 which appear to be out-of-epoch with a canned ACK message; in this 1607 case, implementations SHOULD rate limit how often they send such 1608 ACKs. 1610 9. Connection ID Updates 1612 If the client and server have negotiated the "connection_id" 1613 extension [I-D.ietf-tls-dtls-connection-id], either side can send a 1614 new connection ID which it wishes the other side to use in a 1615 NewConnectionId message. 1617 enum { 1618 cid_immediate(0), cid_spare(1), (255) 1619 } ConnectionIdUsage; 1621 struct { 1622 opaque cid<0..2^8-1>; 1623 ConnectionIdUsage usage; 1624 } NewConnectionId; 1626 cid Indicates the CID which the sender wishes the peer to use. 1628 usage Indicates whether the new CID should be used immediately or is 1629 a spare. If usage is set to "cid_immediate", then the new CID 1630 MUST be used immediately for all future records. If it is set to 1631 "cid_spare", then either CID MAY be used. 1633 If the client and server have negotiated the "connection_id" 1634 extension, either side can request a new CID using the 1635 RequestConnectionId message. 1637 struct { 1638 } RequestConnectionId; 1640 Endpoints SHOULD respond to RequestConnectionId by sending a 1641 NewConnectionId with usage "cid_spare" as soon as possible. Note 1642 that an endpoint MAY ignore requests, which it considers excessive 1643 (though they MUST be ACKed as usual). 1645 Endpoints MUST NOT send either of these messages if they did not 1646 negotiate a connection ID. If an implementation receives these 1647 messages when connection IDs were not negotiated, it MUST abort the 1648 connection with an unexpected_message alert. 1650 9.1. ID Example 1652 Below is an example exchange for DTLS 1.3 using a single connection 1653 id in each direction. 1655 Note: The connection_id extension is defined in 1656 [I-D.ietf-tls-dtls-connection-id], which is used in ClientHello and 1657 ServerHello messages. 1659 Client Server 1660 ------ ------ 1662 ClientHello 1663 (connection_id=5) 1664 --------> 1666 <-------- HelloRetryRequest 1667 (cookie) 1669 ClientHello --------> 1670 (connection_id=5) 1671 +cookie 1673 <-------- ServerHello 1674 (connection_id=100) 1675 EncryptedExtensions 1676 (cid=5) 1677 Certificate 1678 (cid=5) 1679 CertificateVerify 1680 (cid=5) 1681 Finished 1682 (cid=5) 1684 Certificate --------> 1685 (cid=100) 1686 CertificateVerify 1687 (cid=100) 1688 Finished 1689 (cid=100) 1690 <-------- Ack 1691 (cid=5) 1693 Application Data ========> 1694 (cid=100) 1695 <======== Application Data 1696 (cid=5) 1698 Figure 13: Example DTLS 1.3 Exchange with Connection IDs 1700 10. Application Data Protocol 1702 Application data messages are carried by the record layer and are 1703 fragmented and encrypted based on the current connection state. The 1704 messages are treated as transparent data to the record layer. 1706 11. Security Considerations 1708 Security issues are discussed primarily in [I-D.ietf-tls-tls13]. 1710 The primary additional security consideration raised by DTLS is that 1711 of denial of service. DTLS includes a cookie exchange designed to 1712 protect against denial of service. However, implementations that do 1713 not use this cookie exchange are still vulnerable to DoS. In 1714 particular, DTLS servers that do not use the cookie exchange may be 1715 used as attack amplifiers even if they themselves are not 1716 experiencing DoS. Therefore, DTLS servers SHOULD use the cookie 1717 exchange unless there is good reason to believe that amplification is 1718 not a threat in their environment. Clients MUST be prepared to do a 1719 cookie exchange with every handshake. 1721 Unlike TLS implementations, DTLS implementations SHOULD NOT respond 1722 to invalid records by terminating the connection. 1724 If implementations process out-of-epoch records as recommended in 1725 Section 8, then this creates a denial of service risk since an 1726 adversary could inject packets with fake epoch values, forcing the 1727 recipient to compute the next-generation application_traffic_secret 1728 using the HKDF-Expand-Label construct to only find out that the 1729 message was does not pass the AEAD cipher processing. The impact of 1730 this attack is small since the HKDF-Expand-Label only performs 1731 symmetric key hashing operations. Implementations which are 1732 concerned about this form of attack can discard out-of-epoch records. 1734 The security and privacy properties of the connection ID for DTLS 1.3 1735 builds on top of what is described in 1736 [I-D.ietf-tls-dtls-connection-id]. There are, however, several 1737 improvements: 1739 - The use of the Post-Handshake message allows the client and the 1740 server to update their connection IDs and those values are 1741 exchanged with confidentiality protection. 1743 - With multi-homing, an adversary is able to correlate the 1744 communication interaction over the two paths, which adds further 1745 privacy concerns. In order to prevent this, implementations 1746 SHOULD attempt to use fresh connection IDs whenever they change 1747 local addresses or ports (though this is not always possible to 1748 detect). The RequestConnectionId message can be used to ask for 1749 new IDs in order to ensure that you have a pool of suitable IDs. 1751 - Switching connection ID based on certain events, or even 1752 regularly, helps against tracking by onpath adversaries but the 1753 sequence numbers can still allow linkability. [[OPEN ISSUE: We 1754 need to update the document to offer sequence number encryption. 1755 ]] 1757 - Since the DTLS 1.3 exchange encrypts handshake messages much 1758 earlier than in previous DTLS versions information identifying the 1759 DTLS client, such as the client certificate, less information is 1760 available to an on-path adversary. 1762 12. Changes to DTLS 1.2 1764 Since TLS 1.3 introduces a large number of changes to TLS 1.2, the 1765 list of changes from DTLS 1.2 to DTLS 1.3 is equally large. For this 1766 reason this section focuses on the most important changes only. 1768 - New handshake pattern, which leads to a shorter message exchange 1770 - Support for AEAD-only ciphers 1772 - HelloRetryRequest of TLS 1.3 used instead of HelloVerifyRequest 1774 - More flexible ciphersuite negotiation 1776 - New session resumption mechanism 1778 - PSK authentication redefined 1780 - New key derivation hierarchy utilizing a new key derivation 1781 construct 1783 - Removed support for weaker and older cryptographic algorithms 1785 - Improved version negotation 1787 - Optimized record layer encoding and thereby its size 1789 - Added connection ID functionality 1791 13. IANA Considerations 1793 IANA is requested to allocate a new value in the "TLS ContentType" 1794 registry for the ACK message, defined in Section 7, with content type 1795 25. 1797 IANA is requested to allocate two values in the "TLS Handshake Type" 1798 registry, defined in [RFC5246], for RequestConnectionId (TBD), and 1799 NewConnectionId (TBD), as defined in this document. 1801 14. References 1803 14.1. Normative References 1805 [I-D.ietf-tls-tls13] 1806 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1807 Version 1.3", draft-ietf-tls-tls13-21 (work in progress), 1808 July 2017. 1810 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1811 DOI 10.17487/RFC0768, August 1980, 1812 . 1814 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1815 RFC 793, DOI 10.17487/RFC0793, September 1981, 1816 . 1818 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1819 DOI 10.17487/RFC1191, November 1990, 1820 . 1822 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1823 Requirement Levels", BCP 14, RFC 2119, 1824 DOI 10.17487/RFC2119, March 1997, 1825 . 1827 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1828 Control Message Protocol (ICMPv6) for the Internet 1829 Protocol Version 6 (IPv6) Specification", STD 89, 1830 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1831 . 1833 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1834 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1835 . 1837 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 1838 "Computing TCP's Retransmission Timer", RFC 6298, 1839 DOI 10.17487/RFC6298, June 2011, 1840 . 1842 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1843 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1844 May 2017, . 1846 14.2. Informative References 1848 [I-D.ietf-tls-dtls-connection-id] 1849 Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom, 1850 "The Datagram Transport Layer Security (DTLS) Connection 1851 Identifier", draft-ietf-tls-dtls-connection-id-00 (work in 1852 progress), December 2017. 1854 [I-D.rescorla-tls-dtls-connection-id] 1855 Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom, 1856 "The Datagram Transport Layer Security (DTLS) Connection 1857 Identifier", draft-rescorla-tls-dtls-connection-id-02 1858 (work in progress), November 2017. 1860 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 1861 Protocol", RFC 2522, DOI 10.17487/RFC2522, March 1999, 1862 . 1864 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1865 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1866 . 1868 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1869 Congestion Control Protocol (DCCP)", RFC 4340, 1870 DOI 10.17487/RFC4340, March 2006, 1871 . 1873 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1874 (TLS) Protocol Version 1.1", RFC 4346, 1875 DOI 10.17487/RFC4346, April 2006, 1876 . 1878 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1879 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 1880 . 1882 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1883 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1884 . 1886 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 1887 the Datagram Congestion Control Protocol (DCCP)", 1888 RFC 5238, DOI 10.17487/RFC5238, May 2008, 1889 . 1891 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1892 (TLS) Protocol Version 1.2", RFC 5246, 1893 DOI 10.17487/RFC5246, August 2008, 1894 . 1896 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1897 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1898 January 2012, . 1900 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1901 Kivinen, "Internet Key Exchange Protocol Version 2 1902 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1903 2014, . 1905 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1906 "Recommendations for Secure Use of Transport Layer 1907 Security (TLS) and Datagram Transport Layer Security 1908 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1909 2015, . 1911 14.3. URIs 1913 [1] mailto:tls@ietf.org 1915 [2] https://www1.ietf.org/mailman/listinfo/tls 1917 [3] https://www.ietf.org/mail-archive/web/tls/current/index.html 1919 Appendix A. History 1921 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 1923 IETF Drafts draft-27: - Incorporated unified header format. - Added 1924 support for connection IDs. 1926 draft-04 - 26: - Submissions to align with TLS 1.3 draft versions 1928 draft-03 - Only update keys after KeyUpdate is ACKed. 1930 draft-02 - Shorten the protected record header and introduce an 1931 ultra-short version of the record header. - Reintroduce KeyUpdate, 1932 which works properly now that we have ACK. - Clarify the ACK rules. 1934 draft-01 - Restructured the ACK to contain a list of packets and also 1935 be a record rather than a handshake message. 1937 draft-00 - First IETF Draft 1939 Personal Drafts draft-01 - Alignment with version -19 of the TLS 1.3 1940 specification 1942 draft-00 1944 - Initial version using TLS 1.3 as a baseline. 1946 - Use of epoch values instead of KeyUpdate message 1948 - Use of cookie extension instead of cookie field in ClientHello and 1949 HelloVerifyRequest messages 1951 - Added ACK message 1953 - Text about sequence number handling 1955 Appendix B. Working Group Information 1957 The discussion list for the IETF TLS working group is located at the 1958 e-mail address tls@ietf.org [1]. Information on the group and 1959 information on how to subscribe to the list is at 1960 https://www1.ietf.org/mailman/listinfo/tls [2] 1962 Archives of the list can be found at: https://www.ietf.org/mail- 1963 archive/web/tls/current/index.html [3] 1965 Appendix C. Contributors 1967 Many people have contributed to previous DTLS versions and they are 1968 acknowledged in prior versions of DTLS specifications or in the 1969 referenced specifications. 1971 In addition, we would like to thank: 1973 * Ilari Liusvaara 1974 Independent 1975 ilariliusvaara@welho.com 1977 * Martin Thomson 1978 Mozilla 1979 martin.thomson@gmail.com 1981 * Yin Xinxing 1982 Huawei 1983 yinxinxing@huawei.com 1985 * Thomas Fossati 1986 Nokia 1987 thomas.fossati@nokia.com 1989 * Tobias Gondrom 1990 Huawei 1991 tobias.gondrom@gondrom.org 1993 Authors' Addresses 1995 Eric Rescorla 1996 RTFM, Inc. 1998 EMail: ekr@rtfm.com 2000 Hannes Tschofenig 2001 Arm Limited 2003 EMail: hannes.tschofenig@arm.com 2005 Nagendra Modadugu 2006 Google, Inc. 2008 EMail: nagendra@cs.stanford.edu