idnits 2.17.1 draft-ietf-tls-dtls13-43.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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. 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 (30 April 2021) is 1091 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 2785 -- Looks like a reference, but probably isn't: '2' on line 2787 == Missing Reference: 'ACK' is mentioned on line 1937, but not defined == Missing Reference: 'NewSessionTicket' is mentioned on line 1934, but not defined == Missing Reference: 'KeyUpdate' is mentioned on line 2177, but not defined == Missing Reference: 'Ack' is mentioned on line 2180, but not defined ** Downref: Normative reference to an Informational RFC: RFC 8439 (ref. 'CHACHA') == Outdated reference: A later version (-13) exists of draft-ietf-tls-dtls-connection-id-11 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-10 == Outdated reference: A later version (-09) exists of draft-ietf-uta-tls13-iot-profile-01 -- 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: 3 errors (**), 0 flaws (~~), 10 warnings (==), 10 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: 1 November 2021 N. Modadugu 7 Google, Inc. 8 30 April 2021 10 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 11 draft-ietf-tls-dtls13-43 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 with the exception of order protection/non-replayability. 23 Datagram semantics of the underlying transport are preserved by the 24 DTLS protocol. 26 This document obsoletes RFC 6347. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 1 November 2021. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 75 3. DTLS Design Rationale and Overview . . . . . . . . . . . . . 6 76 3.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 7 77 3.2. Reordering . . . . . . . . . . . . . . . . . . . . . . . 8 78 3.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 8 79 3.4. Replay Detection . . . . . . . . . . . . . . . . . . . . 8 80 4. The DTLS Record Layer . . . . . . . . . . . . . . . . . . . . 8 81 4.1. Demultiplexing DTLS Records . . . . . . . . . . . . . . . 12 82 4.2. Sequence Number and Epoch . . . . . . . . . . . . . . . . 14 83 4.2.1. Processing Guidelines . . . . . . . . . . . . . . . . 14 84 4.2.2. Reconstructing the Sequence Number and Epoch . . . . 15 85 4.2.3. Record Number Encryption . . . . . . . . . . . . . . 15 86 4.3. Transport Layer Mapping . . . . . . . . . . . . . . . . . 16 87 4.4. PMTU Issues . . . . . . . . . . . . . . . . . . . . . . . 17 88 4.5. Record Payload Protection . . . . . . . . . . . . . . . . 19 89 4.5.1. Anti-Replay . . . . . . . . . . . . . . . . . . . . . 19 90 4.5.2. Handling Invalid Records . . . . . . . . . . . . . . 20 91 4.5.3. AEAD Limits . . . . . . . . . . . . . . . . . . . . . 20 92 5. The DTLS Handshake Protocol . . . . . . . . . . . . . . . . . 22 93 5.1. Denial-of-Service Countermeasures . . . . . . . . . . . . 22 94 5.2. DTLS Handshake Message Format . . . . . . . . . . . . . . 25 95 5.3. ClientHello Message . . . . . . . . . . . . . . . . . . . 27 96 5.4. ServerHello Message . . . . . . . . . . . . . . . . . . . 28 97 5.5. Handshake Message Fragmentation and Reassembly . . . . . 28 98 5.6. End Of Early Data . . . . . . . . . . . . . . . . . . . . 29 99 5.7. DTLS Handshake Flights . . . . . . . . . . . . . . . . . 30 100 5.8. Timeout and Retransmission . . . . . . . . . . . . . . . 34 101 5.8.1. State Machine . . . . . . . . . . . . . . . . . . . . 34 102 5.8.2. Timer Values . . . . . . . . . . . . . . . . . . . . 37 103 5.8.3. Large Flight Sizes . . . . . . . . . . . . . . . . . 38 104 5.8.4. State machine duplication for post-handshake 105 messages . . . . . . . . . . . . . . . . . . . . . . 38 106 5.9. CertificateVerify and Finished Messages . . . . . . . . . 40 107 5.10. Cryptographic Label Prefix . . . . . . . . . . . . . . . 40 108 5.11. Alert Messages . . . . . . . . . . . . . . . . . . . . . 40 109 5.12. Establishing New Associations with Existing Parameters . 40 110 6. Example of Handshake with Timeout and Retransmission . . . . 41 111 6.1. Epoch Values and Rekeying . . . . . . . . . . . . . . . . 42 112 7. ACK Message . . . . . . . . . . . . . . . . . . . . . . . . . 45 113 7.1. Sending ACKs . . . . . . . . . . . . . . . . . . . . . . 46 114 7.2. Receiving ACKs . . . . . . . . . . . . . . . . . . . . . 47 115 7.3. Design Rationale . . . . . . . . . . . . . . . . . . . . 48 116 8. Key Updates . . . . . . . . . . . . . . . . . . . . . . . . . 48 117 9. Connection ID Updates . . . . . . . . . . . . . . . . . . . . 50 118 9.1. Connection ID Example . . . . . . . . . . . . . . . . . . 51 119 10. Application Data Protocol . . . . . . . . . . . . . . . . . . 53 120 11. Security Considerations . . . . . . . . . . . . . . . . . . . 53 121 12. Changes since DTLS 1.2 . . . . . . . . . . . . . . . . . . . 55 122 13. Updates affecting DTLS 1.2 . . . . . . . . . . . . . . . . . 56 123 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 124 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 125 15.1. Normative References . . . . . . . . . . . . . . . . . . 57 126 15.2. Informative References . . . . . . . . . . . . . . . . . 58 127 Appendix A. Protocol Data Structures and Constant Values . . . . 61 128 A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 61 129 A.2. Handshake Protocol . . . . . . . . . . . . . . . . . . . 62 130 A.3. ACKs . . . . . . . . . . . . . . . . . . . . . . . . . . 64 131 A.4. Connection ID Management . . . . . . . . . . . . . . . . 64 132 Appendix B. Analysis of Limits on CCM Usage . . . . . . . . . . 64 133 B.1. Confidentiality Limits . . . . . . . . . . . . . . . . . 65 134 B.2. Integrity Limits . . . . . . . . . . . . . . . . . . . . 66 135 B.3. Limits for AEAD_AES_128_CCM_8 . . . . . . . . . . . . . . 66 136 Appendix C. Implementation Pitfalls . . . . . . . . . . . . . . 67 137 Appendix D. History . . . . . . . . . . . . . . . . . . . . . . 67 138 Appendix E. Working Group Information . . . . . . . . . . . . . 70 139 Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 70 140 Appendix G. Acknowledgements . . . . . . . . . . . . . . . . . . 71 141 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 71 143 1. Introduction 145 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH 147 The source for this draft is maintained in GitHub. Suggested changes 148 should be submitted as pull requests at https://github.com/tlswg/ 149 dtls13-spec. Instructions are on that page as well. Editorial 150 changes can be managed in GitHub, but any substantive change should 151 be discussed on the TLS mailing list. 153 The primary goal of the TLS protocol is to establish an 154 authenticated, confidentiality and integrity protected channel 155 between two communicating peers. The TLS protocol is composed of two 156 layers: the TLS Record Protocol and the TLS Handshake Protocol. 157 However, TLS must run over a reliable transport channel - typically 158 TCP [RFC0793]. 160 There are applications that use UDP [RFC0768] as a transport and to 161 offer communication security protection for those applications the 162 Datagram Transport Layer Security (DTLS) protocol has been developed. 163 DTLS is deliberately designed to be as similar to TLS as possible, 164 both to minimize new security invention and to maximize the amount of 165 code and infrastructure reuse. 167 DTLS 1.0 [RFC4347] was originally defined as a delta from TLS 1.1 168 [RFC4346] and DTLS 1.2 [RFC6347] was defined as a series of deltas to 169 TLS 1.2 [RFC5246]. There is no DTLS 1.1; that version number was 170 skipped in order to harmonize version numbers with TLS. This 171 specification describes the most current version of the DTLS protocol 172 as a delta from TLS 1.3 [TLS13]. It obsoletes DTLS 1.2. 174 Implementations that speak both DTLS 1.2 and DTLS 1.3 can 175 interoperate with those that speak only DTLS 1.2 (using DTLS 1.2 of 176 course), just as TLS 1.3 implementations can interoperate with TLS 177 1.2 (see Appendix D of [TLS13] for details). While backwards 178 compatibility with DTLS 1.0 is possible the use of DTLS 1.0 is not 179 recommended as explained in Section 3.1.2 of RFC 7525 [RFC7525] and 180 [DEPRECATE]. 182 2. Conventions and Terminology 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 186 "OPTIONAL" in this document are to be interpreted as described in BCP 187 14 [RFC2119] [RFC8174] when, and only when, they appear in all 188 capitals, as shown here. 190 The following terms are used: 192 * client: The endpoint initiating the DTLS connection. 194 * association: Shared state between two endpoints established with a 195 DTLS handshake. 197 * connection: Synonym for association. 199 * endpoint: Either the client or server of the connection. 201 * epoch: one set of cryptographic keys used for encryption and 202 decryption. 204 * handshake: An initial negotiation between client and server that 205 establishes the parameters of the connection. 207 * peer: An endpoint. When discussing a particular endpoint, "peer" 208 refers to the endpoint that is remote to the primary subject of 209 discussion. 211 * receiver: An endpoint that is receiving records. 213 * sender: An endpoint that is transmitting records. 215 * server: The endpoint which did not initiate the DTLS connection. 217 * CID: Connection ID 219 * MSL: Maximum Segment Lifetime 221 The reader is assumed to be familiar with [TLS13]. As in TLS 1.3, 222 the HelloRetryRequest has the same format as a ServerHello message, 223 but for convenience we use the term HelloRetryRequest throughout this 224 document as if it were a distinct message. 226 DTLS 1.3 uses network byte order (big-endian) format for encoding 227 messages based on the encoding format defined in [TLS13] and earlier 228 (D)TLS specifications. 230 The reader is also assumed to be familiar with 231 [I-D.ietf-tls-dtls-connection-id] as this document applies the CID 232 functionality to DTLS 1.3. 234 Figures in this document illustrate various combinations of the DTLS 235 protocol exchanges and the symbols have the following meaning: 237 * '+' indicates noteworthy extensions sent in the previously noted 238 message. 240 * '*' indicates optional or situation-dependent messages/extensions 241 that are not always sent. 243 * '{}' indicates messages protected using keys derived from a 244 [sender]_handshake_traffic_secret. 246 * '[]' indicates messages protected using keys derived from 247 traffic_secret_N. 249 3. DTLS Design Rationale and Overview 251 The basic design philosophy of DTLS is to construct "TLS over 252 datagram transport". Datagram transport does not require nor provide 253 reliable or in-order delivery of data. The DTLS protocol preserves 254 this property for application data. Applications, such as media 255 streaming, Internet telephony, and online gaming use datagram 256 transport for communication due to the delay-sensitive nature of 257 transported data. The behavior of such applications is unchanged 258 when the DTLS protocol is used to secure communication, since the 259 DTLS protocol does not compensate for lost or reordered data traffic. 260 Note that while low-latency streaming and gaming use DTLS to protect 261 data (e.g. for protection of a WebRTC data channel), telephony 262 utilizes DTLS for key establishment, and Secure Real-time Transport 263 Protocol (SRTP) for protection of data [RFC5763]. 265 TLS cannot be used directly over datagram transports the following 266 five reasons: 268 1. TLS relies on an implicit sequence number on records. If a 269 record is not received, then the recipient will use the wrong 270 sequence number when attempting to remove record protection from 271 subsequent records. DTLS solves this problem by adding sequence 272 numbers to records. 274 2. The TLS handshake is a lock-step cryptographic protocol. 275 Messages must be transmitted and received in a defined order; any 276 other order is an error. The DTLS handshake includes message 277 sequence numbers to enable fragmented message reassembly and in- 278 order delivery in case datagrams are lost or reordered. 280 3. During the handshake, messages are implicitly acknowledged by 281 other handshake messages. Some handshake messages, such as the 282 NewSessionTicket message, do not result in any direct response 283 that would allow the sender to detect loss. DTLS adds an 284 acknowledgment message to enable better loss recovery. 286 4. Handshake messages are potentially larger than can be contained 287 in a single datagram. DTLS adds fields to handshake messages to 288 support fragmentation and reassembly. 290 5. Datagram transport protocols, like UDP, are susceptible to 291 abusive behavior effecting denial of service attacks against 292 nonparticipants. DTLS adds a return-routability check and DTLS 293 1.3 uses the TLS 1.3 HelloRetryRequest message (see Section 5.1 294 for details). 296 3.1. Packet Loss 298 DTLS uses a simple retransmission timer to handle packet loss. 299 Figure 1 demonstrates the basic concept, using the first phase of the 300 DTLS handshake: 302 Client Server 303 ------ ------ 304 ClientHello ------> 306 X<-- HelloRetryRequest 307 (lost) 309 [Timer Expires] 311 ClientHello ------> 312 (retransmit) 314 Figure 1: DTLS retransmission example 316 Once the client has transmitted the ClientHello message, it expects 317 to see a HelloRetryRequest or a ServerHello from the server. 318 However, if the timer expires, the client knows that either the 319 ClientHello or the response from the server has been lost, which 320 causes the the client to retransmit the ClientHello. When the server 321 receives the retransmission, it knows to retransmit its 322 HelloRetryRequest or ServerHello. 324 The server also maintains a retransmission timer for messages it 325 sends (other than HelloRetryRequest) and retransmits when that timer 326 expires. Not applying retransmissions to the HelloRetryRequest 327 avoids the need to create state on the server. The HelloRetryRequest 328 is designed to be small enough that it will not itself be fragmented, 329 thus avoiding concerns about interleaving multiple 330 HelloRetryRequests. 332 For more detail on timeouts and retransmission, see Section 5.8. 334 3.2. Reordering 336 In DTLS, each handshake message is assigned a specific sequence 337 number. When a peer receives a handshake message, it can quickly 338 determine whether that message is the next message it expects. If it 339 is, then it processes it. If not, it queues it for future handling 340 once all previous messages have been received. 342 3.3. Fragmentation 344 TLS and DTLS handshake messages can be quite large (in theory up to 345 2^24-1 bytes, in practice many kilobytes). By contrast, UDP 346 datagrams are often limited to less than 1500 bytes if IP 347 fragmentation is not desired. In order to compensate for this 348 limitation, each DTLS handshake message may be fragmented over 349 several DTLS records, each of which is intended to fit in a single 350 UDP datagram (see Section 4.4 for guidance). Each DTLS handshake 351 message contains both a fragment offset and a fragment length. Thus, 352 a recipient in possession of all bytes of a handshake message can 353 reassemble the original unfragmented message. 355 3.4. Replay Detection 357 DTLS optionally supports record replay detection. The technique used 358 is the same as in IPsec AH/ESP, by maintaining a bitmap window of 359 received records. Records that are too old to fit in the window and 360 records that have previously been received are silently discarded. 361 The replay detection feature is optional, since packet duplication is 362 not always malicious, but can also occur due to routing errors. 363 Applications may conceivably detect duplicate packets and accordingly 364 modify their data transmission strategy. 366 4. The DTLS Record Layer 368 The DTLS 1.3 record layer is different from the TLS 1.3 record layer 369 and also different from the DTLS 1.2 record layer. 371 1. The DTLSCiphertext structure omits the superfluous version number 372 and type fields. 374 2. DTLS adds an epoch and sequence number to the TLS record header. 375 This sequence number allows the recipient to correctly verify the 376 DTLS MAC. However, the number of bits used for the epoch and 377 sequence number fields in the DTLSCiphertext structure have been 378 reduced from those in previous versions. 380 3. The DTLSCiphertext structure has a variable length header. 382 DTLSPlaintext records are used to send unprotected records and 383 DTLSCiphertext records are used to send protected records. 385 The DTLS record formats are shown below. Unless explicitly stated 386 the meaning of the fields is unchanged from previous TLS / DTLS 387 versions. 389 struct { 390 ContentType type; 391 ProtocolVersion legacy_record_version; 392 uint16 epoch = 0 393 uint48 sequence_number; 394 uint16 length; 395 opaque fragment[DTLSPlaintext.length]; 396 } DTLSPlaintext; 398 struct { 399 opaque content[DTLSPlaintext.length]; 400 ContentType type; 401 uint8 zeros[length_of_padding]; 402 } DTLSInnerPlaintext; 404 struct { 405 opaque unified_hdr[variable]; 406 opaque encrypted_record[length]; 407 } DTLSCiphertext; 409 Figure 2: DTLS 1.3 Record Formats 411 legacy_record_version This value MUST be set to {254, 253} for all 412 records other than the initial ClientHello (i.e., one not 413 generated after a HelloRetryRequest), where it may also be {254, 414 255} for compatibility purposes. It MUST be ignored for all 415 purposes. See [TLS13]; Appendix D.1 for the rationale for this. 417 unified_hdr: The unified header (unified_hdr) is a structure of 418 variable length, as shown in Figure 3. 420 encrypted_record: The AEAD-encrypted form of the serialized 421 DTLSInnerPlaintext structure. 423 0 1 2 3 4 5 6 7 424 +-+-+-+-+-+-+-+-+ 425 |0|0|1|C|S|L|E E| 426 +-+-+-+-+-+-+-+-+ 427 | Connection ID | Legend: 428 | (if any, | 429 / length as / C - Connection ID (CID) present 430 | negotiated) | S - Sequence number length 431 +-+-+-+-+-+-+-+-+ L - Length present 432 | 8 or 16 bit | E - Epoch 433 |Sequence Number| 434 +-+-+-+-+-+-+-+-+ 435 | 16 bit Length | 436 | (if present) | 437 +-+-+-+-+-+-+-+-+ 439 Figure 3: DTLS 1.3 Unified Header 441 Fixed Bits: The three high bits of the first byte of the unified 442 header are set to 001. This ensures that the value will fit 443 within the DTLS region when multiplexing is performed as described 444 in [RFC7983]. It also ensures that distinguishing encrypted DTLS 445 1.3 records from encrypted DTLS 1.2 records is possible when they 446 are carried on the same host/port quartet; such multiplexing is 447 only possible when CIDs [I-D.ietf-tls-dtls-connection-id] are in 448 use, in which case DTLS 1.2 records will have the content type 449 tls12_cid (25). 451 C: The C bit (0x10) is set if the Connection ID is present. 453 S: The S bit (0x08) indicates the size of the sequence number. 0 454 means an 8-bit sequence number, 1 means 16-bit. Implementations 455 MAY mix sequence numbers of different lengths on the same 456 connection. 458 L: The L bit (0x04) is set if the length is present. 460 E: The two low bits (0x03) include the low order two bits of the 461 epoch. 463 Connection ID: Variable length CID. The CID functionality is 464 described in [I-D.ietf-tls-dtls-connection-id]. An example can be 465 found in Section 9.1. 467 Sequence Number: The low order 8 or 16 bits of the record sequence 468 number. This value is 16 bits if the S bit is set to 1, and 8 469 bits if the S bit is 0. 471 Length: Identical to the length field in a TLS 1.3 record. 473 As with previous versions of DTLS, multiple DTLSPlaintext and 474 DTLSCiphertext records can be included in the same underlying 475 transport datagram. 477 Figure 4 illustrates different record headers. 479 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 480 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 481 | Content Type | |0|0|1|1|1|1|E E| |0|0|1|0|0|0|E E| 482 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 483 | 16 bit | | | |8-bit Seq. No. | 484 | Version | / Connection ID / +-+-+-+-+-+-+-+-+ 485 +-+-+-+-+-+-+-+-+ | | | | 486 | 16 bit | +-+-+-+-+-+-+-+-+ | Encrypted | 487 | Epoch | | 16 bit | / Record / 488 +-+-+-+-+-+-+-+-+ |Sequence Number| | | 489 | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 490 | | | 16 bit | 491 | 48 bit | | Length | DTLSCiphertext 492 |Sequence Number| +-+-+-+-+-+-+-+-+ Structure 493 | | | | (minimal) 494 | | | Encrypted | 495 +-+-+-+-+-+-+-+-+ / Record / 496 | 16 bit | | | 497 | Length | +-+-+-+-+-+-+-+-+ 498 +-+-+-+-+-+-+-+-+ 499 | | DTLSCiphertext 500 | | Structure 501 / Fragment / (full) 502 | | 503 +-+-+-+-+-+-+-+-+ 505 DTLSPlaintext 506 Structure 508 Figure 4: DTLS 1.3 Header Examples 510 The length field MAY be omitted by clearing the L bit, which means 511 that the record consumes the entire rest of the datagram in the lower 512 level transport. In this case it is not possible to have multiple 513 DTLSCiphertext format records without length fields in the same 514 datagram. Omitting the length field MUST only be used for the last 515 record in a datagram. Implementations MAY mix records with and 516 without length fields on the same connection. 518 If a Connection ID is negotiated, then it MUST be contained in all 519 datagrams. Sending implementations MUST NOT mix records from 520 multiple DTLS associations in the same datagram. If the second or 521 later record has a connection ID which does not correspond to the 522 same association used for previous records, the rest of the datagram 523 MUST be discarded. 525 When expanded, the epoch and sequence number can be combined into an 526 unpacked RecordNumber structure, as shown below: 528 struct { 529 uint16 epoch; 530 uint48 sequence_number; 531 } RecordNumber; 533 This 64-bit value is used in the ACK message as well as in the 534 "record_sequence_number" input to the AEAD function. 536 The entire header value shown in Figure 4 (but prior to record number 537 encryption, see Section 4.2.3) is used as as the additional data 538 value for the AEAD function. For instance, if the minimal variant is 539 used, the AAD is 2 octets long. Note that this design is different 540 from the additional data calculation for DTLS 1.2 and for DTLS 1.2 541 with Connection ID. 543 4.1. Demultiplexing DTLS Records 545 DTLS 1.3 uses a variable length record format and hence the 546 demultiplexing process is more complex since more header formats need 547 to be distinguished. Implementations can demultiplex DTLS 1.3 548 records by examining the first byte as follows: 550 * If the first byte is alert(21), handshake(22), or ack(proposed, 551 26), the record MUST be interpreted as a DTLSPlaintext record. 553 * If the first byte is any other value, then receivers MUST check to 554 see if the leading bits of the first byte are 001. If so, the 555 implementation MUST process the record as DTLSCiphertext; the true 556 content type will be inside the protected portion. 558 * Otherwise, the record MUST be rejected as if it had failed 559 deprotection, as described in Section 4.5.2. 561 Figure 5 shows this demultiplexing procedure graphically taking DTLS 562 1.3 and earlier versions of DTLS into account. 564 +----------------+ 565 | Outer Content | 566 | Type (OCT) | 567 | | 568 | OCT == 20 -+--> ChangeCipherSpec (DTLS <1.3) 569 | OCT == 21 -+--> Alert (Plaintext) 570 | OCT == 22 -+--> Handshake (Plaintext) 571 | OCT == 23 -+--> Application Data (DTLS <1.3) 572 | OCT == 24 -+--> Heartbeat (DTLS <1.3) 573 packet --> | OCT == 25 -+--> DTLSCipherText with CID (DTLS 1.2) 574 | OCT == 26 -+--> ACK (DTLS 1.3, Plaintext) 575 | | 576 | | /+----------------+\ 577 | 31 < OCT < 64 -+--> |DTLS Ciphertext | 578 | | |(header bits | 579 | else | | start with 001)| 580 | | | /+-------+--------+\ 581 +-------+--------+ | 582 | | 583 v Decryption | 584 +---------+ +------+ 585 | Reject | | 586 +---------+ v 587 +----------------+ 588 | Decrypted | 589 | Content Type | 590 | (DCT) | 591 | | 592 | DCT == 21 -+--> Alert 593 | DCT == 22 -+--> Handshake 594 | DCT == 23 -+--> Application Data 595 | DCT == 24 -+--> Heartbeat 596 | DCT == 26 -+--> ACK 597 | | 598 +----------------+ 600 Figure 5: Demultiplexing DTLS 1.2 and DTLS 1.3 Records 602 Note: The optimized DTLS header format shown in Figure 3, which does 603 not carry the Content Type in the Unified Header format, requires a 604 different demultilexing strategy compared to what was used in 605 previous DTLS versions where the Content Type was conveyed in every 606 record. As described in Figure 5, the first byte determines how an 607 incoming DTLS record is demultiplexed. The first 3 bits of the first 608 byte distinguish a DTLS 1.3 encrypted record from record types used 609 in previous DTLS versions and plaintext DTLS 1.3 record types. 610 Hence, the range 32 (0b0010 0000) to 63 (0b0011 1111) needs to be 611 excluded from future allocations by IANA to avoid problems while 612 demultiplexing; see Section 14. 614 4.2. Sequence Number and Epoch 616 DTLS uses an explicit or partly explicit sequence number, rather than 617 an implicit one, carried in the sequence_number field of the record. 618 Sequence numbers are maintained separately for each epoch, with each 619 sequence_number initially being 0 for each epoch. 621 The epoch number is initially zero and is incremented each time 622 keying material changes and a sender aims to rekey. More details are 623 provided in Section 6.1. 625 4.2.1. Processing Guidelines 627 Because DTLS records could be reordered, a record from epoch M may be 628 received after epoch N (where N > M) has begun. Implementations 629 SHOULD discard records from earlier epochs, but MAY choose to retain 630 keying material from previous epochs for up to the default MSL 631 specified for TCP [RFC0793] to allow for packet reordering. (Note 632 that the intention here is that implementers use the current guidance 633 from the IETF for MSL, as specified in [RFC0793] or successors, not 634 that they attempt to interrogate the MSL that the system TCP stack is 635 using.) 637 Conversely, it is possible for records that are protected with the 638 new epoch to be received prior to the completion of a handshake. For 639 instance, the server may send its Finished message and then start 640 transmitting data. Implementations MAY either buffer or discard such 641 records, though when DTLS is used over reliable transports (e.g., 642 SCTP [RFC4960]), they SHOULD be buffered and processed once the 643 handshake completes. Note that TLS's restrictions on when records 644 may be sent still apply, and the receiver treats the records as if 645 they were sent in the right order. 647 Implementations MUST send retransmissions of lost messages using the 648 same epoch and keying material as the original transmission. 650 Implementations MUST either abandon an association or re-key prior to 651 allowing the sequence number to wrap. 653 Implementations MUST NOT allow the epoch to wrap, but instead MUST 654 establish a new association, terminating the old association. 656 4.2.2. Reconstructing the Sequence Number and Epoch 658 When receiving protected DTLS records, the recipient does not have a 659 full epoch or sequence number value in the record and so there is 660 some opportunity for ambiguity. Because the full epoch and sequence 661 number are used to compute the per-record nonce, failure to 662 reconstruct these values leads to failure to deprotect the record, 663 and so implementations MAY use a mechanism of their choice to 664 determine the full values. This section provides an algorithm which 665 is comparatively simple and which implementations are RECOMMENDED to 666 follow. 668 If the epoch bits match those of the current epoch, then 669 implementations SHOULD reconstruct the sequence number by computing 670 the full sequence number which is numerically closest to one plus the 671 sequence number of the highest successfully deprotected record in the 672 current epoch. 674 During the handshake phase, the epoch bits unambiguously indicate the 675 correct key to use. After the handshake is complete, if the epoch 676 bits do not match those from the current epoch implementations SHOULD 677 use the most recent past epoch which has matching bits, and then 678 reconstruct the sequence number for that epoch as described above. 680 4.2.3. Record Number Encryption 682 In DTLS 1.3, when records are encrypted, record sequence numbers are 683 also encrypted. The basic pattern is that the underlying encryption 684 algorithm used with the AEAD algorithm is used to generate a mask 685 which is then XORed with the sequence number. 687 When the AEAD is based on AES, then the Mask is generated by 688 computing AES-ECB on the first 16 bytes of the ciphertext: 690 Mask = AES-ECB(sn_key, Ciphertext[0..15]) 692 When the AEAD is based on ChaCha20, then the mask is generated by 693 treating the first 4 bytes of the ciphertext as the block counter and 694 the next 12 bytes as the nonce, passing them to the ChaCha20 block 695 function (Section 2.3 of [CHACHA]): 697 Mask = ChaCha20(sn_key, Ciphertext[0..3], Ciphertext[4..15]) 699 The sn_key is computed as follows: 701 [sender]_sn_key = HKDF-Expand-Label(Secret, "sn" , "", key_length) 703 [sender] denotes the sending side. The Secret value to be used is 704 described in Section 7.3 of [TLS13]. Note that a new key is used for 705 each epoch: because the epoch is sent in the clear, this does not 706 result in ambiguity. 708 The encrypted sequence number is computed by XORing the leading bytes 709 of the Mask with the on-the-wire representation of the sequence 710 number. Decryption is accomplished by the same process. 712 This procedure requires the ciphertext length be at least 16 bytes. 713 Receivers MUST reject shorter records as if they had failed 714 deprotection, as described in Section 4.5.2. Senders MUST pad short 715 plaintexts out (using the conventional record padding mechanism) in 716 order to make a suitable-length ciphertext. Note most of the DTLS 717 AEAD algorithms have a 16-byte authentication tag and need no 718 padding. However, some algorithms such as TLS_AES_128_CCM_8_SHA256 719 have a shorter authentication tag and may require padding for short 720 inputs. 722 Future cipher suites, which are not based on AES or ChaCha20, MUST 723 define their own record sequence number encryption in order to be 724 used with DTLS. 726 Note that sequence number encryption is only applied to the 727 DTLSCiphertext structure and not to the DTLSPlaintext structure, 728 which also contains a sequence number. 730 4.3. Transport Layer Mapping 732 DTLS messages MAY be fragmented into multiple DTLS records. Each 733 DTLS record MUST fit within a single datagram. In order to avoid IP 734 fragmentation, clients of the DTLS record layer SHOULD attempt to 735 size records so that they fit within any Path MTU (PMTU) estimates 736 obtained from the record layer. For more information about PMTU 737 issues see Section 4.4. 739 Multiple DTLS records MAY be placed in a single datagram. Records 740 are encoded consecutively. The length field from DTLS records 741 containing that field can be used to determine the boundaries between 742 records. The final record in a datagram can omit the length field. 743 The first byte of the datagram payload MUST be the beginning of a 744 record. Records MUST NOT span datagrams. 746 DTLS records without CIDs do not contain any association identifiers 747 and applications must arrange to multiplex between associations. 748 With UDP, the host/port number is used to look up the appropriate 749 security association for incoming records without CIDs. 751 Some transports, such as DCCP [RFC4340], provide their own sequence 752 numbers. When carried over those transports, both the DTLS and the 753 transport sequence numbers will be present. Although this introduces 754 a small amount of inefficiency, the transport layer and DTLS sequence 755 numbers serve different purposes; therefore, for conceptual 756 simplicity, it is superior to use both sequence numbers. 758 Some transports provide congestion control for traffic carried over 759 them. If the congestion window is sufficiently narrow, DTLS 760 handshake retransmissions may be held rather than transmitted 761 immediately, potentially leading to timeouts and spurious 762 retransmission. When DTLS is used over such transports, care should 763 be taken not to overrun the likely congestion window. [RFC5238] 764 defines a mapping of DTLS to DCCP that takes these issues into 765 account. 767 4.4. PMTU Issues 769 In general, DTLS's philosophy is to leave PMTU discovery to the 770 application. However, DTLS cannot completely ignore PMTU for three 771 reasons: 773 * The DTLS record framing expands the datagram size, thus lowering 774 the effective PMTU from the application's perspective. 776 * In some implementations, the application may not directly talk to 777 the network, in which case the DTLS stack may absorb ICMP 778 [RFC1191] "Datagram Too Big" indications or ICMPv6 [RFC4443] 779 "Packet Too Big" indications. 781 * The DTLS handshake messages can exceed the PMTU. 783 In order to deal with the first two issues, the DTLS record layer 784 SHOULD behave as described below. 786 If PMTU estimates are available from the underlying transport 787 protocol, they should be made available to upper layer protocols. In 788 particular: 790 * For DTLS over UDP, the upper layer protocol SHOULD be allowed to 791 obtain the PMTU estimate maintained in the IP layer. 793 * For DTLS over DCCP, the upper layer protocol SHOULD be allowed to 794 obtain the current estimate of the PMTU. 796 * For DTLS over TCP or SCTP, which automatically fragment and 797 reassemble datagrams, there is no PMTU limitation. However, the 798 upper layer protocol MUST NOT write any record that exceeds the 799 maximum record size of 2^14 bytes. 801 The DTLS record layer SHOULD also allow the upper layer protocol to 802 discover the amount of record expansion expected by the DTLS 803 processing; alternately it MAY report PMTU estimates minus the 804 estimated expansion from the transport layer and DTLS record framing. 806 Note that DTLS does not defend against spoofed ICMP messages; 807 implementations SHOULD ignore any such messages that indicate PMTUs 808 below the IPv4 and IPv6 minimums of 576 and 1280 bytes respectively. 810 If there is a transport protocol indication that the PMTU was 811 exceeded (either via ICMP or via a refusal to send the datagram as in 812 Section 14 of [RFC4340]), then the DTLS record layer MUST inform the 813 upper layer protocol of the error. 815 The DTLS record layer SHOULD NOT interfere with upper layer protocols 816 performing PMTU discovery, whether via [RFC1191] and [RFC4821] for 817 IPv4 or via [RFC8201] for IPv6. In particular: 819 * Where allowed by the underlying transport protocol, the upper 820 layer protocol SHOULD be allowed to set the state of the DF bit 821 (in IPv4) or prohibit local fragmentation (in IPv6). 823 * If the underlying transport protocol allows the application to 824 request PMTU probing (e.g., DCCP), the DTLS record layer SHOULD 825 honor this request. 827 The final issue is the DTLS handshake protocol. From the perspective 828 of the DTLS record layer, this is merely another upper layer 829 protocol. However, DTLS handshakes occur infrequently and involve 830 only a few round trips; therefore, the handshake protocol PMTU 831 handling places a premium on rapid completion over accurate PMTU 832 discovery. In order to allow connections under these circumstances, 833 DTLS implementations SHOULD follow the following rules: 835 * If the DTLS record layer informs the DTLS handshake layer that a 836 message is too big, the handshake layer SHOULD immediately attempt 837 to fragment the message, using any existing information about the 838 PMTU. 840 * If repeated retransmissions do not result in a response, and the 841 PMTU is unknown, subsequent retransmissions SHOULD back off to a 842 smaller record size, fragmenting the handshake message as 843 appropriate. This specification does not specify an exact number 844 of retransmits to attempt before backing off, but 2-3 seems 845 appropriate. 847 4.5. Record Payload Protection 849 Like TLS, DTLS transmits data as a series of protected records. The 850 rest of this section describes the details of that format. 852 4.5.1. Anti-Replay 854 Each DTLS record contains a sequence number to provide replay 855 protection. Sequence number verification SHOULD be performed using 856 the following sliding window procedure, borrowed from Section 3.4.3 857 of [RFC4303]. Because each epoch resets the sequence number space, a 858 separate sliding window is needed for each epoch. 860 The received record counter for an epoch MUST be initialized to zero 861 when that epoch is first used. For each received record, the 862 receiver MUST verify that the record contains a sequence number that 863 does not duplicate the sequence number of any other record received 864 in that epoch during the lifetime of the association. This check 865 SHOULD happen after deprotecting the record; otherwise the record 866 discard might itself serve as a timing channel for the record number. 867 Note that computing the full record number from the partial is still 868 a potential timing channel for the record number, though a less 869 powerful one than whether the record was deprotected. 871 Duplicates are rejected through the use of a sliding receive window. 872 (How the window is implemented is a local matter, but the following 873 text describes the functionality that the implementation must 874 exhibit.) The receiver SHOULD pick a window large enough to handle 875 any plausible reordering, which depends on the data rate. (The 876 receiver does not notify the sender of the window size.) 878 The "right" edge of the window represents the highest validated 879 sequence number value received in the epoch. Records that contain 880 sequence numbers lower than the "left" edge of the window are 881 rejected. Records falling within the window are checked against a 882 list of received records within the window. An efficient means for 883 performing this check, based on the use of a bit mask, is described 884 in Section 3.4.3 of [RFC4303]. If the received record falls within 885 the window and is new, or if the record is to the right of the 886 window, then the record is new. 888 The window MUST NOT be updated until the record has been deprotected 889 successfully. 891 4.5.2. Handling Invalid Records 893 Unlike TLS, DTLS is resilient in the face of invalid records (e.g., 894 invalid formatting, length, MAC, etc.). In general, invalid records 895 SHOULD be silently discarded, thus preserving the association; 896 however, an error MAY be logged for diagnostic purposes. 897 Implementations which choose to generate an alert instead, MUST 898 generate fatal alerts to avoid attacks where the attacker repeatedly 899 probes the implementation to see how it responds to various types of 900 error. Note that if DTLS is run over UDP, then any implementation 901 which does this will be extremely susceptible to denial-of-service 902 (DoS) attacks because UDP forgery is so easy. Thus, generating fatal 903 alerts is NOT RECOMMENDED for such transports, both to increase the 904 reliability of DTLS service and to avoid the risk of spoofing attacks 905 sending traffic to unrelated third parties. 907 If DTLS is being carried over a transport that is resistant to 908 forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts 909 because an attacker will have difficulty forging a datagram that will 910 not be rejected by the transport layer. 912 Note that because invalid records are rejected at a layer lower than 913 the handshake state machine, they do not affect pending 914 retransmission timers. 916 4.5.3. AEAD Limits 918 Section 5.5 of TLS [TLS13] defines limits on the number of records 919 that can be protected using the same keys. These limits are specific 920 to an AEAD algorithm, and apply equally to DTLS. Implementations 921 SHOULD NOT protect more records than allowed by the limit specified 922 for the negotiated AEAD. Implementations SHOULD initiate a key 923 update before reaching this limit. 925 [TLS13] does not specify a limit for AEAD_AES_128_CCM, but the 926 analysis in Appendix B shows that a limit of 2^23 packets can be used 927 to obtain the same confidentiality protection as the limits specified 928 in TLS. 930 The usage limits defined in TLS 1.3 exist for protection against 931 attacks on confidentiality and apply to successful applications of 932 AEAD protection. The integrity protections in authenticated 933 encryption also depend on limiting the number of attempts to forge 934 packets. TLS achieves this by closing connections after any record 935 fails an authentication check. In comparison, DTLS ignores any 936 packet that cannot be authenticated, allowing multiple forgery 937 attempts. 939 Implementations MUST count the number of received packets that fail 940 authentication with each key. If the number of packets that fail 941 authentication exceed a limit that is specific to the AEAD in use, an 942 implementation SHOULD immediately close the connection. 943 Implementations SHOULD initiate a key update with update_requested 944 before reaching this limit. Once a key update has been initiated, 945 the previous keys can be dropped when the limit is reached rather 946 than closing the connection. Applying a limit reduces the 947 probability that an attacker is able to successfully forge a packet; 948 see [AEBounds] and [ROBUST]. 950 For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305, 951 the limit on the number of records that fail authentication is 2^36. 952 Note that the analysis in [AEBounds] supports a higher limit for the 953 AEAD_AES_128_GCM and AEAD_AES_256_GCM, but this specification 954 recommends a lower limit. For AEAD_AES_128_CCM, the limit on the 955 number of records that fail authentication is 2^23.5; see Appendix B. 957 The AEAD_AES_128_CCM_8 AEAD, as used in TLS_AES_128_CCM_8_SHA256, 958 does not have a limit on the number of records that fail 959 authentication that both limits the probability of forgery by the 960 same amount and does not expose implementations to the risk of denial 961 of service; see Appendix B.3. Therefore, TLS_AES_128_CCM_8_SHA256 962 MUST NOT be used in DTLS without additional safeguards against 963 forgery. Implementations MUST set usage limits for 964 AEAD_AES_128_CCM_8 based on an understanding of any additional 965 forgery protections that are used. 967 Any TLS cipher suite that is specified for use with DTLS MUST define 968 limits on the use of the associated AEAD function that preserves 969 margins for both confidentiality and integrity. That is, limits MUST 970 be specified for the number of packets that can be authenticated and 971 for the number of packets that can fail authentication before a key 972 update is required. Providing a reference to any analysis upon which 973 values are based - and any assumptions used in that analysis - allows 974 limits to be adapted to varying usage conditions. 976 5. The DTLS Handshake Protocol 978 DTLS 1.3 re-uses the TLS 1.3 handshake messages and flows, with the 979 following changes: 981 1. To handle message loss, reordering, and fragmentation 982 modifications to the handshake header are necessary. 984 2. Retransmission timers are introduced to handle message loss. 986 3. A new ACK content type has been added for reliable message 987 delivery of handshake messages. 989 Note that TLS 1.3 already supports a cookie extension, which is used 990 to prevent denial-of-service attacks. This DoS prevention mechanism 991 is described in more detail below since UDP-based protocols are more 992 vulnerable to amplification attacks than a connection-oriented 993 transport like TCP that performs return-routability checks as part of 994 the connection establishment. 996 DTLS implementations do not use the TLS 1.3 "compatibility mode" 997 described in Section D.4 of [TLS13]. DTLS servers MUST NOT echo the 998 "legacy_session_id" value from the client and endpoints MUST NOT send 999 ChangeCipherSpec messages. 1001 With these exceptions, the DTLS message formats, flows, and logic are 1002 the same as those of TLS 1.3. 1004 5.1. Denial-of-Service Countermeasures 1006 Datagram security protocols are extremely susceptible to a variety of 1007 DoS attacks. Two attacks are of particular concern: 1009 1. An attacker can consume excessive resources on the server by 1010 transmitting a series of handshake initiation requests, causing 1011 the server to allocate state and potentially to perform expensive 1012 cryptographic operations. 1014 2. An attacker can use the server as an amplifier by sending 1015 connection initiation messages with a forged source address that 1016 belongs to a victim. The server then sends its response to the 1017 victim machine, thus flooding it. Depending on the selected 1018 parameters this response message can be quite large, as is the 1019 case for a Certificate message. 1021 In order to counter both of these attacks, DTLS borrows the stateless 1022 cookie technique used by Photuris [RFC2522] and IKE [RFC7296]. When 1023 the client sends its ClientHello message to the server, the server 1024 MAY respond with a HelloRetryRequest message. The HelloRetryRequest 1025 message, as well as the cookie extension, is defined in TLS 1.3. The 1026 HelloRetryRequest message contains a stateless cookie (see [TLS13]; 1027 Section 4.2.2). The client MUST send a new ClientHello with the 1028 cookie added as an extension. The server then verifies the cookie 1029 and proceeds with the handshake only if it is valid. This mechanism 1030 forces the attacker/client to be able to receive the cookie, which 1031 makes DoS attacks with spoofed IP addresses difficult. This 1032 mechanism does not provide any defense against DoS attacks mounted 1033 from valid IP addresses. 1035 The DTLS 1.3 specification changes how cookies are exchanged compared 1036 to DTLS 1.2. DTLS 1.3 re-uses the HelloRetryRequest message and 1037 conveys the cookie to the client via an extension. The client 1038 receiving the cookie uses the same extension to place the cookie 1039 subsequently into a ClientHello message. DTLS 1.2 on the other hand 1040 used a separate message, namely the HelloVerifyRequest, to pass a 1041 cookie to the client and did not utilize the extension mechanism. 1042 For backwards compatibility reasons, the cookie field in the 1043 ClientHello is present in DTLS 1.3 but is ignored by a DTLS 1.3 1044 compliant server implementation. 1046 The exchange is shown in Figure 6. Note that the figure focuses on 1047 the cookie exchange; all other extensions are omitted. 1049 Client Server 1050 ------ ------ 1051 ClientHello ------> 1053 <----- HelloRetryRequest 1054 + cookie 1056 ClientHello ------> 1057 + cookie 1059 [Rest of handshake] 1061 Figure 6: DTLS exchange with HelloRetryRequest containing the 1062 "cookie" extension 1064 The cookie extension is defined in Section 4.2.2 of [TLS13]. When 1065 sending the initial ClientHello, the client does not have a cookie 1066 yet. In this case, the cookie extension is omitted and the 1067 legacy_cookie field in the ClientHello message MUST be set to a zero- 1068 length vector (i.e., a zero-valued single byte length field). 1070 When responding to a HelloRetryRequest, the client MUST create a new 1071 ClientHello message following the description in Section 4.1.2 of 1072 [TLS13]. 1074 If the HelloRetryRequest message is used, the initial ClientHello and 1075 the HelloRetryRequest are included in the calculation of the 1076 transcript hash. The computation of the message hash for the 1077 HelloRetryRequest is done according to the description in 1078 Section 4.4.1 of [TLS13]. 1080 The handshake transcript is not reset with the second ClientHello and 1081 a stateless server-cookie implementation requires the content or hash 1082 of the initial ClientHello (and HelloRetryRequest) to be stored in 1083 the cookie. The initial ClientHello is included in the handshake 1084 transcript as a synthetic "message_hash" message, so only the hash 1085 value is needed for the handshake to complete, though the complete 1086 HelloRetryRequest contents are needed. 1088 When the second ClientHello is received, the server can verify that 1089 the cookie is valid and that the client can receive packets at the 1090 given IP address. If the client's apparent IP address is embedded in 1091 the cookie, this prevents an attacker from generating an acceptable 1092 ClientHello apparently from another user. 1094 One potential attack on this scheme is for the attacker to collect a 1095 number of cookies from different addresses where it controls 1096 endpoints and then reuse them to attack the server. The server can 1097 defend against this attack by changing the secret value frequently, 1098 thus invalidating those cookies. If the server wishes to allow 1099 legitimate clients to handshake through the transition (e.g., a 1100 client received a cookie with Secret 1 and then sent the second 1101 ClientHello after the server has changed to Secret 2), the server can 1102 have a limited window during which it accepts both secrets. 1103 [RFC7296] suggests adding a key identifier to cookies to detect this 1104 case. An alternative approach is simply to try verifying with both 1105 secrets. It is RECOMMENDED that servers implement a key rotation 1106 scheme that allows the server to manage keys with overlapping 1107 lifetime. 1109 Alternatively, the server can store timestamps in the cookie and 1110 reject cookies that were generated outside a certain interval of 1111 time. 1113 DTLS servers SHOULD perform a cookie exchange whenever a new 1114 handshake is being performed. If the server is being operated in an 1115 environment where amplification is not a problem, the server MAY be 1116 configured not to perform a cookie exchange. The default SHOULD be 1117 that the exchange is performed, however. In addition, the server MAY 1118 choose not to do a cookie exchange when a session is resumed or, more 1119 generically, when the DTLS handshake uses a PSK-based key exchange 1120 and the IP address matches one associated with the PSK. Servers 1121 which process 0-RTT requests and send 0.5-RTT responses without a 1122 cookie exchange risk being used in an amplification attack if the 1123 size of outgoing messages greatly exceeds the size of those that are 1124 received. A server SHOULD limit the amount of data it sends toward a 1125 client address to three times the amount of data sent by the client 1126 before it verifies that the client is able to receive data at that 1127 address. A client address is valid after a cookie exchange or 1128 handshake completion. Clients MUST be prepared to do a cookie 1129 exchange with every handshake. Note that cookies are only valid for 1130 the existing handshake and cannot be stored for future handshakes. 1132 If a server receives a ClientHello with an invalid cookie, it MUST 1133 terminate the handshake with an "illegal_parameter" alert. This 1134 allows the client to restart the connection from scratch without a 1135 cookie. 1137 As described in Section 4.1.4 of [TLS13], clients MUST abort the 1138 handshake with an "unexpected_message" alert in response to any 1139 second HelloRetryRequest which was sent in the same connection (i.e., 1140 where the ClientHello was itself in response to a HelloRetryRequest). 1142 DTLS clients which do not want to receive a Connection ID SHOULD 1143 still offer the "connection_id" extension unless there is an 1144 application profile to the contrary. This permits a server which 1145 wants to receive a CID to negotiate one. 1147 5.2. DTLS Handshake Message Format 1149 In order to support message loss, reordering, and message 1150 fragmentation, DTLS modifies the TLS 1.3 handshake header: 1152 enum { 1153 client_hello(1), 1154 server_hello(2), 1155 new_session_ticket(4), 1156 end_of_early_data(5), 1157 encrypted_extensions(8), 1158 certificate(11), 1159 certificate_request(13), 1160 certificate_verify(15), 1161 finished(20), 1162 key_update(24), 1163 message_hash(254), 1164 (255) 1165 } HandshakeType; 1167 struct { 1168 HandshakeType msg_type; /* handshake type */ 1169 uint24 length; /* bytes in message */ 1170 uint16 message_seq; /* DTLS-required field */ 1171 uint24 fragment_offset; /* DTLS-required field */ 1172 uint24 fragment_length; /* DTLS-required field */ 1173 select (msg_type) { 1174 case client_hello: ClientHello; 1175 case server_hello: ServerHello; 1176 case end_of_early_data: EndOfEarlyData; 1177 case encrypted_extensions: EncryptedExtensions; 1178 case certificate_request: CertificateRequest; 1179 case certificate: Certificate; 1180 case certificate_verify: CertificateVerify; 1181 case finished: Finished; 1182 case new_session_ticket: NewSessionTicket; 1183 case key_update: KeyUpdate; 1184 } body; 1185 } Handshake; 1187 The first message each side transmits in each association always has 1188 message_seq = 0. Whenever a new message is generated, the 1189 message_seq value is incremented by one. When a message is 1190 retransmitted, the old message_seq value is re-used, i.e., not 1191 incremented. From the perspective of the DTLS record layer, the 1192 retransmission is a new record. This record will have a new 1193 DTLSPlaintext.sequence_number value. 1195 Note: In DTLS 1.2 the message_seq was reset to zero in case of a 1196 rehandshake (i.e., renegotiation). On the surface, a rehandshake in 1197 DTLS 1.2 shares similarities with a post-handshake message exchange 1198 in DTLS 1.3. However, in DTLS 1.3 the message_seq is not reset to 1199 allow distinguishing a retransmission from a previously sent post- 1200 handshake message from a newly sent post-handshake message. 1202 DTLS implementations maintain (at least notionally) a 1203 next_receive_seq counter. This counter is initially set to zero. 1204 When a handshake message is received, if its message_seq value 1205 matches next_receive_seq, next_receive_seq is incremented and the 1206 message is processed. If the sequence number is less than 1207 next_receive_seq, the message MUST be discarded. If the sequence 1208 number is greater than next_receive_seq, the implementation SHOULD 1209 queue the message but MAY discard it. (This is a simple space/ 1210 bandwidth tradeoff). 1212 In addition to the handshake messages that are deprecated by the TLS 1213 1.3 specification, DTLS 1.3 furthermore deprecates the 1214 HelloVerifyRequest message originally defined in DTLS 1.0. DTLS 1215 1.3-compliant implements MUST NOT use the HelloVerifyRequest to 1216 execute a return-routability check. A dual-stack DTLS 1.2/DTLS 1.3 1217 client MUST, however, be prepared to interact with a DTLS 1.2 server. 1219 5.3. ClientHello Message 1221 The format of the ClientHello used by a DTLS 1.3 client differs from 1222 the TLS 1.3 ClientHello format as shown below. 1224 uint16 ProtocolVersion; 1225 opaque Random[32]; 1227 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 1229 struct { 1230 ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2 1231 Random random; 1232 opaque legacy_session_id<0..32>; 1233 opaque legacy_cookie<0..2^8-1>; // DTLS 1234 CipherSuite cipher_suites<2..2^16-2>; 1235 opaque legacy_compression_methods<1..2^8-1>; 1236 Extension extensions<8..2^16-1>; 1237 } ClientHello; 1239 legacy_version: In previous versions of DTLS, this field was used 1240 for version negotiation and represented the highest version number 1241 supported by the client. Experience has shown that many servers 1242 do not properly implement version negotiation, leading to "version 1243 intolerance" in which the server rejects an otherwise acceptable 1244 ClientHello with a version number higher than it supports. In 1245 DTLS 1.3, the client indicates its version preferences in the 1246 "supported_versions" extension (see Section 4.2.1 of [TLS13]) and 1247 the legacy_version field MUST be set to {254, 253}, which was the 1248 version number for DTLS 1.2. The supported_versions entries for 1249 DTLS 1.0 and DTLS 1.2 are 0xfeff and 0xfefd (to match the wire 1250 versions). The value 0xfefc is used to indicate DTLS 1.3. 1252 random: Same as for TLS 1.3, except that the downgrade sentinels 1253 described in Section 4.1.3 of [TLS13] when TLS 1.2 and TLS 1.1 and 1254 below are negotiated apply to DTLS 1.2 and DTLS 1.0 respectively. 1256 legacy_session_id: Versions of TLS and DTLS before version 1.3 1257 supported a "session resumption" feature which has been merged 1258 with pre-shared keys in version 1.3. A client which has a cached 1259 session ID set by a pre-DTLS 1.3 server SHOULD set this field to 1260 that value. Otherwise, it MUST be set as a zero-length vector 1261 (i.e., a zero-valued single byte length field). 1263 legacy_cookie: A DTLS 1.3-only client MUST set the legacy_cookie 1264 field to zero length. If a DTLS 1.3 ClientHello is received with 1265 any other value in this field, the server MUST abort the handshake 1266 with an "illegal_parameter" alert. 1268 cipher_suites: Same as for TLS 1.3; only suites with DTLS-OK=Y may 1269 be used. 1271 legacy_compression_methods: Same as for TLS 1.3. 1273 extensions: Same as for TLS 1.3. 1275 5.4. ServerHello Message 1277 The DTLS 1.3 ServerHello message is the same as the TLS 1.3 1278 ServerHello message, except that the legacy_version field is set to 1279 0xfefd, indicating DTLS 1.2. 1281 5.5. Handshake Message Fragmentation and Reassembly 1283 As described in Section 4.3 one or more handshake messages may be 1284 carried in a single datagram. However, handshake messages are 1285 potentially bigger than the size allowed by the underlying datagram 1286 transport. DTLS provides a mechanism for fragmenting a handshake 1287 message over a number of records, each of which can be transmitted in 1288 separate datagrams, thus avoiding IP fragmentation. 1290 When transmitting the handshake message, the sender divides the 1291 message into a series of N contiguous data ranges. The ranges MUST 1292 NOT overlap. The sender then creates N handshake messages, all with 1293 the same message_seq value as the original handshake message. Each 1294 new message is labeled with the fragment_offset (the number of bytes 1295 contained in previous fragments) and the fragment_length (the length 1296 of this fragment). The length field in all messages is the same as 1297 the length field of the original message. An unfragmented message is 1298 a degenerate case with fragment_offset=0 and fragment_length=length. 1299 Each handshake message fragment that is placed into a record MUST be 1300 delivered in a single UDP datagram. 1302 When a DTLS implementation receives a handshake message fragment 1303 corresponding to the next expected handshake message sequence number, 1304 it MUST buffer it until it has the entire handshake message. DTLS 1305 implementations MUST be able to handle overlapping fragment ranges. 1306 This allows senders to retransmit handshake messages with smaller 1307 fragment sizes if the PMTU estimate changes. Senders MUST NOT change 1308 handshake message bytes upon retransmission. Receivers MAY check 1309 that retransmitted bytes are identical and SHOULD abort the handshake 1310 with an "illegal_parameter" alert if the value of a byte changes. 1312 Note that as with TLS, multiple handshake messages may be placed in 1313 the same DTLS record, provided that there is room and that they are 1314 part of the same flight. Thus, there are two acceptable ways to pack 1315 two DTLS handshake messages into the same datagram: in the same 1316 record or in separate records. 1318 5.6. End Of Early Data 1320 The DTLS 1.3 handshake has one important difference from the TLS 1.3 1321 handshake: the EndOfEarlyData message is omitted both from the wire 1322 and the handshake transcript: because DTLS records have epochs, 1323 EndOfEarlyData is not necessary to determine when the early data is 1324 complete, and because DTLS is lossy, attackers can trivially mount 1325 the deletion attacks that EndOfEarlyData prevents in TLS. Servers 1326 SHOULD NOT accept records from epoch 1 indefinitely once they are 1327 able to process records from epoch 3. Though reordering of IP 1328 packets can result in records from epoch 1 arriving after records 1329 from epoch 3, this is not likely to persist for very long relative to 1330 the round trip time. Servers could discard epoch 1 keys after the 1331 first epoch 3 data arrives, or retain keys for processing epoch 1 1332 data for a short period. (See Section 6.1 for the definitions of 1333 each epoch.) 1335 5.7. DTLS Handshake Flights 1337 DTLS handshake messages are grouped into a series of message flights. 1338 A flight starts with the handshake message transmission of one peer 1339 and ends with the expected response from the other peer. Table 1 1340 contains a complete list of message combinations that constitute 1341 flights. 1343 +======+========+========+===================================+ 1344 | Note | Client | Server | Handshake Messages | 1345 +======+========+========+===================================+ 1346 | | x | | ClientHello | 1347 +------+--------+--------+-----------------------------------+ 1348 | | | x | HelloRetryRequest | 1349 +------+--------+--------+-----------------------------------+ 1350 | | | x | ServerHello, EncryptedExtensions, | 1351 | | | | CertificateRequest, Certificate, | 1352 | | | | CertificateVerify, Finished | 1353 +------+--------+--------+-----------------------------------+ 1354 | 1 | x | | Certificate, CertificateVerify, | 1355 | | | | Finished | 1356 +------+--------+--------+-----------------------------------+ 1357 | 1 | | x | NewSessionTicket | 1358 +------+--------+--------+-----------------------------------+ 1360 Table 1: Flight Handshake Message Combinations. 1362 Remarks: 1364 * Table 1 does not highlight any of the optional messages. 1366 * Regarding note (1): When a handshake flight is sent without any 1367 expected response, as it is the case with the client's final 1368 flight or with the NewSessionTicket message, the flight must be 1369 acknowledged with an ACK message. 1371 Below are several example message exchange illustrating the flight 1372 concept. The notational conventions from [TLS13] are used. 1374 Client Server 1376 +--------+ 1377 ClientHello | Flight | 1378 --------> +--------+ 1380 +--------+ 1381 <-------- HelloRetryRequest | Flight | 1382 + cookie +--------+ 1384 +--------+ 1385 ClientHello | Flight | 1386 + cookie --------> +--------+ 1388 ServerHello 1389 {EncryptedExtensions} +--------+ 1390 {CertificateRequest*} | Flight | 1391 {Certificate*} +--------+ 1392 {CertificateVerify*} 1393 {Finished} 1394 <-------- [Application Data*] 1396 {Certificate*} +--------+ 1397 {CertificateVerify*} | Flight | 1398 {Finished} --------> +--------+ 1399 [Application Data] 1401 +--------+ 1402 <-------- [ACK] | Flight | 1403 [Application Data*] +--------+ 1405 [Application Data] <-------> [Application Data] 1407 Figure 7: Message flights for a full DTLS Handshake (with cookie 1408 exchange) 1410 ClientHello +--------+ 1411 + pre_shared_key | Flight | 1412 + psk_key_exchange_modes +--------+ 1413 + key_share* --------> 1415 ServerHello 1416 + pre_shared_key +--------+ 1417 + key_share* | Flight | 1418 {EncryptedExtensions} +--------+ 1419 <-------- {Finished} 1420 [Application Data*] 1421 +--------+ 1422 {Finished} --------> | Flight | 1423 [Application Data*] +--------+ 1425 +--------+ 1426 <-------- [ACK] | Flight | 1427 [Application Data*] +--------+ 1429 [Application Data] <-------> [Application Data] 1431 Figure 8: Message flights for resumption and PSK handshake 1432 (without cookie exchange) 1434 Client Server 1436 ClientHello 1437 + early_data 1438 + psk_key_exchange_modes +--------+ 1439 + key_share* | Flight | 1440 + pre_shared_key +--------+ 1441 (Application Data*) --------> 1443 ServerHello 1444 + pre_shared_key 1445 + key_share* +--------+ 1446 {EncryptedExtensions} | Flight | 1447 {Finished} +--------+ 1448 <-------- [Application Data*] 1450 +--------+ 1451 {Finished} --------> | Flight | 1452 [Application Data*] +--------+ 1454 +--------+ 1455 <-------- [ACK] | Flight | 1456 [Application Data*] +--------+ 1458 [Application Data] <-------> [Application Data] 1460 Figure 9: Message flights for the Zero-RTT handshake 1462 Client Server 1464 +--------+ 1465 <-------- [NewSessionTicket] | Flight | 1466 +--------+ 1468 +--------+ 1469 [ACK] --------> | Flight | 1470 +--------+ 1472 Figure 10: Message flights for the NewSessionTicket message 1474 KeyUpdate, NewConnectionId and RequestConnectionId follow a similar 1475 pattern to NewSessionTicket: a single message sent by one side 1476 followed by an ACK by the other. 1478 5.8. Timeout and Retransmission 1480 5.8.1. State Machine 1482 DTLS uses a simple timeout and retransmission scheme with the state 1483 machine shown in Figure 11. 1485 +-----------+ 1486 | PREPARING | 1487 +----------> | | 1488 | | | 1489 | +-----------+ 1490 | | 1491 | | Buffer next flight 1492 | | 1493 | \|/ 1494 | +-----------+ 1495 | | | 1496 | | SENDING |<------------------+ 1497 | | | | 1498 | +-----------+ | 1499 Receive | | | 1500 next | | Send flight or partial | 1501 flight | | flight | 1502 | | | 1503 | | Set retransmit timer | 1504 | \|/ | 1505 | +-----------+ | 1506 | | | | 1507 +------------| WAITING |-------------------+ 1508 | +----->| | Timer expires | 1509 | | +-----------+ | 1510 | | | | | | 1511 | | | | | | 1512 | +----------+ | +--------------------+ 1513 | Receive record | Read retransmit or ACK 1514 Receive | (Maybe Send ACK) | 1515 last | | 1516 flight | | Receive ACK 1517 | | for last flight 1518 \|/ | 1519 | 1520 +-----------+ | 1521 | | <---------+ 1522 | FINISHED | 1523 | | 1524 +-----------+ 1525 | /|\ 1526 | | 1527 | | 1528 +---+ 1530 Server read retransmit 1531 Retransmit ACK 1533 Figure 11: DTLS timeout and retransmission state machine 1535 The state machine has four basic states: PREPARING, SENDING, WAITING, 1536 and FINISHED. 1538 In the PREPARING state, the implementation does whatever computations 1539 are necessary to prepare the next flight of messages. It then 1540 buffers them up for transmission (emptying the transmission buffer 1541 first) and enters the SENDING state. 1543 In the SENDING state, the implementation transmits the buffered 1544 flight of messages. If the implementation has received one or more 1545 ACKs (see Section 7) from the peer, then it SHOULD omit any messages 1546 or message fragments which have already been ACKed. Once the 1547 messages have been sent, the implementation then sets a retransmit 1548 timer and enters the WAITING state. 1550 There are four ways to exit the WAITING state: 1552 1. The retransmit timer expires: the implementation transitions to 1553 the SENDING state, where it retransmits the flight, adjusts and 1554 re-arms the retransmit timer (see Section 5.8.2), and returns to 1555 the WAITING state. 1557 2. The implementation reads an ACK from the peer: upon receiving an 1558 ACK for a partial flight (as mentioned in Section 7.1), the 1559 implementation transitions to the SENDING state, where it 1560 retransmits the unacked portion of the flight, adjusts and re- 1561 arms the retransmit timer, and returns to the WAITING state. 1562 Upon receiving an ACK for a complete flight, the implementation 1563 cancels all retransmissions and either remains in WAITING, or, if 1564 the ACK was for the final flight, transitions to FINISHED. 1566 3. The implementation reads a retransmitted flight from the peer: 1567 the implementation transitions to the SENDING state, where it 1568 retransmits the flight, adjusts and re-arms the retransmit timer, 1569 and returns to the WAITING state. The rationale here is that the 1570 receipt of a duplicate message is the likely result of timer 1571 expiry on the peer and therefore suggests that part of one's 1572 previous flight was lost. 1574 4. The implementation receives some or all of the next flight of 1575 messages: if this is the final flight of messages, the 1576 implementation transitions to FINISHED. If the implementation 1577 needs to send a new flight, it transitions to the PREPARING 1578 state. Partial reads (whether partial messages or only some of 1579 the messages in the flight) may also trigger the implementation 1580 to send an ACK, as described in Section 7.1. 1582 Because DTLS clients send the first message (ClientHello), they start 1583 in the PREPARING state. DTLS servers start in the WAITING state, but 1584 with empty buffers and no retransmit timer. 1586 In addition, for at least twice the default MSL defined for 1587 [RFC0793], when in the FINISHED state, the server MUST respond to 1588 retransmission of the client's final flight with a retransmit of its 1589 ACK. 1591 Note that because of packet loss, it is possible for one side to be 1592 sending application data even though the other side has not received 1593 the first side's Finished message. Implementations MUST either 1594 discard or buffer all application data records for epoch 3 and above 1595 until they have received the Finished message from the peer. 1596 Implementations MAY treat receipt of application data with a new 1597 epoch prior to receipt of the corresponding Finished message as 1598 evidence of reordering or packet loss and retransmit their final 1599 flight immediately, shortcutting the retransmission timer. 1601 5.8.2. Timer Values 1603 The configuration of timer settings varies with implementations, and 1604 certain deployment environments require timer value adjustments. 1605 Mishandling of the timer can lead to serious congestion problems, for 1606 example if many instances of a DTLS time out early and retransmit too 1607 quickly on a congested link. 1609 Unless implementations have deployment-specific and/or external 1610 information about the round trip time, implementations SHOULD use an 1611 initial timer value of 1000 ms and double the value at each 1612 retransmission, up to no less than 60 seconds (the RFC 6298 [RFC6298] 1613 maximum). Application specific profiles MAY recommend shorter or 1614 longer timer values. For instance: 1616 * Profiles for specific deployment environments, such as in low- 1617 power, multi-hop mesh scenarios as used in some Internet of Things 1618 (IoT) networks, MAY specify longer timeouts. See 1619 [I-D.ietf-uta-tls13-iot-profile] for more information about one 1620 such DTLS 1.3 IoT profile. 1622 * Real-time protocols MAY specify shorter timeouts. It is 1623 RECOMMENDED that for DTLS-SRTP [RFC5764], a default timeout of 1624 400ms be used; because customer experience degrades with one-way 1625 latencies of greater than 200ms, real-time deployments are less 1626 likely to have long latencies. 1628 In settings where there is external information (for instance from an 1629 ICE [RFC8445] handshake, or from previous connections to the same 1630 server) about the RTT, implementations SHOULD use 1.5 times that RTT 1631 estimate as the retransmit timer. 1633 Implementations SHOULD retain the current timer value until a message 1634 is transmitted and acknowledged without having to be retransmitted, 1635 at which time the value SHOULD be adjusted to 1.5 times the measured 1636 round trip time for that message. After a long period of idleness, 1637 no less than 10 times the current timer value, implementations MAY 1638 reset the timer to the initial value. 1640 Note that because retransmission is for the handshake and not 1641 dataflow, the effect on congestion of shorter timeouts is smaller 1642 than in generic protocols such as TCP or QUIC. Experience with DTLS 1643 1.2, which uses a simpler "retransmit everything on timeout" 1644 approach, has not shown serious congestion problems in practice. 1646 5.8.3. Large Flight Sizes 1648 DTLS does not have any built-in congestion control or rate control; 1649 in general this is not an issue because messages tend to be small. 1650 However, in principle, some messages - especially Certificate - can 1651 be quite large. If all the messages in a large flight are sent at 1652 once, this can result in network congestion. A better strategy is to 1653 send out only part of the flight, sending more when messages are 1654 acknowledged. Several extensions have been standardized to reduce 1655 the size of the certificate message, for example the cached 1656 information extension [RFC7924], certificate compression [RFC8879] 1657 and [RFC6066], which defines the "client_certificate_url" extension 1658 allowing DTLS clients to send a sequence of Uniform Resource Locators 1659 (URLs) instead of the client certificate. 1661 DTLS stacks SHOULD NOT send more than 10 records in a single 1662 transmission. 1664 5.8.4. State machine duplication for post-handshake messages 1666 DTLS 1.3 makes use of the following categories of post-handshake 1667 messages: 1669 1. NewSessionTicket 1671 2. KeyUpdate 1673 3. NewConnectionId 1675 4. RequestConnectionId 1676 5. Post-handshake client authentication 1678 Messages of each category can be sent independently, and reliability 1679 is established via independent state machines each of which behaves 1680 as described in Section 5.8.1. For example, if a server sends a 1681 NewSessionTicket and a CertificateRequest message, two independent 1682 state machines will be created. 1684 As explained in the corresponding sections, sending multiple 1685 instances of messages of a given category without having completed 1686 earlier transmissions is allowed for some categories, but not for 1687 others. Specifically, a server MAY send multiple NewSessionTicket 1688 messages at once without awaiting ACKs for earlier NewSessionTicket 1689 first. Likewise, a server MAY send multiple CertificateRequest 1690 messages at once without having completed earlier client 1691 authentication requests before. In contrast, implementations MUST 1692 NOT send KeyUpdate, NewConnectionId or RequestConnectionId messages 1693 if an earlier message of the same type has not yet been acknowledged. 1695 Note: Except for post-handshake client authentication, which involves 1696 handshake messages in both directions, post-handshake messages are 1697 single-flight, and their respective state machines on the sender side 1698 reduce to waiting for an ACK and retransmitting the original message. 1699 In particular, note that a RequestConnectionId message does not force 1700 the receiver to send a NewConnectionId message in reply, and both 1701 messages are therefore treated independently. 1703 Creating and correctly updating multiple state machines requires 1704 feedback from the handshake logic to the state machine layer, 1705 indicating which message belongs to which state machine. For 1706 example, if a server sends multiple CertificateRequest messages and 1707 receives a Certificate message in response, the corresponding state 1708 machine can only be determined after inspecting the 1709 certificate_request_context field. Similarly, a server sending a 1710 single CertificateRequest and receiving a NewConnectionId message in 1711 response can only decide that the NewConnectionId message should be 1712 treated through an independent state machine after inspecting the 1713 handshake message type. 1715 5.9. CertificateVerify and Finished Messages 1717 CertificateVerify and Finished messages have the same format as in 1718 TLS 1.3. Hash calculations include entire handshake messages, 1719 including DTLS-specific fields: message_seq, fragment_offset, and 1720 fragment_length. However, in order to remove sensitivity to 1721 handshake message fragmentation, the CertificateVerify and the 1722 Finished messages MUST be computed as if each handshake message had 1723 been sent as a single fragment following the algorithm described in 1724 Section 4.4.3 and Section 4.4.4 of [TLS13], respectively. 1726 5.10. Cryptographic Label Prefix 1728 Section 7.1 of [TLS13] specifies that HKDF-Expand-Label uses a label 1729 prefix of "tls13 ". For DTLS 1.3, that label SHALL be "dtls13". 1730 This ensures key separation between DTLS 1.3 and TLS 1.3. Note that 1731 there is no trailing space; this is necessary in order to keep the 1732 overall label size inside of one hash iteration because "DTLS" is one 1733 letter longer than "TLS". 1735 5.11. Alert Messages 1737 Note that Alert messages are not retransmitted at all, even when they 1738 occur in the context of a handshake. However, a DTLS implementation 1739 which would ordinarily issue an alert SHOULD generate a new alert 1740 message if the offending record is received again (e.g., as a 1741 retransmitted handshake message). Implementations SHOULD detect when 1742 a peer is persistently sending bad messages and terminate the local 1743 connection state after such misbehavior is detected. Note that 1744 alerts are not reliably transmitted; implementation SHOULD NOT depend 1745 on receiving alerts in order to signal errors or connection closure. 1747 5.12. Establishing New Associations with Existing Parameters 1749 If a DTLS client-server pair is configured in such a way that 1750 repeated connections happen on the same host/port quartet, then it is 1751 possible that a client will silently abandon one connection and then 1752 initiate another with the same parameters (e.g., after a reboot). 1753 This will appear to the server as a new handshake with epoch=0. In 1754 cases where a server believes it has an existing association on a 1755 given host/port quartet and it receives an epoch=0 ClientHello, it 1756 SHOULD proceed with a new handshake but MUST NOT destroy the existing 1757 association until the client has demonstrated reachability either by 1758 completing a cookie exchange or by completing a complete handshake 1759 including delivering a verifiable Finished message. After a correct 1760 Finished message is received, the server MUST abandon the previous 1761 association to avoid confusion between two valid associations with 1762 overlapping epochs. The reachability requirement prevents off-path/ 1763 blind attackers from destroying associations merely by sending forged 1764 ClientHellos. 1766 Note: it is not always possible to distinguish which association a 1767 given record is from. For instance, if the client performs a 1768 handshake, abandons the connection, and then immediately starts a new 1769 handshake, it may not be possible to tell which connection a given 1770 protected record is for. In these cases, trial decryption may be 1771 necessary, though implementations could use CIDs to avoid the 5- 1772 tuple-based ambiguity. 1774 6. Example of Handshake with Timeout and Retransmission 1776 The following is an example of a handshake with lost packets and 1777 retransmissions. Note that the client sends an empty ACK message 1778 because it can only acknowledge Record 2 sent by the server once it 1779 has processed messages in Record 0 needed to establish epoch 2 keys, 1780 which are needed to encrypt or decrypt messages found in Record 2. 1781 Section 7 provides the necessary background details for this 1782 interaction. Note: for simplicity we are not re-setting record 1783 numbers in this diagram, so "Record 1" is really "Epoch 2, Record 0, 1784 etc.". 1786 Client Server 1787 ------ ------ 1789 Record 0 --------> 1790 ClientHello 1791 (message_seq=0) 1793 X<----- Record 0 1794 (lost) ServerHello 1795 (message_seq=0) 1796 Record 1 1797 EncryptedExtensions 1798 (message_seq=1) 1799 Certificate 1800 (message_seq=2) 1802 <-------- Record 2 1803 CertificateVerify 1804 (message_seq=3) 1805 Finished 1806 (message_seq=4) 1808 Record 1 --------> 1809 ACK [] 1810 <-------- Record 3 1811 ServerHello 1812 (message_seq=0) 1813 EncryptedExtensions 1814 (message_seq=1) 1815 Certificate 1816 (message_seq=2) 1818 <-------- Record 4 1819 CertificateVerify 1820 (message_seq=3) 1821 Finished 1822 (message_seq=4) 1824 Record 2 --------> 1825 Certificate 1826 (message_seq=1) 1827 CertificateVerify 1828 (message_seq=2) 1829 Finished 1830 (message_seq=3) 1832 <-------- Record 5 1833 ACK [2] 1835 Figure 12: Example DTLS exchange illustrating message loss 1837 6.1. Epoch Values and Rekeying 1839 A recipient of a DTLS message needs to select the correct keying 1840 material in order to process an incoming message. With the 1841 possibility of message loss and re-ordering, an identifier is needed 1842 to determine which cipher state has been used to protect the record 1843 payload. The epoch value fulfills this role in DTLS. In addition to 1844 the TLS 1.3-defined key derivation steps, see Section 7 of [TLS13], a 1845 sender may want to rekey at any time during the lifetime of the 1846 connection. It therefore needs to indicate that it is updating its 1847 sending cryptographic keys. 1849 This version of DTLS assigns dedicated epoch values to messages in 1850 the protocol exchange to allow identification of the correct cipher 1851 state: 1853 * epoch value (0) is used with unencrypted messages. There are 1854 three unencrypted messages in DTLS, namely ClientHello, 1855 ServerHello, and HelloRetryRequest. 1857 * epoch value (1) is used for messages protected using keys derived 1858 from client_early_traffic_secret. Note this epoch is skipped if 1859 the client does not offer early data. 1861 * epoch value (2) is used for messages protected using keys derived 1862 from [sender]_handshake_traffic_secret. Messages transmitted 1863 during the initial handshake, such as EncryptedExtensions, 1864 CertificateRequest, Certificate, CertificateVerify, and Finished 1865 belong to this category. Note, however, post-handshake are 1866 protected under the appropriate application traffic key and are 1867 not included in this category. 1869 * epoch value (3) is used for payloads protected using keys derived 1870 from the initial [sender]_application_traffic_secret_0. This may 1871 include handshake messages, such as post-handshake messages (e.g., 1872 a NewSessionTicket message). 1874 * epoch value (4 to 2^16-1) is used for payloads protected using 1875 keys from the [sender]_application_traffic_secret_N (N>0). 1877 Using these reserved epoch values a receiver knows what cipher state 1878 has been used to encrypt and integrity protect a message. 1879 Implementations that receive a record with an epoch value for which 1880 no corresponding cipher state can be determined SHOULD handle it as a 1881 record which fails deprotection. 1883 Note that epoch values do not wrap. If a DTLS implementation would 1884 need to wrap the epoch value, it MUST terminate the connection. 1886 The traffic key calculation is described in Section 7.3 of [TLS13]. 1888 Figure 13 illustrates the epoch values in an example DTLS handshake. 1890 Client Server 1891 ------ ------ 1893 Record 0 1894 ClientHello 1895 (epoch=0) 1896 --------> 1897 Record 0 1898 <-------- HelloRetryRequest 1899 (epoch=0) 1900 Record 1 1901 ClientHello --------> 1902 (epoch=0) 1903 Record 1 1904 <-------- ServerHello 1905 (epoch=0) 1906 {EncryptedExtensions} 1907 (epoch=2) 1908 {Certificate} 1909 (epoch=2) 1910 {CertificateVerify} 1911 (epoch=2) 1912 {Finished} 1913 (epoch=2) 1914 Record 2 1915 {Certificate} --------> 1916 (epoch=2) 1917 {CertificateVerify} 1918 (epoch=2) 1919 {Finished} 1920 (epoch=2) 1921 Record 2 1922 <-------- [ACK] 1923 (epoch=3) 1924 Record 3 1925 [Application Data] --------> 1926 (epoch=3) 1927 Record 3 1928 <-------- [Application Data] 1929 (epoch=3) 1931 Some time later ... 1932 (Post-Handshake Message Exchange) 1933 Record 4 1934 <-------- [NewSessionTicket] 1935 (epoch=3) 1936 Record 4 1937 [ACK] --------> 1938 (epoch=3) 1940 Some time later ... 1941 (Rekeying) 1942 Record 5 1943 <-------- [Application Data] 1944 (epoch=4) 1945 Record 5 1946 [Application Data] --------> 1947 (epoch=4) 1949 Figure 13: Example DTLS exchange with epoch information 1951 7. ACK Message 1953 The ACK message is used by an endpoint to indicate which handshake 1954 records it has received and processed from the other side. ACK is 1955 not a handshake message but is rather a separate content type, with 1956 code point TBD (proposed, 25). This avoids having ACK being added to 1957 the handshake transcript. Note that ACKs can still be sent in the 1958 same UDP datagram as handshake records. 1960 struct { 1961 RecordNumber record_numbers<0..2^16-1>; 1962 } ACK; 1964 record_numbers: a list of the records containing handshake messages 1965 in the current flight which the endpoint has received and either 1966 processed or buffered, in numerically increasing order. 1968 Implementations MUST NOT acknowledge records containing handshake 1969 messages or fragments which have not been processed or buffered. 1970 Otherwise, deadlock can ensue. As an example, implementations MUST 1971 NOT send ACKs for handshake messages which they discard because they 1972 are not the next expected message. 1974 During the handshake, ACKs only cover the current outstanding flight 1975 (this is possible because DTLS is generally a lockstep protocol). In 1976 particular, receiving a message from a handshake flight implicitly 1977 acknowledges all messages from the previous flight(s). Accordingly, 1978 an ACK from the server would not cover both the ClientHello and the 1979 client's Certificate, because the ClientHello and client Certificate 1980 are in different flights. Implementations can accomplish this by 1981 clearing their ACK list upon receiving the start of the next flight. 1983 After the handshake, ACKs SHOULD be sent once for each received and 1984 processed handshake record (potentially subject to some delay) and 1985 MAY cover more than one flight. This includes records containing 1986 messages which are discarded because a previous copy has been 1987 received. 1989 During the handshake, ACK records MUST be sent with an epoch that is 1990 equal to or higher than the record which is being acknowledged. Note 1991 that some care is required when processing flights spanning multiple 1992 epochs. For instance, if the client receives only the Server Hello 1993 and Certificate and wishes to ACK them in a single record, it must do 1994 so in epoch 2, as it is required to use an epoch greater than or 1995 equal to 2 and cannot yet send with any greater epoch. 1996 Implementations SHOULD simply use the highest current sending epoch, 1997 which will generally be the highest available. After the handshake, 1998 implementations MUST use the highest available sending epoch. 2000 7.1. Sending ACKs 2002 When an implementation detects a disruption in the receipt of the 2003 current incoming flight, it SHOULD generate an ACK that covers the 2004 messages from that flight which it has received and processed so far. 2005 Implementations have some discretion about which events to treat as 2006 signs of disruption, but it is RECOMMENDED that they generate ACKs 2007 under two circumstances: 2009 * When they receive a message or fragment which is out of order, 2010 either because it is not the next expected message or because it 2011 is not the next piece of the current message. 2013 * When they have received part of a flight and do not immediately 2014 receive the rest of the flight (which may be in the same UDP 2015 datagram). "Immediately" is hard to define. One approach is to 2016 set a timer for 1/4 the current retransmit timer value when the 2017 first record in the flight is received and then send an ACK when 2018 that timer expires. Note: the 1/4 value here is somewhat 2019 arbitrary. Given that the round trip estimates in the DTLS 2020 handshake are generally very rough (or the default), any value 2021 will be an approximation, and there is an inherent compromise due 2022 to competition between retransmision due to over-agressive ACKing 2023 and over-aggressive timeout-based retransmission. As a comparison 2024 point, QUIC's loss-based recovery algorithms 2025 ([I-D.ietf-quic-recovery]; Section 6.1.2) work out to a delay of 2026 about 1/3 of the retransmit timer. 2028 In general, flights MUST be ACKed unless they are implicitly 2029 acknowledged. In the present specification the following flights are 2030 implicitly acknowledged by the receipt of the next flight, which 2031 generally immediately follows the flight, 2033 1. Handshake flights other than the client's final flight of the 2034 main handshake. 2036 2. The server's post-handshake CertificateRequest. 2038 ACKs SHOULD NOT be sent for these flights unless the responding 2039 flight cannot be generated immediately. In this case, 2040 implementations MAY send explicit ACKs for the complete received 2041 flight even though it will eventually also be implicitly acknowledged 2042 through the responding flight. A notable example for this is the 2043 case of client authentication in constrained environments, where 2044 generating the CertificateVerify message can take considerable time 2045 on the client. All other flights MUST be ACKed. Implementations MAY 2046 acknowledge the records corresponding to each transmission of each 2047 flight or simply acknowledge the most recent one. In general, 2048 implementations SHOULD ACK as many received packets as can fit into 2049 the ACK record, as this provides the most complete information and 2050 thus reduces the chance of spurious retransmission; if space is 2051 limited, implementations SHOULD favor including records which have 2052 not yet been acknowledged. 2054 Note: While some post-handshake messages follow a request/response 2055 pattern, this does not necessarily imply receipt. For example, a 2056 KeyUpdate sent in response to a KeyUpdate with request_update set to 2057 'update_requested' does not implicitly acknowledge the earlier 2058 KeyUpdate message because the two KeyUpdate messages might have 2059 crossed in flight. 2061 ACKs MUST NOT be sent for other records of any content type other 2062 than handshake or for records which cannot be unprotected. 2064 Note that in some cases it may be necessary to send an ACK which does 2065 not contain any record numbers. For instance, a client might receive 2066 an EncryptedExtensions message prior to receiving a ServerHello. 2067 Because it cannot decrypt the EncryptedExtensions, it cannot safely 2068 acknowledge it (as it might be damaged). If the client does not send 2069 an ACK, the server will eventually retransmit its first flight, but 2070 this might take far longer than the actual round trip time between 2071 client and server. Having the client send an empty ACK shortcuts 2072 this process. 2074 7.2. Receiving ACKs 2076 When an implementation receives an ACK, it SHOULD record that the 2077 messages or message fragments sent in the records being ACKed were 2078 received and omit them from any future retransmissions. Upon receipt 2079 of an ACK that leaves it with only some messages from a flight having 2080 been acknowledged an implementation SHOULD retransmit the 2081 unacknowledged messages or fragments. Note that this requires 2082 implementations to track which messages appear in which records. 2083 Once all the messages in a flight have been acknowledged, the 2084 implementation MUST cancel all retransmissions of that flight. 2085 Implementations MUST treat a record as having been acknowledged if it 2086 appears in any ACK; this prevents spurious retransmission in cases 2087 where a flight is very large and the receiver is forced to elide 2088 acknowledgements for records which have already been ACKed. As noted 2089 above, the receipt of any record responding to a given flight MUST be 2090 taken as an implicit acknowledgement for the entire flight to which 2091 it is responding. 2093 7.3. Design Rationale 2095 ACK messages are used in two circumstances, namely : 2097 * on sign of disruption, or lack of progress, and 2099 * to indicate complete receipt of the last flight in a handshake. 2101 In the first case the use of the ACK message is optional because the 2102 peer will retransmit in any case and therefore the ACK just allows 2103 for selective or early retransmission, as opposed to the timeout- 2104 based whole flight retransmission in previous versions of DTLS. When 2105 DTLS 1.3 is used in deployments with lossy networks, such as low- 2106 power, long range radio networks as well as low-power mesh networks, 2107 the use of ACKs is recommended. 2109 The use of the ACK for the second case is mandatory for the proper 2110 functioning of the protocol. For instance, the ACK message sent by 2111 the client in Figure 13, acknowledges receipt and processing of 2112 record 4 (containing the NewSessionTicket message) and if it is not 2113 sent the server will continue retransmission of the NewSessionTicket 2114 indefinitely until its maximum retransmission count is reached. 2116 8. Key Updates 2118 As with TLS 1.3, DTLS 1.3 implementations send a KeyUpdate message to 2119 indicate that they are updating their sending keys. As with other 2120 handshake messages with no built-in response, KeyUpdates MUST be 2121 acknowledged. In order to facilitate epoch reconstruction 2122 Section 4.2.2 implementations MUST NOT send records with the new keys 2123 or send a new KeyUpdate until the previous KeyUpdate has been 2124 acknowledged (this avoids having too many epochs in active use). 2126 Due to loss and/or re-ordering, DTLS 1.3 implementations may receive 2127 a record with an older epoch than the current one (the requirements 2128 above preclude receiving a newer record). They SHOULD attempt to 2129 process those records with that epoch (see Section 4.2.2 for 2130 information on determining the correct epoch), but MAY opt to discard 2131 such out-of-epoch records. 2133 Due to the possibility of an ACK message for a KeyUpdate being lost 2134 and thereby preventing the sender of the KeyUpdate from updating its 2135 keying material, receivers MUST retain the pre-update keying material 2136 until receipt and successful decryption of a message using the new 2137 keys. 2139 Figure 14 shows an example exchange illustrating that a successful 2140 ACK processing updates the keys of the KeyUpdate message sender, 2141 which is reflected in the change of epoch values. 2143 Client Server 2145 /-------------------------------------------\ 2146 | | 2147 | Initial Handshake | 2148 \-------------------------------------------/ 2150 [Application Data] --------> 2151 (epoch=3) 2153 <-------- [Application Data] 2154 (epoch=3) 2156 /-------------------------------------------\ 2157 | | 2158 | Some time later ... | 2159 \-------------------------------------------/ 2161 [Application Data] --------> 2162 (epoch=3) 2164 [KeyUpdate] 2165 (+ update_requested --------> 2166 (epoch 3) 2168 <-------- [Application Data] 2169 (epoch=3) 2171 [Ack] 2172 <-------- (epoch=3) 2174 [Application Data] 2175 (epoch=4) --------> 2177 <-------- [KeyUpdate] 2178 (epoch=3) 2180 [Ack] --------> 2181 (epoch=4) 2183 <-------- [Application Data] 2184 (epoch=4) 2186 Figure 14: Example DTLS Key Update 2188 9. Connection ID Updates 2190 If the client and server have negotiated the "connection_id" 2191 extension [I-D.ietf-tls-dtls-connection-id], either side can send a 2192 new CID which it wishes the other side to use in a NewConnectionId 2193 message. 2195 enum { 2196 cid_immediate(0), cid_spare(1), (255) 2197 } ConnectionIdUsage; 2199 opaque ConnectionId<0..2^8-1>; 2201 struct { 2202 ConnectionIds cids<0..2^16-1>; 2203 ConnectionIdUsage usage; 2204 } NewConnectionId; 2206 cid Indicates the set of CIDs which the sender wishes the peer to 2207 use. 2209 usage Indicates whether the new CIDs should be used immediately or 2210 are spare. If usage is set to "cid_immediate", then one of the 2211 new CID MUST be used immediately for all future records. If it is 2212 set to "cid_spare", then either existing or new CID MAY be used. 2214 Endpoints SHOULD use receiver-provided CIDs in the order they were 2215 provided. Implementations which receive more spare CIDs than they 2216 wish to maintain MAY simply discard any extra CIDs. Endpoints MUST 2217 NOT have more than one NewConnectionId message outstanding. 2219 Implementations which either did not negotiate the "connection_id" 2220 extension or which have negotiated receiving an empty CID MUST NOT 2221 send NewConnectionId. Implementations MUST NOT send 2222 RequestConnectionId when sending an empty Connection ID. 2223 Implementations which detect a violation of these rules MUST 2224 terminate the connection with an "unexpected_message" alert. 2226 Implementations SHOULD use a new CID whenever sending on a new path, 2227 and SHOULD request new CIDs for this purpose if path changes are 2228 anticipated. 2230 struct { 2231 uint8 num_cids; 2232 } RequestConnectionId; 2234 num_cids The number of CIDs desired. 2236 Endpoints SHOULD respond to RequestConnectionId by sending a 2237 NewConnectionId with usage "cid_spare" containing num_cid CIDs soon 2238 as possible. Endpoints MUST NOT send a RequestConnectionId message 2239 when an existing request is still unfulfilled; this implies that 2240 endpoints needs to request new CIDs well in advance. An endpoint MAY 2241 handle requests, which it considers excessive, by responding with a 2242 NewConnectionId message containing fewer than num_cid CIDs, including 2243 no CIDs at all. Endpoints MAY handle an excessive number of 2244 RequestConnectionId messages by terminating the connection using a 2245 "too_many_cids_requested" (alert number 52) alert. 2247 Endpoints MUST NOT send either of these messages if they did not 2248 negotiate a CID. If an implementation receives these messages when 2249 CIDs were not negotiated, it MUST abort the connection with an 2250 unexpected_message alert. 2252 9.1. Connection ID Example 2254 Below is an example exchange for DTLS 1.3 using a single CID in each 2255 direction. 2257 Note: The connection_id extension is defined in 2258 [I-D.ietf-tls-dtls-connection-id], which is used in ClientHello and 2259 ServerHello messages. 2261 Client Server 2262 ------ ------ 2264 ClientHello 2265 (connection_id=5) 2266 --------> 2268 <-------- HelloRetryRequest 2269 (cookie) 2271 ClientHello --------> 2272 (connection_id=5) 2273 +cookie 2275 <-------- ServerHello 2276 (connection_id=100) 2277 EncryptedExtensions 2278 (cid=5) 2279 Certificate 2280 (cid=5) 2281 CertificateVerify 2282 (cid=5) 2283 Finished 2284 (cid=5) 2286 Certificate --------> 2287 (cid=100) 2288 CertificateVerify 2289 (cid=100) 2290 Finished 2291 (cid=100) 2292 <-------- Ack 2293 (cid=5) 2295 Application Data ========> 2296 (cid=100) 2297 <======== Application Data 2298 (cid=5) 2300 Figure 15: Example DTLS 1.3 Exchange with CIDs 2302 If no CID is negotiated, then the receiver MUST reject any records it 2303 receives that contain a CID. 2305 10. Application Data Protocol 2307 Application data messages are carried by the record layer and are 2308 split into records and encrypted based on the current connection 2309 state. The messages are treated as transparent data to the record 2310 layer. 2312 11. Security Considerations 2314 Security issues are discussed primarily in [TLS13]. 2316 The primary additional security consideration raised by DTLS is that 2317 of denial of service by excessive resource consumption. DTLS 2318 includes a cookie exchange designed to protect against denial of 2319 service. However, implementations that do not use this cookie 2320 exchange are still vulnerable to DoS. In particular, DTLS servers 2321 that do not use the cookie exchange may be used as attack amplifiers 2322 even if they themselves are not experiencing DoS. Therefore, DTLS 2323 servers SHOULD use the cookie exchange unless there is good reason to 2324 believe that amplification is not a threat in their environment. 2325 Clients MUST be prepared to do a cookie exchange with every 2326 handshake. 2328 Some key properties required of the cookie for the cookie-exchange 2329 mechanism to be functional are described in Section 3.3 of [RFC2522]: 2331 * the cookie MUST depend on the client's address. 2333 * it MUST NOT be possible for anyone other than the issuing entity 2334 to generate cookies that are accepted as valid by that entity. 2335 This typically entails an integrity check based on a secret key. 2337 * cookie generation and verification are triggered by 2338 unauthenticated parties, and as such their resource consumption 2339 needs to be restrained in order to avoid having the cookie- 2340 exchange mechanism itself serve as a DoS vector. 2342 Although the cookie must allow the server to produce the right 2343 handshake transcript, it SHOULD be constructed so that knowledge of 2344 the cookie is insufficient to reproduce the ClientHello contents. 2345 Otherwise, this may create problems with future extensions such as 2346 [I-D.ietf-tls-esni]. 2348 When cookies are generated using a keyed authentication mechanism it 2349 should be possible to rotate the associated secret key, so that 2350 temporary compromise of the key does not permanently compromise the 2351 integrity of the cookie-exchange mechanism. Though this secret is 2352 not as high-value as, e.g., a session-ticket-encryption key, rotating 2353 the cookie-generation key on a similar timescale would ensure that 2354 the key-rotation functionality is exercised regularly and thus in 2355 working order. 2357 The cookie exchange provides address validation during the initial 2358 handshake. DTLS with Connection IDs allows for endpoint addresses to 2359 change during the association; any such updated addresses are not 2360 covered by the cookie exchange during the handshake. DTLS 2361 implementations MUST NOT update the address they send to in response 2362 to packets from a different address unless they first perform some 2363 reachability test; no such test is defined in this specification. 2364 Even with such a test, an active on-path adversary can also black- 2365 hole traffic or create a reflection attack against third parties 2366 because a DTLS peer has no means to distinguish a genuine address 2367 update event (for example, due to a NAT rebinding) from one that is 2368 malicious. This attack is of concern when there is a large asymmetry 2369 of request/response message sizes. 2371 With the exception of order protection and non-replayability, the 2372 security guarantees for DTLS 1.3 are the same as TLS 1.3. While TLS 2373 always provides order protection and non-replayability, DTLS does not 2374 provide order protection and may not provide replay protection. 2376 Unlike TLS implementations, DTLS implementations SHOULD NOT respond 2377 to invalid records by terminating the connection. 2379 TLS 1.3 requires replay protection for 0-RTT data (or rather, for 2380 connections that use 0-RTT data; see Section 8 of [TLS13]). DTLS 2381 provides an optional per-record replay-protection mechanism, since 2382 datagram protocols are inherently subject to message reordering and 2383 replay. These two replay-protection mechanisms are orthogonal, and 2384 neither mechanism meets the requirements for the other. 2386 The security and privacy properties of the CID for DTLS 1.3 builds on 2387 top of what is described for DTLS 1.2 in 2388 [I-D.ietf-tls-dtls-connection-id]. There are, however, several 2389 differences: 2391 * In both versions of DTLS extension negotiation is used to agree on 2392 the use of the CID feature and the CID values. In both versions 2393 the CID is carried in the DTLS record header (if negotiated). 2394 However, the way the CID is included in the record header differs 2395 between the two versions. 2397 * The use of the Post-Handshake message allows the client and the 2398 server to update their CIDs and those values are exchanged with 2399 confidentiality protection. 2401 * The ability to use multiple CIDs allows for improved privacy 2402 properties in multi-homed scenarios. When only a single CID is in 2403 use on multiple paths from such a host, an adversary can correlate 2404 the communication interaction across paths, which adds further 2405 privacy concerns. In order to prevent this, implementations 2406 SHOULD attempt to use fresh CIDs whenever they change local 2407 addresses or ports (though this is not always possible to detect). 2408 The RequestConnectionId message can be used by a peer to ask for 2409 new CIDs to ensure that a pool of suitable CIDs is available. 2411 * The mechanism for encrypting sequence numbers (Section 4.2.3) 2412 prevents trivial tracking by on-path adversaries that attempt to 2413 correlate the pattern of sequence numbers received on different 2414 paths; such tracking could occur even when different CIDs are used 2415 on each path, in the absence of sequence number encryption. 2416 Switching CIDs based on certain events, or even regularly, helps 2417 against tracking by on-path adversaries. Note that sequence 2418 number encryption is used for all encrypted DTLS 1.3 records 2419 irrespective of whether a CID is used or not. Unlike the sequence 2420 number, the epoch is not encrypted because it acts as a key 2421 identifier, which may improve correlation of packets from a single 2422 connection across different network paths. 2424 * DTLS 1.3 encrypts handshake messages much earlier than in previous 2425 DTLS versions. Therefore, less information identifying the DTLS 2426 client, such as the client certificate, is available to an on-path 2427 adversary. 2429 12. Changes since DTLS 1.2 2431 Since TLS 1.3 introduces a large number of changes with respect to 2432 TLS 1.2, the list of changes from DTLS 1.2 to DTLS 1.3 is equally 2433 large. For this reason this section focuses on the most important 2434 changes only. 2436 * New handshake pattern, which leads to a shorter message exchange 2438 * Only AEAD ciphers are supported. Additional data calculation has 2439 been simplified. 2441 * Removed support for weaker and older cryptographic algorithms 2443 * HelloRetryRequest of TLS 1.3 used instead of HelloVerifyRequest 2445 * More flexible ciphersuite negotiation 2447 * New session resumption mechanism 2448 * PSK authentication redefined 2450 * New key derivation hierarchy utilizing a new key derivation 2451 construct 2453 * Improved version negotiation 2455 * Optimized record layer encoding and thereby its size 2457 * Added CID functionality 2459 * Sequence numbers are encrypted. 2461 13. Updates affecting DTLS 1.2 2463 This document defines several changes that optionally affect 2464 implementations of DTLS 1.2, including those which do not also 2465 support DTLS 1.3. 2467 * A version downgrade protection mechanism as described in [TLS13]; 2468 Section 4.1.3 and applying to DTLS as described in Section 5.3. 2470 * The updates described in [TLS13]; Section 3. 2472 * The new compliance requirements described in [TLS13]; Section 9.3. 2474 14. IANA Considerations 2476 IANA is requested to allocate a new value in the "TLS ContentType" 2477 registry for the ACK message, defined in Section 7, with content type 2478 26. The value for the "DTLS-OK" column is "Y". IANA is requested to 2479 reserve the content type range 32-63 so that content types in this 2480 range are not allocated. 2482 IANA is requested to allocate "the too_many_cids_requested" alert in 2483 the "TLS Alerts" registry with value 52. 2485 IANA is requested to allocate two values in the "TLS Handshake Type" 2486 registry, defined in [TLS13], for RequestConnectionId (TBD), and 2487 NewConnectionId (TBD), as defined in this document. The value for 2488 the "DTLS-OK" columns are "Y". 2490 IANA is requested to add this RFC as a reference to the TLS Cipher 2491 Suite Registry along with the following Note: 2493 Any TLS cipher suite that is specified for use with DTLS MUST 2494 define limits on the use of the associated AEAD function that 2495 preserves margins for both confidentiality and integrity, 2496 as specified in [THIS RFC; Section TODO] 2498 15. References 2500 15.1. Normative References 2502 [CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 2503 Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, 2504 . 2506 [I-D.ietf-tls-dtls-connection-id] 2507 Rescorla, E., Tschofenig, H., Fossati, T., and A. Kraus, 2508 "Connection Identifiers for DTLS 1.2", Work in Progress, 2509 Internet-Draft, draft-ietf-tls-dtls-connection-id-11, 14 2510 April 2021, . 2513 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2514 DOI 10.17487/RFC0768, August 1980, 2515 . 2517 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2518 RFC 793, DOI 10.17487/RFC0793, September 1981, 2519 . 2521 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2522 DOI 10.17487/RFC1191, November 1990, 2523 . 2525 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2526 Requirement Levels", BCP 14, RFC 2119, 2527 DOI 10.17487/RFC2119, March 1997, 2528 . 2530 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2531 Control Message Protocol (ICMPv6) for the Internet 2532 Protocol Version 6 (IPv6) Specification", STD 89, 2533 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2534 . 2536 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 2537 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 2538 . 2540 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 2541 "Computing TCP's Retransmission Timer", RFC 6298, 2542 DOI 10.17487/RFC6298, June 2011, 2543 . 2545 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2546 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2547 May 2017, . 2549 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2550 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2551 . 2553 15.2. Informative References 2555 [AEBounds] Luykx, A. and K. Paterson, "Limits on Authenticated 2556 Encryption Use in TLS", 8 March 2016, 2557 . 2559 [CCM-ANALYSIS] 2560 Jonsson, J., "On the Security of CTR + CBC-MAC", Selected 2561 Areas in Cryptography pp. 76-93, 2562 DOI 10.1007/3-540-36492-7_7, 2003, 2563 . 2565 [DEPRECATE] 2566 Moriarty, K. and S. Farrell, "Deprecating TLSv1.0 and 2567 TLSv1.1", Work in Progress, Internet-Draft, draft-ietf- 2568 tls-oldversions-deprecate-12, 21 January 2021, 2569 . 2572 [I-D.ietf-quic-recovery] 2573 Iyengar, J. and I. Swett, "QUIC Loss Detection and 2574 Congestion Control", Work in Progress, Internet-Draft, 2575 draft-ietf-quic-recovery-34, 14 January 2021, 2576 . 2579 [I-D.ietf-tls-esni] 2580 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS 2581 Encrypted Client Hello", Work in Progress, Internet-Draft, 2582 draft-ietf-tls-esni-10, 8 March 2021, 2583 . 2586 [I-D.ietf-uta-tls13-iot-profile] 2587 Tschofenig, H. and T. Fossati, "TLS/DTLS 1.3 Profiles for 2588 the Internet of Things", Work in Progress, Internet-Draft, 2589 draft-ietf-uta-tls13-iot-profile-01, 22 February 2021, 2590 . 2593 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 2594 Protocol", RFC 2522, DOI 10.17487/RFC2522, March 1999, 2595 . 2597 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 2598 RFC 4303, DOI 10.17487/RFC4303, December 2005, 2599 . 2601 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2602 Congestion Control Protocol (DCCP)", RFC 4340, 2603 DOI 10.17487/RFC4340, March 2006, 2604 . 2606 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 2607 (TLS) Protocol Version 1.1", RFC 4346, 2608 DOI 10.17487/RFC4346, April 2006, 2609 . 2611 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2612 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 2613 . 2615 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 2616 RFC 4960, DOI 10.17487/RFC4960, September 2007, 2617 . 2619 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 2620 the Datagram Congestion Control Protocol (DCCP)", 2621 RFC 5238, DOI 10.17487/RFC5238, May 2008, 2622 . 2624 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2625 (TLS) Protocol Version 1.2", RFC 5246, 2626 DOI 10.17487/RFC5246, August 2008, 2627 . 2629 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 2630 for Establishing a Secure Real-time Transport Protocol 2631 (SRTP) Security Context Using Datagram Transport Layer 2632 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2633 2010, . 2635 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 2636 Security (DTLS) Extension to Establish Keys for the Secure 2637 Real-time Transport Protocol (SRTP)", RFC 5764, 2638 DOI 10.17487/RFC5764, May 2010, 2639 . 2641 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 2642 Extensions: Extension Definitions", RFC 6066, 2643 DOI 10.17487/RFC6066, January 2011, 2644 . 2646 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2647 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2648 January 2012, . 2650 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 2651 Kivinen, "Internet Key Exchange Protocol Version 2 2652 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2653 2014, . 2655 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2656 "Recommendations for Secure Use of Transport Layer 2657 Security (TLS) and Datagram Transport Layer Security 2658 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2659 2015, . 2661 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 2662 (TLS) Cached Information Extension", RFC 7924, 2663 DOI 10.17487/RFC7924, July 2016, 2664 . 2666 [RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme 2667 Updates for Secure Real-time Transport Protocol (SRTP) 2668 Extension for Datagram Transport Layer Security (DTLS)", 2669 RFC 7983, DOI 10.17487/RFC7983, September 2016, 2670 . 2672 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 2673 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 2674 DOI 10.17487/RFC8201, July 2017, 2675 . 2677 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 2678 Connectivity Establishment (ICE): A Protocol for Network 2679 Address Translator (NAT) Traversal", RFC 8445, 2680 DOI 10.17487/RFC8445, July 2018, 2681 . 2683 [RFC8879] Ghedini, A. and V. Vasiliev, "TLS Certificate 2684 Compression", RFC 8879, DOI 10.17487/RFC8879, December 2685 2020, . 2687 [ROBUST] Fischlin, M., Günther, F., and C. Janson, "Robust 2688 Channels: Handling Unreliable Networks in the Record 2689 Layers of QUIC and DTLS 1.3", 15 June 2020, 2690 . 2692 Appendix A. Protocol Data Structures and Constant Values 2694 This section provides the normative protocol types and constants 2695 definitions. 2697 A.1. Record Layer 2698 struct { 2699 ContentType type; 2700 ProtocolVersion legacy_record_version; 2701 uint16 epoch = 0 2702 uint48 sequence_number; 2703 uint16 length; 2704 opaque fragment[DTLSPlaintext.length]; 2705 } DTLSPlaintext; 2707 struct { 2708 opaque content[DTLSPlaintext.length]; 2709 ContentType type; 2710 uint8 zeros[length_of_padding]; 2711 } DTLSInnerPlaintext; 2713 struct { 2714 opaque unified_hdr[variable]; 2715 opaque encrypted_record[length]; 2716 } DTLSCiphertext; 2718 0 1 2 3 4 5 6 7 2719 +-+-+-+-+-+-+-+-+ 2720 |0|0|1|C|S|L|E E| 2721 +-+-+-+-+-+-+-+-+ 2722 | Connection ID | Legend: 2723 | (if any, | 2724 / length as / C - Connection ID (CID) present 2725 | negotiated) | S - Sequence number length 2726 +-+-+-+-+-+-+-+-+ L - Length present 2727 | 8 or 16 bit | E - Epoch 2728 |Sequence Number| 2729 +-+-+-+-+-+-+-+-+ 2730 | 16 bit Length | 2731 | (if present) | 2732 +-+-+-+-+-+-+-+-+ 2734 struct { 2735 uint16 epoch; 2736 uint48 sequence_number; 2737 } RecordNumber; 2739 A.2. Handshake Protocol 2740 enum { 2741 hello_request_RESERVED(0), 2742 client_hello(1), 2743 server_hello(2), 2744 hello_verify_request_RESERVED(3), 2745 new_session_ticket(4), 2746 end_of_early_data(5), 2747 hello_retry_request_RESERVED(6), 2748 encrypted_extensions(8), 2749 certificate(11), 2750 server_key_exchange_RESERVED(12), 2751 certificate_request(13), 2752 server_hello_done_RESERVED(14), 2753 certificate_verify(15), 2754 client_key_exchange_RESERVED(16), 2755 finished(20), 2756 certificate_url_RESERVED(21), 2757 certificate_status_RESERVED(22), 2758 supplemental_data_RESERVED(23), 2759 key_update(24), 2760 message_hash(254), 2761 (255) 2762 } HandshakeType; 2764 struct { 2765 HandshakeType msg_type; /* handshake type */ 2766 uint24 length; /* bytes in message */ 2767 uint16 message_seq; /* DTLS-required field */ 2768 uint24 fragment_offset; /* DTLS-required field */ 2769 uint24 fragment_length; /* DTLS-required field */ 2770 select (msg_type) { 2771 case client_hello: ClientHello; 2772 case server_hello: ServerHello; 2773 case end_of_early_data: EndOfEarlyData; 2774 case encrypted_extensions: EncryptedExtensions; 2775 case certificate_request: CertificateRequest; 2776 case certificate: Certificate; 2777 case certificate_verify: CertificateVerify; 2778 case finished: Finished; 2779 case new_session_ticket: NewSessionTicket; 2780 case key_update: KeyUpdate; 2781 } body; 2782 } Handshake; 2784 uint16 ProtocolVersion; 2785 opaque Random[32]; 2787 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 2788 struct { 2789 ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2 2790 Random random; 2791 opaque legacy_session_id<0..32>; 2792 opaque legacy_cookie<0..2^8-1>; // DTLS 2793 CipherSuite cipher_suites<2..2^16-2>; 2794 opaque legacy_compression_methods<1..2^8-1>; 2795 Extension extensions<8..2^16-1>; 2796 } ClientHello; 2798 A.3. ACKs 2800 struct { 2801 RecordNumber record_numbers<0..2^16-1>; 2802 } ACK; 2804 A.4. Connection ID Management 2806 enum { 2807 cid_immediate(0), cid_spare(1), (255) 2808 } ConnectionIdUsage; 2810 opaque ConnectionId<0..2^8-1>; 2812 struct { 2813 ConnectionIds cids<0..2^16-1>; 2814 ConnectionIdUsage usage; 2815 } NewConnectionId; 2817 struct { 2818 uint8 num_cids; 2819 } RequestConnectionId; 2821 Appendix B. Analysis of Limits on CCM Usage 2823 TLS [TLS13] and [AEBounds] do not specify limits on key usage for 2824 AEAD_AES_128_CCM. However, any AEAD that is used with DTLS requires 2825 limits on use that ensure that both confidentiality and integrity are 2826 preserved. This section documents that analysis for 2827 AEAD_AES_128_CCM. 2829 [CCM-ANALYSIS] is used as the basis of this analysis. The results of 2830 that analysis are used to derive usage limits that are based on those 2831 chosen in [TLS13]. 2833 This analysis uses symbols for multiplication (*), division (/), and 2834 exponentiation (^), plus parentheses for establishing precedence. 2835 The following symbols are also used: 2837 t: The size of the authentication tag in bits. For this cipher, t 2838 is 128. 2840 n: The size of the block function in bits. For this cipher, n is 2841 128. 2843 l: The number of blocks in each packet (see below). 2845 q: The number of genuine packets created and protected by endpoints. 2846 This value is the bound on the number of packets that can be 2847 protected before updating keys. 2849 v: The number of forged packets that endpoints will accept. This 2850 value is the bound on the number of forged packets that an 2851 endpoint can reject before updating keys. 2853 The analysis of AEAD_AES_128_CCM relies on a count of the number of 2854 block operations involved in producing each message. For simplicity, 2855 and to match the analysis of other AEAD functions in [AEBounds], this 2856 analysis assumes a packet length of 2^10 blocks and a packet size 2857 limit of 2^14 bytes. 2859 For AEAD_AES_128_CCM, the total number of block cipher operations is 2860 the sum of: the length of the associated data in blocks, the length 2861 of the ciphertext in blocks, and the length of the plaintext in 2862 blocks, plus 1. In this analysis, this is simplified to a value of 2863 twice the maximum length of a record in blocks (that is, "2l = 2864 2^11"). This simplification is based on the associated data being 2865 limited to one block. 2867 B.1. Confidentiality Limits 2869 For confidentiality, Theorem 2 in [CCM-ANALYSIS] establishes that an 2870 attacker gains a distinguishing advantage over an ideal pseudorandom 2871 permutation (PRP) of no more than: 2873 (2l * q)^2 / 2^n 2875 For a target advantage of 2^-60, which matches that used by [TLS13], 2876 this results in the relation: 2878 q <= 2^23 2880 That is, endpoints cannot protect more than 2^23 packets with the 2881 same set of keys without causing an attacker to gain an larger 2882 advantage than the target of 2^-60. 2884 B.2. Integrity Limits 2886 For integrity, Theorem 1 in [CCM-ANALYSIS] establishes that an 2887 attacker gains an advantage over an ideal PRP of no more than: 2889 v / 2^t + (2l * (v + q))^2 / 2^n 2891 The goal is to limit this advantage to 2^-57, to match the target in 2892 [TLS13]. As "t" and "n" are both 128, the first term is negligible 2893 relative to the second, so that term can be removed without a 2894 significant effect on the result. This produces the relation: 2896 v + q <= 2^24.5 2898 Using the previously-established value of 2^23 for "q" and rounding, 2899 this leads to an upper limit on "v" of 2^23.5. That is, endpoints 2900 cannot attempt to authenticate more than 2^23.5 packets with the same 2901 set of keys without causing an attacker to gain an larger advantage 2902 than the target of 2^-57. 2904 B.3. Limits for AEAD_AES_128_CCM_8 2906 The TLS_AES_128_CCM_8_SHA256 cipher suite uses the AEAD_AES_128_CCM_8 2907 function, which uses a short authentication tag (that is, t=64). 2909 The confidentiality limits of AEAD_AES_128_CCM_8 are the same as 2910 those for AEAD_AES_128_CCM, as this does not depend on the tag 2911 length; see Appendix B.1. 2913 The shorter tag length of 64 bits means that the simplification used 2914 in Appendix B.2 does not apply to AEAD_AES_128_CCM_8. If the goal is 2915 to preserve the same margins as other cipher suites, then the limit 2916 on forgeries is largely dictated by the first term of the advantage 2917 formula: 2919 v <= 2^7 2921 As this represents attempts to fail authentication, applying this 2922 limit might be feasible in some environments. However, applying this 2923 limit in an implementation intended for general use exposes 2924 connections to an inexpensive denial of service attack. 2926 This analysis supports the view that TLS_AES_128_CCM_8_SHA256 is not 2927 suitable for general use. Specifically, TLS_AES_128_CCM_8_SHA256 2928 cannot be used without additional measures to prevent forgery of 2929 records, or to mitigate the effect of forgeries. This might require 2930 understanding the constraints that exist in a particular deployment 2931 or application. For instance, it might be possible to set a 2932 different target for the advantage an attacker gains based on an 2933 understanding of the constraints imposed on a specific usage of DTLS. 2935 Appendix C. Implementation Pitfalls 2937 In addition to the aspects of TLS that have been a source of 2938 interoperability and security problems (Section C.3 of [TLS13]), DTLS 2939 presents a few new potential sources of issues, noted here. 2941 * Do you correctly handle messages received from multiple epochs 2942 during a key transition? This includes locating the correct key 2943 as well as performing replay detection, if enabled. 2945 * Do you retransmit handshake messages that are not (implicitly or 2946 explicitly) acknowledged (Section 5.8)? 2948 * Do you correctly handle handshake message fragments received, 2949 including when they are out of order? 2951 * Do you correctly handle handshake messages received out of order? 2952 This may include either buffering or discarding them. 2954 * Do you limit how much data you send to a peer before its address 2955 is validated? 2957 * Do you verify that the explicit record length is contained within 2958 the datagram in which it is contained? 2960 Appendix D. History 2962 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 2964 (*) indicates a change that may affect interoperability. 2966 IETF Drafts draft-42 2968 * SHOULD level requirement for the client to offer CID extension. 2970 * Change the default retransmission timer to 1s and allow people to 2971 do otherwise if they have side knowledge. 2973 * Cap any given flight to 10 records 2974 * Don't re-set the timer to the initial value but to 1.5 times the 2975 measured RTT. 2977 * A bunch more clarity about the reliability algorithms and timers 2978 (including changing reset to re-arm) 2980 * Update IANA considerations 2982 draft-40 2984 - Clarified encrypted_record structure in DTLS 1.3 record layer 2985 - Added description of the demultiplexing process 2986 - Added text about the DTLS 1.2 and DTLS 1.3 CID mechanism 2987 - Forbid going from an empty CID to a non-empty CID (*) 2988 - Add warning about certificates and congestion 2989 - Use DTLS style version values, even for DTLS 1.3 (*) 2990 - Describe how to distinguish DTLS 1.2 and DTLS 1.3 connections 2991 - Updated examples 2992 - Included editorial improvements from Ben Kaduk 2993 - Removed stale text about out-of-epoch records 2994 - Added clarifications around when ACKs are sent 2995 - Noted that alerts are unreliable 2996 - Clarify when you can reset the timer 2997 - Indicated that records with bogus epochs should be discarded 2998 - Relax age out text 2999 - Updates to cookie text 3000 - Require that cipher suites define a record number encryption algorithm 3001 - Clean up use of connection and association 3002 - Reference tls-old-versions-deprecate 3004 draft-39 - Updated Figure 4 due to misalignment with Figure 3 content 3006 draft-38 - Ban implicit Connection IDs (*) - ACKs are processed as 3007 the union. 3009 draft-37: - Fix the other place where we have ACK. 3011 draft-36: - Some editorial changes. - Changed the content type to not 3012 conflict with existing allocations (*) 3014 draft-35: - I-D.ietf-tls-dtls-connection-id became a normative 3015 reference - Removed duplicate reference to I-D.ietf-tls-dtls- 3016 connection-id. - Fix figure 11 to have the right numbers andno cookie 3017 in message 1. - Clarify when you can ACK. - Clarify additional data 3018 computation. 3020 draft-33: - Key separation between TLS and DTLS. Issue #72. 3022 draft-32: - Editorial improvements and clarifications. 3024 draft-31: - Editorial improvements in text and figures. - Added 3025 normative reference to ChaCha20 and Poly1305. 3027 draft-30: - Changed record format - Added text about end of early 3028 data - Changed format of the Connection ID Update message - Added 3029 Appendix A "Protocol Data Structures and Constant Values" 3031 draft-29: - Added support for sequence number encryption - Update to 3032 new record format - Emphasize that compatibility mode isn't used. 3034 draft-28: - Version bump to align with TLS 1.3 pre-RFC version. 3036 draft-27: - Incorporated unified header format. - Added support for 3037 CIDs. 3039 draft-04 - 26: - Submissions to align with TLS 1.3 draft versions 3041 draft-03 - Only update keys after KeyUpdate is ACKed. 3043 draft-02 - Shorten the protected record header and introduce an 3044 ultra-short version of the record header. - Reintroduce KeyUpdate, 3045 which works properly now that we have ACK. - Clarify the ACK rules. 3047 draft-01 - Restructured the ACK to contain a list of records and also 3048 be a record rather than a handshake message. 3050 draft-00 - First IETF Draft 3052 Personal Drafts draft-01 - Alignment with version -19 of the TLS 1.3 3053 specification 3055 draft-00 3057 * Initial version using TLS 1.3 as a baseline. 3059 * Use of epoch values instead of KeyUpdate message 3061 * Use of cookie extension instead of cookie field in ClientHello and 3062 HelloVerifyRequest messages 3064 * Added ACK message 3066 * Text about sequence number handling 3068 Appendix E. Working Group Information 3070 RFC EDITOR: PLEASE REMOVE THIS SECTION. 3072 The discussion list for the IETF TLS working group is located at the 3073 e-mail address tls@ietf.org (mailto:tls@ietf.org). Information on 3074 the group and information on how to subscribe to the list is at 3075 https://www1.ietf.org/mailman/listinfo/tls 3076 (https://www1.ietf.org/mailman/listinfo/tls) 3078 Archives of the list can be found at: https://www.ietf.org/mail- 3079 archive/web/tls/current/index.html (https://www.ietf.org/mail- 3080 archive/web/tls/current/index.html) 3082 Appendix F. Contributors 3084 Many people have contributed to previous DTLS versions and they are 3085 acknowledged in prior versions of DTLS specifications or in the 3086 referenced specifications. The sequence number encryption concept is 3087 taken from the QUIC specification. We would like to thank the 3088 authors of the QUIC specification for their work. Felix Guenther and 3089 Martin Thomson contributed the analysis in Appendix B. 3091 In addition, we would like to thank: 3093 * David Benjamin 3094 Google 3095 davidben@google.com 3097 * Thomas Fossati 3098 Arm Limited 3099 Thomas.Fossati@arm.com 3101 * Tobias Gondrom 3102 Huawei 3103 tobias.gondrom@gondrom.org 3105 * Felix Günther 3106 ETH Zurich 3107 mail@felixguenther.info 3109 * Benjamin Kaduk 3110 Akamai Technologies 3111 kaduk@mit.edu 3113 * Ilari Liusvaara 3114 Independent 3115 ilariliusvaara@welho.com 3117 * Martin Thomson 3118 Mozilla 3119 martin.thomson@gmail.com 3121 * Christopher A. Wood 3122 Apple Inc. 3123 cawood@apple.com 3125 * Yin Xinxing 3126 Huawei 3127 yinxinxing@huawei.com 3129 * Hanno Becker 3130 Arm Limited 3131 Hanno.Becker@arm.com 3133 Appendix G. Acknowledgements 3135 We would like to thank Jonathan Hammell, Bernard Aboba and Andy 3136 Cunningham for their review comments. 3138 Additionally, we would like to thank the IESG members for their 3139 review comments: Martin Duke, Erik Kline, Francesca Palombini, Lars 3140 Eggert, Zaheduzzaman Sarker, John Scudder, Eric Vyncke, Robert 3141 Wilton, Roman Danyliw, Benjamin Kaduk, Murray Kucherawy, Martin 3142 Vigoureux, and Alvaro Retana 3144 Authors' Addresses 3146 Eric Rescorla 3147 RTFM, Inc. 3149 Email: ekr@rtfm.com 3151 Hannes Tschofenig 3152 Arm Limited 3154 Email: hannes.tschofenig@arm.com 3156 Nagendra Modadugu 3157 Google, Inc. 3159 Email: nagendra@cs.stanford.edu