idnits 2.17.1 draft-ietf-tls-dtls13-40.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. -- The draft header indicates that this document obsoletes RFC6347, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (20 January 2021) is 1164 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 2592 -- Looks like a reference, but probably isn't: '2' on line 2593 == Missing Reference: 'ACK' is mentioned on line 1861, but not defined == Missing Reference: 'NewSessionTicket' is mentioned on line 1858, but not defined == Missing Reference: 'KeyUpdate' is mentioned on line 2090, but not defined == Missing Reference: 'Ack' is mentioned on line 2093, 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-09 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-12) exists of draft-ietf-tls-oldversions-deprecate-11 -- 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 (~~), 9 warnings (==), 11 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: 24 July 2021 N. Modadugu 7 Google, Inc. 8 20 January 2021 10 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 11 draft-ietf-tls-dtls13-40 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 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 24 July 2021. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 73 3. DTLS Design Rationale and Overview . . . . . . . . . . . . . 6 74 3.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 6 75 3.2. Reordering . . . . . . . . . . . . . . . . . . . . . . . 7 76 3.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 7 77 3.4. Replay Detection . . . . . . . . . . . . . . . . . . . . 8 78 4. The DTLS Record Layer . . . . . . . . . . . . . . . . . . . . 8 79 4.1. Demultiplexing DTLS Records . . . . . . . . . . . . . . . 12 80 4.2. Sequence Number and Epoch . . . . . . . . . . . . . . . . 13 81 4.2.1. Processing Guidelines . . . . . . . . . . . . . . . . 14 82 4.2.2. Reconstructing the Sequence Number and Epoch . . . . 14 83 4.2.3. Record Number Encryption . . . . . . . . . . . . . . 15 84 4.3. Transport Layer Mapping . . . . . . . . . . . . . . . . . 16 85 4.4. PMTU Issues . . . . . . . . . . . . . . . . . . . . . . . 17 86 4.5. Record Payload Protection . . . . . . . . . . . . . . . . 18 87 4.5.1. Anti-Replay . . . . . . . . . . . . . . . . . . . . . 18 88 4.5.2. Handling Invalid Records . . . . . . . . . . . . . . 19 89 4.5.3. AEAD Limits . . . . . . . . . . . . . . . . . . . . . 20 90 5. The DTLS Handshake Protocol . . . . . . . . . . . . . . . . . 21 91 5.1. Denial-of-Service Countermeasures . . . . . . . . . . . . 22 92 5.2. DTLS Handshake Message Format . . . . . . . . . . . . . . 24 93 5.3. ClientHello Message . . . . . . . . . . . . . . . . . . . 26 94 5.4. ServerHello Message . . . . . . . . . . . . . . . . . . . 27 95 5.5. Handshake Message Fragmentation and Reassembly . . . . . 27 96 5.6. End Of Early Data . . . . . . . . . . . . . . . . . . . . 28 97 5.7. DTLS Handshake Flights . . . . . . . . . . . . . . . . . 29 98 5.8. Timeout and Retransmission . . . . . . . . . . . . . . . 33 99 5.8.1. State Machine . . . . . . . . . . . . . . . . . . . . 33 100 5.8.2. Timer Values . . . . . . . . . . . . . . . . . . . . 36 101 5.8.3. Large Flight Sizes . . . . . . . . . . . . . . . . . 37 102 5.8.4. State machine duplication for post-handshake 103 messages . . . . . . . . . . . . . . . . . . . . . . 37 104 5.9. CertificateVerify and Finished Messages . . . . . . . . . 38 105 5.10. Cryptographic Label Prefix . . . . . . . . . . . . . . . 38 106 5.11. Alert Messages . . . . . . . . . . . . . . . . . . . . . 38 107 5.12. Establishing New Associations with Existing Parameters . 39 108 6. Example of Handshake with Timeout and Retransmission . . . . 39 109 6.1. Epoch Values and Rekeying . . . . . . . . . . . . . . . . 41 110 7. ACK Message . . . . . . . . . . . . . . . . . . . . . . . . . 43 111 7.1. Sending ACKs . . . . . . . . . . . . . . . . . . . . . . 44 112 7.2. Receiving ACKs . . . . . . . . . . . . . . . . . . . . . 45 113 7.3. Design Rationale . . . . . . . . . . . . . . . . . . . . 46 114 8. Key Updates . . . . . . . . . . . . . . . . . . . . . . . . . 46 115 9. Connection ID Updates . . . . . . . . . . . . . . . . . . . . 48 116 9.1. Connection ID Example . . . . . . . . . . . . . . . . . . 49 117 10. Application Data Protocol . . . . . . . . . . . . . . . . . . 51 118 11. Security Considerations . . . . . . . . . . . . . . . . . . . 51 119 12. Changes since DTLS 1.2 . . . . . . . . . . . . . . . . . . . 52 120 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 121 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 122 14.1. Normative References . . . . . . . . . . . . . . . . . . 53 123 14.2. Informative References . . . . . . . . . . . . . . . . . 55 124 Appendix A. Protocol Data Structures and Constant Values . . . . 57 125 A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 57 126 A.2. Handshake Protocol . . . . . . . . . . . . . . . . . . . 58 127 A.3. ACKs . . . . . . . . . . . . . . . . . . . . . . . . . . 59 128 A.4. Connection ID Management . . . . . . . . . . . . . . . . 59 129 Appendix B. Analysis of Limits on CCM Usage . . . . . . . . . . 59 130 B.1. Confidentiality Limits . . . . . . . . . . . . . . . . . 60 131 B.2. Integrity Limits . . . . . . . . . . . . . . . . . . . . 61 132 B.3. Limits for AEAD_AES_128_CCM_8 . . . . . . . . . . . . . . 61 133 Appendix C. History . . . . . . . . . . . . . . . . . . . . . . 62 134 Appendix D. Working Group Information . . . . . . . . . . . . . 64 135 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 64 136 Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 65 137 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65 139 1. Introduction 141 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH 142 The source for this draft is maintained in GitHub. Suggested changes 143 should be submitted as pull requests at https://github.com/tlswg/ 144 dtls13-spec. Instructions are on that page as well. Editorial 145 changes can be managed in GitHub, but any substantive change should 146 be discussed on the TLS mailing list. 148 The primary goal of the TLS protocol is to establish an 149 authenticated, confidentiality and integrity protected channel 150 between two communicating peers. The TLS protocol is composed of two 151 layers: the TLS Record Protocol and the TLS Handshake Protocol. 152 However, TLS must run over a reliable transport channel - typically 153 TCP [RFC0793]. 155 There are applications that use UDP [RFC0768] as a transport and to 156 offer communication security protection for those applications the 157 Datagram Transport Layer Security (DTLS) protocol has been developed. 158 DTLS is deliberately designed to be as similar to TLS as possible, 159 both to minimize new security invention and to maximize the amount of 160 code and infrastructure reuse. 162 DTLS 1.0 [RFC4347] was originally defined as a delta from TLS 1.1 163 [RFC4346] and DTLS 1.2 [RFC6347] was defined as a series of deltas to 164 TLS 1.2 [RFC5246]. There is no DTLS 1.1; that version number was 165 skipped in order to harmonize version numbers with TLS. This 166 specification describes the most current version of the DTLS protocol 167 based on TLS 1.3 [TLS13]. 169 Implementations that speak both DTLS 1.2 and DTLS 1.3 can 170 interoperate with those that speak only DTLS 1.2 (using DTLS 1.2 of 171 course), just as TLS 1.3 implementations can interoperate with TLS 172 1.2 (see Appendix D of [TLS13] for details). While backwards 173 compatibility with DTLS 1.0 is possible the use of DTLS 1.0 is not 174 recommended as explained in Section 3.1.2 of RFC 7525 [RFC7525] and 175 [DEPRECATE]. 177 2. Conventions and Terminology 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 181 "OPTIONAL" in this document are to be interpreted as described in BCP 182 14 [RFC2119] [RFC8174] when, and only when, they appear in all 183 capitals, as shown here. 185 The following terms are used: 187 * client: The endpoint initiating the DTLS connection. 189 * association: Shared state between two endpoints established with a 190 DTLS handshake. 192 * connection: Synonym for association. 194 * endpoint: Either the client or server of the connection. 196 * handshake: An initial negotiation between client and server that 197 establishes the parameters of the connection. 199 * peer: An endpoint. When discussing a particular endpoint, "peer" 200 refers to the endpoint that is remote to the primary subject of 201 discussion. 203 * receiver: An endpoint that is receiving records. 205 * sender: An endpoint that is transmitting records. 207 * server: The endpoint which did not initiate the DTLS connection. 209 * CID: Connection ID 211 * MSL: Maximum Segment Lifetime 213 The reader is assumed to be familiar with the TLS 1.3 specification 214 since this document is defined as a delta from TLS 1.3. As in TLS 215 1.3 the HelloRetryRequest has the same format as a ServerHello 216 message but for convenience we use the term HelloRetryRequest 217 throughout this document as if it were a distinct message. 219 The reader is also as to be familiar with 220 [I-D.ietf-tls-dtls-connection-id] as this document applies the CID 221 functionality to DTLS 1.3. 223 Figures in this document illustrate various combinations of the DTLS 224 protocol exchanges and the symbols have the following meaning: 226 * '+' indicates noteworthy extensions sent in the previously noted 227 message. 229 * '*' indicates optional or situation-dependent messages/extensions 230 that are not always sent. 232 * '{}' indicates messages protected using keys derived from a 233 [sender]_handshake_traffic_secret. 235 * '[]' indicates messages protected using keys derived from 236 traffic_secret_N. 238 3. DTLS Design Rationale and Overview 240 The basic design philosophy of DTLS is to construct "TLS over 241 datagram transport". Datagram transport does not require nor provide 242 reliable or in-order delivery of data. The DTLS protocol preserves 243 this property for application data. Applications such as media 244 streaming, Internet telephony, and online gaming use datagram 245 transport for communication due to the delay-sensitive nature of 246 transported data. The behavior of such applications is unchanged 247 when the DTLS protocol is used to secure communication, since the 248 DTLS protocol does not compensate for lost or reordered data traffic. 250 TLS cannot be used directly in datagram environments for the 251 following five reasons: 253 1. TLS relies on an implicit sequence number on records. If a 254 record is not received, then the recipient will use the wrong 255 sequence number when attempting to remove record protection from 256 subsequent records. DTLS solves this problem by adding sequence 257 numbers to records. 259 2. The TLS handshake is a lock-step cryptographic protocol. 260 Messages must be transmitted and received in a defined order; any 261 other order is an error. The DTLS handshake includes message 262 sequence numbers to enable reassembly in the correct order in 263 case datagrams are lost or reordered. 265 3. During the handshake, messages are implicitly acknowledged by 266 other handshake messages. Some handshake messages, such as the 267 NewSessionTicket message, do not result in any direct response 268 that would allow the sender to detect loss. DTLS adds an 269 acknowledgment message to enable better loss recovery. 271 4. Handshake messages are potentially larger than can be contained 272 in a single datagram. DTLS adds fields to handshake messages to 273 support fragmentation and reassembly. 275 5. Datagram transport protocols, like UDP, are susceptible to 276 abusive behavior effecting denial of service attacks against 277 nonparticipants. DTLS adds a return-routability check and DTLS 278 1.3 uses the TLS 1.3 HelloRetryRequest message (see Section 5.1 279 for details). 281 3.1. Packet Loss 283 DTLS uses a simple retransmission timer to handle packet loss. 284 Figure 1 demonstrates the basic concept, using the first phase of the 285 DTLS handshake: 287 Client Server 288 ------ ------ 289 ClientHello ------> 291 X<-- HelloRetryRequest 292 (lost) 294 [Timer Expires] 296 ClientHello ------> 297 (retransmit) 299 Figure 1: DTLS retransmission example 301 Once the client has transmitted the ClientHello message, it expects 302 to see a HelloRetryRequest or a ServerHello from the server. 303 However, if the server's message is lost, the client knows that 304 either the ClientHello or the response from the server has been lost 305 and retransmits. When the server receives the retransmission, it 306 knows to retransmit. 308 The server also maintains a retransmission timer and retransmits when 309 that timer expires. 311 Note that timeout and retransmission do not apply to the 312 HelloRetryRequest since this would require creating state on the 313 server. The HelloRetryRequest is designed to be small enough that it 314 will not itself be fragmented, thus avoiding concerns about 315 interleaving multiple HelloRetryRequests. 317 3.2. Reordering 319 In DTLS, each handshake message is assigned a specific sequence 320 number. When a peer receives a handshake message, it can quickly 321 determine whether that message is the next message it expects. If it 322 is, then it processes it. If not, it queues it for future handling 323 once all previous messages have been received. 325 3.3. Fragmentation 327 TLS and DTLS handshake messages can be quite large (in theory up to 328 2^24-1 bytes, in practice many kilobytes). By contrast, UDP 329 datagrams are often limited to less than 1500 bytes if IP 330 fragmentation is not desired. In order to compensate for this 331 limitation, each DTLS handshake message may be fragmented over 332 several DTLS records, each of which is intended to fit in a single 333 UDP datagram. Each DTLS handshake message contains both a fragment 334 offset and a fragment length. Thus, a recipient in possession of all 335 bytes of a handshake message can reassemble the original unfragmented 336 message. 338 3.4. Replay Detection 340 DTLS optionally supports record replay detection. The technique used 341 is the same as in IPsec AH/ESP, by maintaining a bitmap window of 342 received records. Records that are too old to fit in the window and 343 records that have previously been received are silently discarded. 344 The replay detection feature is optional, since packet duplication is 345 not always malicious, but can also occur due to routing errors. 346 Applications may conceivably detect duplicate packets and accordingly 347 modify their data transmission strategy. 349 4. The DTLS Record Layer 351 The DTLS 1.3 record layer is different from the TLS 1.3 record layer 352 and also different from the DTLS 1.2 record layer. 354 1. The DTLSCiphertext structure omits the superfluous version number 355 and type fields. 357 2. DTLS adds an epoch and sequence number to the TLS record header. 358 This sequence number allows the recipient to correctly verify the 359 DTLS MAC. However, the number of bits used for the epoch and 360 sequence number fields in the DTLSCiphertext structure have been 361 reduced from those in previous versions. 363 3. The DTLSCiphertext structure has a variable length header. 365 DTLSPlaintext records are used to send unprotected records and 366 DTLSCiphertext records are used to send protected records. 368 The DTLS record formats are shown below. Unless explicitly stated 369 the meaning of the fields is unchanged from previous TLS / DTLS 370 versions. 372 struct { 373 ContentType type; 374 ProtocolVersion legacy_record_version; 375 uint16 epoch = 0 376 uint48 sequence_number; 377 uint16 length; 378 opaque fragment[DTLSPlaintext.length]; 379 } DTLSPlaintext; 381 struct { 382 opaque content[DTLSPlaintext.length]; 383 ContentType type; 384 uint8 zeros[length_of_padding]; 385 } DTLSInnerPlaintext; 387 struct { 388 opaque unified_hdr[variable]; 389 opaque encrypted_record[length]; 390 } DTLSCiphertext; 392 Figure 2: DTLS 1.3 Record Formats 394 legacy_record_version This value MUST be set to {254, 253} for all 395 records other than the initial ClientHello (i.e., one not 396 generated after a HelloRetryRequest), where it may also be {254, 397 254} for compatibility purposes. It MUST be ignored for all 398 purposes. See [TLS13]; Appendix D.1 for the rationale for this. 400 unified_hdr: The unified header (unified_hdr) is a structure of 401 variable length, as shown in Figure 3. 403 encrypted_record: The AEAD-encrypted form of the serialized 404 DTLSInnerPlaintext structure. 406 0 1 2 3 4 5 6 7 407 +-+-+-+-+-+-+-+-+ 408 |0|0|1|C|S|L|E E| 409 +-+-+-+-+-+-+-+-+ 410 | Connection ID | Legend: 411 | (if any, | 412 / length as / C - Connection ID (CID) present 413 | negotiated) | S - Sequence number length 414 +-+-+-+-+-+-+-+-+ L - Length present 415 | 8 or 16 bit | E - Epoch 416 |Sequence Number| 417 +-+-+-+-+-+-+-+-+ 418 | 16 bit Length | 419 | (if present) | 420 +-+-+-+-+-+-+-+-+ 422 Figure 3: DTLS 1.3 Unified Header 424 Fixed Bits: The three high bits of the first byte of the unified 425 header are set to 001. This ensures that the value will fit 426 within the DTLS region when multiplexing is performed as described 427 in [RFC7983]. It also ensures that distinguishing encrypted DTLS 428 1.3 records from encrypted DTLS 1.2 records is possible when they 429 are carried on the same host/port quartet; such multiplexing is 430 only possible when CIDs [I-D.ietf-tls-dtls-connection-id] are in 431 use, in which case DTLS 1.2 records will have the content type 432 tls12_cid (25). 434 C: The C bit (0x10) is set if the Connection ID is present. 436 S: The S bit (0x08) indicates the size of the sequence number. 0 437 means an 8-bit sequence number, 1 means 16-bit. Implementations 438 MAY mix sequence numbers of different lengths on the same 439 connection. 441 L: The L bit (0x04) is set if the length is present. 443 E: The two low bits (0x03) include the low order two bits of the 444 epoch. 446 Connection ID: Variable length CID. The CID functionality is 447 described in [I-D.ietf-tls-dtls-connection-id]. An example can be 448 found in Section 9.1. 450 Sequence Number: The low order 8 or 16 bits of the record sequence 451 number. This value is 16 bits if the S bit is set to 1, and 8 452 bits if the S bit is 0. 454 Length: Identical to the length field in a TLS 1.3 record. 456 As with previous versions of DTLS, multiple DTLSPlaintext and 457 DTLSCiphertext records can be included in the same underlying 458 transport datagram. 460 Figure 4 illustrates different record headers. 462 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 463 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 464 | Content Type | |0|0|1|1|1|1|E E| |0|0|1|0|0|0|E E| 465 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 466 | 16 bit | | | |8-bit Seq. No. | 467 | Version | / Connection ID / +-+-+-+-+-+-+-+-+ 468 +-+-+-+-+-+-+-+-+ | | | | 469 | 16 bit | +-+-+-+-+-+-+-+-+ | Encrypted | 470 | Epoch | | 16 bit | / Record / 471 +-+-+-+-+-+-+-+-+ |Sequence Number| | | 472 | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 473 | | | 16 bit | 474 | 48 bit | | Length | DTLSCiphertext 475 |Sequence Number| +-+-+-+-+-+-+-+-+ Structure 476 | | | | (minimal) 477 | | | Encrypted | 478 +-+-+-+-+-+-+-+-+ / Record / 479 | 16 bit | | | 480 | Length | +-+-+-+-+-+-+-+-+ 481 +-+-+-+-+-+-+-+-+ 482 | | DTLSCiphertext 483 | | Structure 484 / Fragment / (full) 485 | | 486 +-+-+-+-+-+-+-+-+ 488 DTLSPlaintext 489 Structure 491 Figure 4: DTLS 1.3 Header Examples 493 The length field MAY be omitted by clearing the L bit, which means 494 that the record consumes the entire rest of the datagram in the lower 495 level transport. In this case it is not possible to have multiple 496 DTLSCiphertext format records without length fields in the same 497 datagram. Omitting the length field MUST only be used for the last 498 record in a datagram. Implementations MAY mix records with and 499 without length fields on the same connection. 501 If a connection ID is negotiated, then it MUST be contained in all 502 datagrams. Sending implementations MUST NOT mix records from 503 multiple DTLS associations in the same datagram. If the second or 504 later record has a connection ID which does not correspond to the 505 same association used for previous records, the rest of the datagram 506 MUST be discarded. 508 When expanded, the epoch and sequence number can be combined into an 509 unpacked RecordNumber structure, as shown below: 511 struct { 512 uint16 epoch; 513 uint48 sequence_number; 514 } RecordNumber; 516 This 64-bit value is used in the ACK message as well as in the 517 "record_sequence_number" input to the AEAD function. 519 The entire header value shown in Figure 4 (but prior to record number 520 encryption, see Section 4.2.3) is used as as the additional data 521 value for the AEAD function. For instance, if the minimal variant is 522 used, the AAD is 2 octets long. Note that this design is different 523 from the additional data calculation for DTLS 1.2 and for DTLS 1.2 524 with Connection ID. 526 4.1. Demultiplexing DTLS Records 528 DTLS 1.3 uses a variable length record format and hence the 529 demultiplexing process is more complex since more header formats need 530 to be distinguished. Implementations can demultiplex DTLS 1.3 531 records by examining the first byte as follows: 533 * If the first byte is alert(21), handshake(22), or ack(proposed, 534 26), the record MUST be interpreted as a DTLSPlaintext record. 536 * If the first byte is any other value, then receivers MUST check to 537 see if the leading bits of the first byte are 001. If so, the 538 implementation MUST process the record as DTLSCiphertext; the true 539 content type will be inside the protected portion. 541 * Otherwise, the record MUST be rejected as if it had failed 542 deprotection, as described in Section 4.5.2. 544 Figure 5 shows this demultiplexing procedure graphically taking DTLS 545 1.3 and earlier versions of DTLS into account. 547 +----------------+ 548 | Outer Content | 549 | Type (OCT) | 550 | | 551 | OCT == 20 -+--> ChangeCipherSpec (DTLS <1.3) 552 | OCT == 21 -+--> Alert (Plaintext) 553 | OCT == 22 -+--> Handshake (Plaintext) 554 | OCT == 23 -+--> Application Data (DTLS <1.3) 555 | OCT == 24 -+--> Heartbeat (DTLS <1.3) 556 packet --> | OCT == 25 -+--> DTLSCipherText with CID (DTLS 1.2) 557 | OCT == 26 -+--> ACK (DTLS 1.3, Plaintext) 558 | | 559 | | /+----------------+\ 560 | 31 < OCT < 64 -+--> |DTLS Ciphertext | 561 | | |(header bits | 562 | else | | start with 001)| 563 | | | /+-------+--------+\ 564 +-------+--------+ | 565 | | 566 v Decryption | 567 +---------+ +------+ 568 | Reject | | 569 +---------+ v 570 +----------------+ 571 | Decrypted | 572 | Content Type | 573 | (DCT) | 574 | | 575 | DCT == 21 -+--> Alert 576 | DCT == 22 -+--> Handshake 577 | DCT == 23 -+--> Application Data 578 | DCT == 24 -+--> Heartbeat 579 | DCT == 26 -+--> ACK 580 | | 581 +----------------+ 583 Figure 5: Demultiplexing DTLS 1.2 and DTLS 1.3 Records 585 4.2. Sequence Number and Epoch 587 DTLS uses an explicit or partly explicit sequence number, rather than 588 an implicit one, carried in the sequence_number field of the record. 589 Sequence numbers are maintained separately for each epoch, with each 590 sequence_number initially being 0 for each epoch. 592 The epoch number is initially zero and is incremented each time 593 keying material changes and a sender aims to rekey. More details are 594 provided in Section 6.1. 596 4.2.1. Processing Guidelines 598 Because DTLS records could be reordered, a record from epoch M may be 599 received after epoch N (where N > M) has begun. In general, 600 implementations SHOULD discard records from earlier epochs, but if 601 packet loss causes noticeable problems implementations MAY choose to 602 retain keying material from previous epochs for up to the default MSL 603 specified for TCP [RFC0793] to allow for packet reordering. (Note 604 that the intention here is that implementers use the current guidance 605 from the IETF for MSL, as specified in [RFC0793] or successors, not 606 that they attempt to interrogate the MSL that the system TCP stack is 607 using.) 609 Conversely, it is possible for records that are protected with the 610 new epoch to be received prior to the completion of a handshake. For 611 instance, the server may send its Finished message and then start 612 transmitting data. Implementations MAY either buffer or discard such 613 records, though when DTLS is used over reliable transports (e.g., 614 SCTP [RFC4960]), they SHOULD be buffered and processed once the 615 handshake completes. Note that TLS's restrictions on when records 616 may be sent still apply, and the receiver treats the records as if 617 they were sent in the right order. 619 Implementations MUST send retransmissions of lost messages using the 620 same epoch and keying material as the original transmission. 622 Implementations MUST either abandon an association or re-key prior to 623 allowing the sequence number to wrap. 625 Implementations MUST NOT allow the epoch to wrap, but instead MUST 626 establish a new association, terminating the old association. 628 4.2.2. Reconstructing the Sequence Number and Epoch 630 When receiving protected DTLS records, the recipient does not have a 631 full epoch or sequence number value in the record and so there is 632 some opportunity for ambiguity. Because the full epoch and sequence 633 number are used to compute the per-record nonce, failure to 634 reconstruct these values leads to failure to deprotect the record, 635 and so implementations MAY use a mechanism of their choice to 636 determine the full values. This section provides an algorithm which 637 is comparatively simple and which implementations are RECOMMENDED to 638 follow. 640 If the epoch bits match those of the current epoch, then 641 implementations SHOULD reconstruct the sequence number by computing 642 the full sequence number which is numerically closest to one plus the 643 sequence number of the highest successfully deprotected record in the 644 current epoch. 646 During the handshake phase, the epoch bits unambiguously indicate the 647 correct key to use. After the handshake is complete, if the epoch 648 bits do not match those from the current epoch implementations SHOULD 649 use the most recent past epoch which has matching bits, and then 650 reconstruct the sequence number for that epoch as described above. 652 4.2.3. Record Number Encryption 654 In DTLS 1.3, when records are encrypted, record sequence numbers are 655 also encrypted. The basic pattern is that the underlying encryption 656 algorithm used with the AEAD algorithm is used to generate a mask 657 which is then XORed with the sequence number. 659 When the AEAD is based on AES, then the Mask is generated by 660 computing AES-ECB on the first 16 bytes of the ciphertext: 662 Mask = AES-ECB(sn_key, Ciphertext[0..15]) 664 When the AEAD is based on ChaCha20, then the mask is generated by 665 treating the first 4 bytes of the ciphertext as the block counter and 666 the next 12 bytes as the nonce, passing them to the ChaCha20 block 667 function (Section 2.3 of [CHACHA]): 669 Mask = ChaCha20(sn_key, Ciphertext[0..3], Ciphertext[4..15]) 671 The sn_key is computed as follows: 673 [sender]_sn_key = HKDF-Expand-Label(Secret, "sn" , "", key_length) 675 [sender] denotes the sending side. The Secret value to be used is 676 described in Section 7.3 of [TLS13]. 678 The encrypted sequence number is computed by XORing the leading bytes 679 of the Mask with the sequence number. Decryption is accomplished by 680 the same process. 682 This procedure requires the ciphertext length be at least 16 bytes. 683 Receivers MUST reject shorter records as if they had failed 684 deprotection, as described in Section 4.5.2. Senders MUST pad short 685 plaintexts out (using the conventional record padding mechanism) in 686 order to make a suitable-length ciphertext. Note most of the DTLS 687 AEAD algorithms have a 16-byte authentication tag and need no 688 padding. However, some algorithms such as TLS_AES_128_CCM_8_SHA256 689 have a shorter authentication tag and may require padding for short 690 inputs. 692 Future cipher suites, which are not based on AES or ChaCha20, MUST 693 define their own record sequence number encryption in order to be 694 used with DTLS. 696 Note that sequence number encryption is only applied to the 697 DTLSCiphertext structure and not to the DTLSPlaintext structure, 698 which also contains a sequence number. 700 4.3. Transport Layer Mapping 702 DTLS messages MAY be fragmented into multiple DTLS records. Each 703 DTLS record MUST fit within a single datagram. In order to avoid IP 704 fragmentation, clients of the DTLS record layer SHOULD attempt to 705 size records so that they fit within any PMTU estimates obtained from 706 the record layer. 708 Multiple DTLS records MAY be placed in a single datagram. Records 709 are encoded consecutively. The length field from DTLS records 710 containing that field can be used to determine the boundaries between 711 records. The final record in a datagram can omit the length field. 712 The first byte of the datagram payload MUST be the beginning of a 713 record. Records MUST NOT span datagrams. 715 DTLS records without CIDs do not contain any association identifiers 716 and applications must arrange to multiplex between associations. 717 With UDP, the host/port number is used to look up the appropriate 718 security association for incoming records without CIDs. 720 Some transports, such as DCCP [RFC4340], provide their own sequence 721 numbers. When carried over those transports, both the DTLS and the 722 transport sequence numbers will be present. Although this introduces 723 a small amount of inefficiency, the transport layer and DTLS sequence 724 numbers serve different purposes; therefore, for conceptual 725 simplicity, it is superior to use both sequence numbers. 727 Some transports provide congestion control for traffic carried over 728 them. If the congestion window is sufficiently narrow, DTLS 729 handshake retransmissions may be held rather than transmitted 730 immediately, potentially leading to timeouts and spurious 731 retransmission. When DTLS is used over such transports, care should 732 be taken not to overrun the likely congestion window. [RFC5238] 733 defines a mapping of DTLS to DCCP that takes these issues into 734 account. 736 4.4. PMTU Issues 738 In general, DTLS's philosophy is to leave PMTU discovery to the 739 application. However, DTLS cannot completely ignore PMTU for three 740 reasons: 742 * The DTLS record framing expands the datagram size, thus lowering 743 the effective PMTU from the application's perspective. 745 * In some implementations, the application may not directly talk to 746 the network, in which case the DTLS stack may absorb ICMP 747 [RFC1191] "Datagram Too Big" indications or ICMPv6 [RFC4443] 748 "Packet Too Big" indications. 750 * The DTLS handshake messages can exceed the PMTU. 752 In order to deal with the first two issues, the DTLS record layer 753 SHOULD behave as described below. 755 If PMTU estimates are available from the underlying transport 756 protocol, they should be made available to upper layer protocols. In 757 particular: 759 * For DTLS over UDP, the upper layer protocol SHOULD be allowed to 760 obtain the PMTU estimate maintained in the IP layer. 762 * For DTLS over DCCP, the upper layer protocol SHOULD be allowed to 763 obtain the current estimate of the PMTU. 765 * For DTLS over TCP or SCTP, which automatically fragment and 766 reassemble datagrams, there is no PMTU limitation. However, the 767 upper layer protocol MUST NOT write any record that exceeds the 768 maximum record size of 2^14 bytes. 770 The DTLS record layer SHOULD also allow the upper layer protocol to 771 discover the amount of record expansion expected by the DTLS 772 processing; alternately it MAY report PMTU estimates minus the 773 estimated expansion from the transport layer and DTLS record framing. 775 Note that DTLS does not defend against spoofed ICMP messages; 776 implementations SHOULD ignore any such messages that indicate PMTUs 777 below the IPv4 and IPv6 minimums of 576 and 1280 bytes respectively 779 If there is a transport protocol indication that the PMTU was 780 exceeded (either via ICMP or via a refusal to send the datagram as in 781 Section 14 of [RFC4340]), then the DTLS record layer MUST inform the 782 upper layer protocol of the error. 784 The DTLS record layer SHOULD NOT interfere with upper layer protocols 785 performing PMTU discovery, whether via [RFC1191] or [RFC4821] 786 mechanisms. In particular: 788 * Where allowed by the underlying transport protocol, the upper 789 layer protocol SHOULD be allowed to set the state of the DF bit 790 (in IPv4) or prohibit local fragmentation (in IPv6). 792 * If the underlying transport protocol allows the application to 793 request PMTU probing (e.g., DCCP), the DTLS record layer SHOULD 794 honor this request. 796 The final issue is the DTLS handshake protocol. From the perspective 797 of the DTLS record layer, this is merely another upper layer 798 protocol. However, DTLS handshakes occur infrequently and involve 799 only a few round trips; therefore, the handshake protocol PMTU 800 handling places a premium on rapid completion over accurate PMTU 801 discovery. In order to allow connections under these circumstances, 802 DTLS implementations SHOULD follow the following rules: 804 * If the DTLS record layer informs the DTLS handshake layer that a 805 message is too big, the handshake layer SHOULD immediately attempt 806 to fragment the message, using any existing information about the 807 PMTU. 809 * If repeated retransmissions do not result in a response, and the 810 PMTU is unknown, subsequent retransmissions SHOULD back off to a 811 smaller record size, fragmenting the handshake message as 812 appropriate. This specification does not specify an exact number 813 of retransmits to attempt before backing off, but 2-3 seems 814 appropriate. 816 4.5. Record Payload Protection 818 Like TLS, DTLS transmits data as a series of protected records. The 819 rest of this section describes the details of that format. 821 4.5.1. Anti-Replay 823 Each DTLS record contains a sequence number to provide replay 824 protection. Sequence number verification SHOULD be performed using 825 the following sliding window procedure, borrowed from Section 3.4.3 826 of [RFC4303]. 828 The received record counter for an association MUST be initialized to 829 zero when that association is established. For each received record, 830 the receiver MUST verify that the record contains a sequence number 831 that does not duplicate the sequence number of any other record 832 received during the lifetime of the association. This check SHOULD 833 happen after deprotecting the record; otherwise the record discard 834 might itself serve as a timing channel for the record number. Note 835 that computing the full record number from the partial is still a 836 potential timing channel for the record number, though a less 837 powerful one than whether the record was deprotected. 839 Duplicates are rejected through the use of a sliding receive window. 840 (How the window is implemented is a local matter, but the following 841 text describes the functionality that the implementation must 842 exhibit.) The receiver SHOULD pick a window large enough to handle 843 any plausible reordering, which depends on the data rate. (The 844 receiver does not notify the sender of the window size.) 846 The "right" edge of the window represents the highest validated 847 sequence number value received on the association. Records that 848 contain sequence numbers lower than the "left" edge of the window are 849 rejected. Records falling within the window are checked against a 850 list of received records within the window. An efficient means for 851 performing this check, based on the use of a bit mask, is described 852 in Section 3.4.3 of [RFC4303]. If the received record falls within 853 the window and is new, or if the record is to the right of the 854 window, then the record is new. 856 The window MUST NOT be updated until the record has been deprotected 857 successfully. 859 4.5.2. Handling Invalid Records 861 Unlike TLS, DTLS is resilient in the face of invalid records (e.g., 862 invalid formatting, length, MAC, etc.). In general, invalid records 863 SHOULD be silently discarded, thus preserving the association; 864 however, an error MAY be logged for diagnostic purposes. 865 Implementations which choose to generate an alert instead, MUST 866 generate error alerts to avoid attacks where the attacker repeatedly 867 probes the implementation to see how it responds to various types of 868 error. Note that if DTLS is run over UDP, then any implementation 869 which does this will be extremely susceptible to denial-of-service 870 (DoS) attacks because UDP forgery is so easy. Thus, this practice is 871 NOT RECOMMENDED for such transports, both to increase the reliability 872 of DTLS service and to avoid the risk of spoofing attacks sending 873 traffic to unrelated third parties. 875 If DTLS is being carried over a transport that is resistant to 876 forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts 877 because an attacker will have difficulty forging a datagram that will 878 not be rejected by the transport layer. 880 4.5.3. AEAD Limits 882 Section 5.5 of TLS [TLS13] defines limits on the number of records 883 that can be protected using the same keys. These limits are specific 884 to an AEAD algorithm, and apply equally to DTLS. Implementations 885 SHOULD NOT protect more records than allowed by the limit specified 886 for the negotiated AEAD. Implementations SHOULD initiate a key 887 update before reaching this limit. 889 [TLS13] does not specify a limit for AEAD_AES_128_CCM, but the 890 analysis in Appendix B shows that a limit of 2^23 packets can be used 891 to obtain the same confidentiality protection as the limits specified 892 in TLS. 894 The usage limits defined in TLS 1.3 exist for protection against 895 attacks on confidentiality and apply to successful applications of 896 AEAD protection. The integrity protections in authenticated 897 encryption also depend on limiting the number of attempts to forge 898 packets. TLS achieves this by closing connections after any record 899 fails an authentication check. In comparison, DTLS ignores any 900 packet that cannot be authenticated, allowing multiple forgery 901 attempts. 903 Implementations MUST count the number of received packets that fail 904 authentication with each key. If the number of packets that fail 905 authentication exceed a limit that is specific to the AEAD in use, an 906 implementation SHOULD immediately close the connection. 907 Implementations SHOULD initiate a key update with update_requested 908 before reaching this limit. Once a key update has been initiated, 909 the previous keys can be dropped when the limit is reached rather 910 than closing the connection. Applying a limit reduces the 911 probability that an attacker is able to successfully forge a packet; 912 see [AEBounds] and [ROBUST]. 914 For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305, 915 the limit on the number of records that fail authentication is 2^36. 916 Note that the analysis in [AEBounds] supports a higher limit for the 917 AEAD_AES_128_GCM and AEAD_AES_256_GCM, but this specification 918 recommends a lower limit. For AEAD_AES_128_CCM, the limit on the 919 number of records that fail authentication is 2^23.5; see Appendix B. 921 The AEAD_AES_128_CCM_8 AEAD, as used in TLS_AES_128_CCM_8_SHA256, 922 does not have a limit on the number of records that fail 923 authentication that both limits the probability of forgery by the 924 same amount and does not expose implementations to the risk of denial 925 of service; see Appendix B.3. Therefore, TLS_AES_128_CCM_8_SHA256 926 MUST NOT used in DTLS without additional safeguards against forgery. 927 Implementations MUST set usage limits for AEAD_AES_128_CCM_8 based on 928 an understanding of any additional forgery protections that are used. 930 Any TLS cipher suite that is specified for use with DTLS MUST define 931 limits on the use of the associated AEAD function that preserves 932 margins for both confidentiality and integrity. That is, limits MUST 933 be specified for the number of packets that can be authenticated and 934 for the number of packets that can fail authentication before a key 935 update is required. Providing a reference to any analysis upon which 936 values are based - and any assumptions used in that analysis - allows 937 limits to be adapted to varying usage conditions. 939 5. The DTLS Handshake Protocol 941 DTLS 1.3 re-uses the TLS 1.3 handshake messages and flows, with the 942 following changes: 944 1. To handle message loss, reordering, and fragmentation 945 modifications to the handshake header are necessary. 947 2. Retransmission timers are introduced to handle message loss. 949 3. A new ACK content type has been added for reliable message 950 delivery of handshake messages. 952 Note that TLS 1.3 already supports a cookie extension, which is used 953 to prevent denial-of-service attacks. This DoS prevention mechanism 954 is described in more detail below since UDP-based protocols are more 955 vulnerable to amplification attacks than a connection-oriented 956 transport like TCP that performs return-routability checks as part of 957 the connection establishment. 959 DTLS implementations do not use the TLS 1.3 "compatibility mode" 960 described in Section D.4 of [TLS13]. DTLS servers MUST NOT echo the 961 "legacy_session_id" value from the client and endpoints MUST NOT send 962 ChangeCipherSpec messages. 964 With these exceptions, the DTLS message formats, flows, and logic are 965 the same as those of TLS 1.3. 967 5.1. Denial-of-Service Countermeasures 969 Datagram security protocols are extremely susceptible to a variety of 970 DoS attacks. Two attacks are of particular concern: 972 1. An attacker can consume excessive resources on the server by 973 transmitting a series of handshake initiation requests, causing 974 the server to allocate state and potentially to perform expensive 975 cryptographic operations. 977 2. An attacker can use the server as an amplifier by sending 978 connection initiation messages with a forged source address that 979 belongs to a victim. The server then sends its response to the 980 victim machine, thus flooding it. Depending on the selected 981 parameters this response message can be quite large, as is the 982 case for a Certificate message. 984 In order to counter both of these attacks, DTLS borrows the stateless 985 cookie technique used by Photuris [RFC2522] and IKE [RFC7296]. When 986 the client sends its ClientHello message to the server, the server 987 MAY respond with a HelloRetryRequest message. The HelloRetryRequest 988 message, as well as the cookie extension, is defined in TLS 1.3. The 989 HelloRetryRequest message contains a stateless cookie (see [TLS13]; 990 Section 4.2.2). The client MUST send a new ClientHello with the 991 cookie added as an extension. The server then verifies the cookie 992 and proceeds with the handshake only if it is valid. This mechanism 993 forces the attacker/client to be able to receive the cookie, which 994 makes DoS attacks with spoofed IP addresses difficult. This 995 mechanism does not provide any defense against DoS attacks mounted 996 from valid IP addresses. 998 The DTLS 1.3 specification changes how cookies are exchanged compared 999 to DTLS 1.2. DTLS 1.3 re-uses the HelloRetryRequest message and 1000 conveys the cookie to the client via an extension. The client 1001 receiving the cookie uses the same extension to place the cookie 1002 subsequently into a ClientHello message. DTLS 1.2 on the other hand 1003 used a separate message, namely the HelloVerifyRequest, to pass a 1004 cookie to the client and did not utilize the extension mechanism. 1005 For backwards compatibility reasons, the cookie field in the 1006 ClientHello is present in DTLS 1.3 but is ignored by a DTLS 1.3 1007 compliant server implementation. 1009 The exchange is shown in Figure 6. Note that the figure focuses on 1010 the cookie exchange; all other extensions are omitted. 1012 Client Server 1013 ------ ------ 1014 ClientHello ------> 1016 <----- HelloRetryRequest 1017 + cookie 1019 ClientHello ------> 1020 + cookie 1022 [Rest of handshake] 1024 Figure 6: DTLS exchange with HelloRetryRequest containing the 1025 "cookie" extension 1027 The cookie extension is defined in Section 4.2.2 of [TLS13]. When 1028 sending the initial ClientHello, the client does not have a cookie 1029 yet. In this case, the cookie extension is omitted and the 1030 legacy_cookie field in the ClientHello message MUST be set to a zero 1031 length vector (i.e., a single zero byte length field). 1033 When responding to a HelloRetryRequest, the client MUST create a new 1034 ClientHello message following the description in Section 4.1.2 of 1035 [TLS13]. 1037 If the HelloRetryRequest message is used, the initial ClientHello and 1038 the HelloRetryRequest are included in the calculation of the 1039 transcript hash. The computation of the message hash for the 1040 HelloRetryRequest is done according to the description in 1041 Section 4.4.1 of [TLS13]. 1043 The handshake transcript is not reset with the second ClientHello and 1044 a stateless server-cookie implementation requires the transcript or 1045 hash of the HelloRetryRequest to be stored in the cookie, since the 1046 initial ClientHello is included in the handshake transcript as a 1047 synthetic "message_hash" message, so only the hash value is needed 1048 for the handshake to complete. 1050 When the second ClientHello is received, the server can verify that 1051 the cookie is valid and that the client can receive packets at the 1052 given IP address. If the client's apparent IP address is embedded in 1053 the cookie, this prevents an attacker from generating an acceptable 1054 ClientHello apparently from another user. 1056 One potential attack on this scheme is for the attacker to collect a 1057 number of cookies from different addresses where it controls 1058 endpoints and then reuse them to attack the server. The server can 1059 defend against this attack by changing the secret value frequently, 1060 thus invalidating those cookies. If the server wishes to allow 1061 legitimate clients to handshake through the transition (e.g., a 1062 client received a cookie with Secret 1 and then sent the second 1063 ClientHello after the server has changed to Secret 2), the server can 1064 have a limited window during which it accepts both secrets. 1065 [RFC7296] suggests adding a key identifier to cookies to detect this 1066 case. An alternative approach is simply to try verifying with both 1067 secrets. It is RECOMMENDED that servers implement a key rotation 1068 scheme that allows the server to manage keys with overlapping 1069 lifetime. 1071 Alternatively, the server can store timestamps in the cookie and 1072 reject cookies that were generated outside a certain interval of 1073 time. 1075 DTLS servers SHOULD perform a cookie exchange whenever a new 1076 handshake is being performed. If the server is being operated in an 1077 environment where amplification is not a problem, the server MAY be 1078 configured not to perform a cookie exchange. The default SHOULD be 1079 that the exchange is performed, however. In addition, the server MAY 1080 choose not to do a cookie exchange when a session is resumed or, more 1081 generically, when the DTLS handshake uses a PSK-based key exchange. 1082 Servers which process 0-RTT requests and send 0.5-RTT responses 1083 without a cookie exchange risk being used in an amplification attack 1084 if the size of outgoing messages greatly exceeds the size of those 1085 that are received. A server SHOULD limit the amount of data it sends 1086 toward a client address before it verifies that the client is able to 1087 receive data at that address. A client address is valid after a 1088 cookie exchange or handshake completion. A server MAY apply a higher 1089 limit based on heuristics, such as if the client uses the same IP 1090 address as the connection on which the cookie was created. Clients 1091 MUST be prepared to do a cookie exchange with every handshake. 1093 If a server receives a ClientHello with an invalid cookie, it MUST 1094 terminate the handshake with an "illegal_parameter" alert. This 1095 allows the client to restart the connection from scratch without a 1096 cookie. 1098 As described in Section 4.1.4 of [TLS13], clients MUST abort the 1099 handshake with an "unexpected_message" alert in response to any 1100 second HelloRetryRequest which was sent in the same connection (i.e., 1101 where the ClientHello was itself in response to a HelloRetryRequest). 1103 5.2. DTLS Handshake Message Format 1105 In order to support message loss, reordering, and message 1106 fragmentation, DTLS modifies the TLS 1.3 handshake header: 1108 enum { 1109 client_hello(1), 1110 server_hello(2), 1111 new_session_ticket(4), 1112 end_of_early_data(5), 1113 encrypted_extensions(8), 1114 certificate(11), 1115 certificate_request(13), 1116 certificate_verify(15), 1117 finished(20), 1118 key_update(24), 1119 message_hash(254), 1120 (255) 1121 } HandshakeType; 1123 struct { 1124 HandshakeType msg_type; /* handshake type */ 1125 uint24 length; /* bytes in message */ 1126 uint16 message_seq; /* DTLS-required field */ 1127 uint24 fragment_offset; /* DTLS-required field */ 1128 uint24 fragment_length; /* DTLS-required field */ 1129 select (HandshakeType) { 1130 case client_hello: ClientHello; 1131 case server_hello: ServerHello; 1132 case end_of_early_data: EndOfEarlyData; 1133 case encrypted_extensions: EncryptedExtensions; 1134 case certificate_request: CertificateRequest; 1135 case certificate: Certificate; 1136 case certificate_verify: CertificateVerify; 1137 case finished: Finished; 1138 case new_session_ticket: NewSessionTicket; 1139 case key_update: KeyUpdate; 1140 } body; 1141 } Handshake; 1143 The first message each side transmits in each association always has 1144 message_seq = 0. Whenever a new message is generated, the 1145 message_seq value is incremented by one. When a message is 1146 retransmitted, the old message_seq value is re-used, i.e., not 1147 incremented. From the perspective of the DTLS record layer, the 1148 retransmission is a new record. This record will have a new 1149 DTLSPlaintext.sequence_number value. 1151 Note: In DTLS 1.2 the message_seq was reset to zero in case of a 1152 rehandshake (i.e., renegotiation). On the surface, a rehandshake in 1153 DTLS 1.2 shares similarities with a post-handshake message exchange 1154 in DTLS 1.3. However, in DTLS 1.3 the message_seq is not reset to 1155 allow distinguishing a retransmission from a previously sent post- 1156 handshake message from a newly sent post-handshake message. 1158 DTLS implementations maintain (at least notionally) a 1159 next_receive_seq counter. This counter is initially set to zero. 1160 When a handshake message is received, if its message_seq value 1161 matches next_receive_seq, next_receive_seq is incremented and the 1162 message is processed. If the sequence number is less than 1163 next_receive_seq, the message MUST be discarded. If the sequence 1164 number is greater than next_receive_seq, the implementation SHOULD 1165 queue the message but MAY discard it. (This is a simple space/ 1166 bandwidth tradeoff). 1168 In addition to the handshake messages that are deprecated by the TLS 1169 1.3 specification, DTLS 1.3 furthermore deprecates the 1170 HelloVerifyRequest message originally defined in DTLS 1.0. DTLS 1171 1.3-compliant implements MUST NOT use the HelloVerifyRequest to 1172 execute a return-routability check. A dual-stack DTLS 1.2/DTLS 1.3 1173 client MUST, however, be prepared to interact with a DTLS 1.2 server. 1175 5.3. ClientHello Message 1177 The format of the ClientHello used by a DTLS 1.3 client differs from 1178 the TLS 1.3 ClientHello format as shown below. 1180 uint16 ProtocolVersion; 1181 opaque Random[32]; 1183 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 1185 struct { 1186 ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2 1187 Random random; 1188 opaque legacy_session_id<0..32>; 1189 opaque legacy_cookie<0..2^8-1>; // DTLS 1190 CipherSuite cipher_suites<2..2^16-2>; 1191 opaque legacy_compression_methods<1..2^8-1>; 1192 Extension extensions<8..2^16-1>; 1193 } ClientHello; 1195 legacy_version: In previous versions of DTLS, this field was used 1196 for version negotiation and represented the highest version number 1197 supported by the client. Experience has shown that many servers 1198 do not properly implement version negotiation, leading to "version 1199 intolerance" in which the server rejects an otherwise acceptable 1200 ClientHello with a version number higher than it supports. In 1201 DTLS 1.3, the client indicates its version preferences in the 1202 "supported_versions" extension (see Section 4.2.1 of [TLS13]) and 1203 the legacy_version field MUST be set to {254, 253}, which was the 1204 version number for DTLS 1.2. The supported_versions entries for 1205 DTLS 1.0 and DTLS 1.2 are 0xfeff and 0xfefd (to match the wire 1206 versions). The value 0xfefc is used to indicate DTLS 1.3. 1208 random: Same as for TLS 1.3. 1210 legacy_session_id: Versions of TLS and DTLS before version 1.3 1211 supported a "session resumption" feature which has been merged 1212 with pre-shared keys in version 1.3. A client which has a cached 1213 session ID set by a pre-DTLS 1.3 server SHOULD set this field to 1214 that value. Otherwise, it MUST be set as a zero-length vector 1215 (i.e., a zero-valued single byte length field). 1217 legacy_cookie: A DTLS 1.3-only client MUST set the legacy_cookie 1218 field to zero length. If a DTLS 1.3 ClientHello is received with 1219 any other value in this field, the server MUST abort the handshake 1220 with an "illegal_parameter" alert. 1222 cipher_suites: Same as for TLS 1.3; only suites with DTLS-OK=Y may 1223 be used. 1225 legacy_compression_methods: Same as for TLS 1.3. 1227 extensions: Same as for TLS 1.3. 1229 5.4. ServerHello Message 1231 The DTLS 1.3 ServerHello message is the same as the TLS 1.3 1232 ServerHello message, except that the legacy_version field is set to 1233 0xfefd, indicating DTLS 1.2. 1235 5.5. Handshake Message Fragmentation and Reassembly 1237 As described in Section 4.3 one or more handshake messages may be 1238 carried in a single datagram. However, handshake messages are 1239 potentially bigger than the size allowed by the underlying datagram 1240 transport. DTLS provides a mechanism for fragmenting a handshake 1241 message over a number of records, each of which can be transmitted in 1242 separate datagrams, thus avoiding IP fragmentation. 1244 When transmitting the handshake message, the sender divides the 1245 message into a series of N contiguous data ranges. The ranges MUST 1246 NOT overlap. The sender then creates N handshake messages, all with 1247 the same message_seq value as the original handshake message. Each 1248 new message is labeled with the fragment_offset (the number of bytes 1249 contained in previous fragments) and the fragment_length (the length 1250 of this fragment). The length field in all messages is the same as 1251 the length field of the original message. An unfragmented message is 1252 a degenerate case with fragment_offset=0 and fragment_length=length. 1253 Each handshake message fragment that is placed into a record MUST be 1254 delivered in a single UDP datagram. 1256 When a DTLS implementation receives a handshake message fragment 1257 corresponding to the next expected handshake message sequence number, 1258 it MUST buffer it until it has the entire handshake message. DTLS 1259 implementations MUST be able to handle overlapping fragment ranges. 1260 This allows senders to retransmit handshake messages with smaller 1261 fragment sizes if the PMTU estimate changes. Senders MUST NOT change 1262 handshake message bytes upon retransmission. Receivers MAY check 1263 that retransmitted bytes are identical and SHOULD abort the handshake 1264 with an "illegal_parameter" alert if the value of a byte changes. 1266 Note that as with TLS, multiple handshake messages may be placed in 1267 the same DTLS record, provided that there is room and that they are 1268 part of the same flight. Thus, there are two acceptable ways to pack 1269 two DTLS handshake messages into the same datagram: in the same 1270 record or in separate records. 1272 5.6. End Of Early Data 1274 The DTLS 1.3 handshake has one important difference from the TLS 1.3 1275 handshake: the EndOfEarlyData message is omitted both from the wire 1276 and the handshake transcript: because DTLS records have epochs, 1277 EndOfEarlyData is not necessary to determine when the early data is 1278 complete, and because DTLS is lossy, attackers can trivially mount 1279 the deletion attacks that EndOfEarlyData prevents in TLS. Servers 1280 SHOULD NOT accept records from epoch 1 indefinitely once they are 1281 able to process records from epoch 3. Though reordering of IP 1282 packets can result in records from epoch 1 arriving after records 1283 from epoch 3, this is not likely to persist for very long relative to 1284 the round trip time. Servers could discard epoch 1 keys after the 1285 first epoch 3 data arrives, or retain keys for processing epoch 1 1286 data for a short period. is received. (See Section 6.1 for the 1287 definitions of each epoch.) 1289 5.7. DTLS Handshake Flights 1291 DTLS handshake messages are grouped into a series of message flights. 1292 A flight starts with the handshake message transmission of one peer 1293 and ends with the expected response from the other peer. Table 1 1294 contains a complete list of message combinations that consitute 1295 flights. 1297 +======+========+========+===================================+ 1298 | Note | Client | Server | Handshake Messages | 1299 +======+========+========+===================================+ 1300 | | x | | ClientHello | 1301 +------+--------+--------+-----------------------------------+ 1302 | | | x | HelloRetryRequest | 1303 +------+--------+--------+-----------------------------------+ 1304 | | | x | ServerHello, EncryptedExtensions, | 1305 | | | | CertificateRequest, Certificate, | 1306 | | | | CertificateVerify, Finished | 1307 +------+--------+--------+-----------------------------------+ 1308 | 1 | x | | Certificate, CertificateVerify, | 1309 | | | | Finished | 1310 +------+--------+--------+-----------------------------------+ 1311 | | | x | ACK | 1312 +------+--------+--------+-----------------------------------+ 1313 | 1 | | x | NewSessionTicket | 1314 +------+--------+--------+-----------------------------------+ 1316 Table 1: Flight Handshake Message Combinations. 1318 Remarks: 1320 * Table 1 does not highlight any of the optional messages. 1322 * Regarding note (1): When a handshake flight is sent without any 1323 expected response, as it is the case with the client's final 1324 flight or with the NewSessionTicket message, the flight must be 1325 acknowledged with an ACK message. 1327 Below are several example message exchange illustrating the flight 1328 concept. 1330 Client Server 1332 +--------+ 1333 ClientHello | Flight | 1334 --------> +--------+ 1336 +--------+ 1337 <-------- HelloRetryRequest | Flight | 1338 + cookie +--------+ 1340 +--------+ 1341 ClientHello | Flight | 1342 + cookie --------> +--------+ 1344 ServerHello 1345 {EncryptedExtensions} +--------+ 1346 {CertificateRequest*} | Flight | 1347 {Certificate*} +--------+ 1348 {CertificateVerify*} 1349 {Finished} 1350 <-------- [Application Data*] 1352 {Certificate*} +--------+ 1353 {CertificateVerify*} | Flight | 1354 {Finished} --------> +--------+ 1355 [Application Data] 1357 +--------+ 1358 <-------- [ACK] | Flight | 1359 [Application Data*] +--------+ 1361 [Application Data] <-------> [Application Data] 1363 Figure 7: Message flights for a full DTLS Handshake (with cookie 1364 exchange) 1366 ClientHello +--------+ 1367 + pre_shared_key | Flight | 1368 + psk_key_exchange_modes +--------+ 1369 + key_share* --------> 1371 ServerHello 1372 + pre_shared_key +--------+ 1373 + key_share* | Flight | 1374 {EncryptedExtensions} +--------+ 1375 <-------- {Finished} 1376 [Application Data*] 1377 +--------+ 1378 {Finished} --------> | Flight | 1379 [Application Data*] +--------+ 1381 +--------+ 1382 <-------- [ACK] | Flight | 1383 [Application Data*] +--------+ 1385 [Application Data] <-------> [Application Data] 1387 Figure 8: Message flights for resumption and PSK handshake 1388 (without cookie exchange) 1390 Client Server 1392 ClientHello 1393 + early_data 1394 + psk_key_exchange_modes +--------+ 1395 + key_share* | Flight | 1396 + pre_shared_key +--------+ 1397 (Application Data*) --------> 1399 ServerHello 1400 + pre_shared_key 1401 + key_share* +--------+ 1402 {EncryptedExtensions} | Flight | 1403 {Finished} +--------+ 1404 <-------- [Application Data*] 1406 +--------+ 1407 {Finished} --------> | Flight | 1408 [Application Data*] +--------+ 1410 +--------+ 1411 <-------- [ACK] | Flight | 1412 [Application Data*] +--------+ 1414 [Application Data] <-------> [Application Data] 1416 Figure 9: Message flights for the Zero-RTT handshake 1418 Client Server 1420 +--------+ 1421 <-------- [NewSessionTicket] | Flight | 1422 +--------+ 1424 +--------+ 1425 [ACK] --------> | Flight | 1426 +--------+ 1428 Figure 10: Message flights for the NewSessionTicket message 1430 KeyUpdate, NewConnectionId and RequestConnectionId follow a similar 1431 pattern to NewSessionTicket: a single message sent by one side 1432 followed by an ACK by the other. 1434 5.8. Timeout and Retransmission 1436 5.8.1. State Machine 1438 DTLS uses a simple timeout and retransmission scheme with the state 1439 machine shown in Figure 11. Because DTLS clients send the first 1440 message (ClientHello), they start in the PREPARING state. DTLS 1441 servers start in the WAITING state, but with empty buffers and no 1442 retransmit timer. 1444 +-----------+ 1445 | PREPARING | 1446 +----------> | | 1447 | | | 1448 | +-----------+ 1449 | | 1450 | | Buffer next flight 1451 | | 1452 | \|/ 1453 | +-----------+ 1454 | | | 1455 | | SENDING |<------------------+ 1456 | | | | 1457 | +-----------+ | 1458 Receive | | | 1459 next | | Send flight or partial | 1460 flight | | flight | 1461 | | | 1462 | | Set retransmit timer | 1463 | \|/ | 1464 | +-----------+ | 1465 | | | | 1466 +------------| WAITING |-------------------+ 1467 | +----->| | Timer expires | 1468 | | +-----------+ | 1469 | | | | | | 1470 | | | | | | 1471 | +----------+ | +--------------------+ 1472 | Receive record | Read retransmit or ACK 1473 Receive | (Maybe Send ACK) | 1474 last | | 1475 flight | | Receive ACK 1476 | | for last flight 1477 \|/ | 1478 | 1479 +-----------+ | 1480 | | <---------+ 1481 | FINISHED | 1482 | | 1483 +-----------+ 1484 | /|\ 1485 | | 1486 | | 1487 +---+ 1489 Server read retransmit 1490 Retransmit ACK 1492 Figure 11: DTLS timeout and retransmission state machine 1494 The state machine has four basic states: PREPARING, SENDING, WAITING, 1495 and FINISHED. 1497 In the PREPARING state, the implementation does whatever computations 1498 are necessary to prepare the next flight of messages. It then 1499 buffers them up for transmission (emptying the buffer first) and 1500 enters the SENDING state. 1502 In the SENDING state, the implementation transmits the buffered 1503 flight of messages. If the implementation has received one or more 1504 ACKs (see Section 7) from the peer, then it SHOULD omit any messages 1505 or message fragments which have already been ACKed. Once the 1506 messages have been sent, the implementation then sets a retransmit 1507 timer and enters the WAITING state. 1509 There are four ways to exit the WAITING state: 1511 1. The retransmit timer expires: the implementation transitions to 1512 the SENDING state, where it retransmits the flight, resets the 1513 retransmit timer, and returns to the WAITING state. 1515 2. The implementation reads an ACK from the peer: upon receiving an 1516 ACK for a partial flight (as mentioned in Section 7.1), the 1517 implementation transitions to the SENDING state, where it 1518 retransmits the unacked portion of the flight, resets the 1519 retransmit timer, and returns to the WAITING state. Upon 1520 receiving an ACK for a complete flight, the implementation 1521 cancels all retransmissions and either remains in WAITING, or, if 1522 the ACK was for the final flight, transitions to FINISHED. 1524 3. The implementation reads a retransmitted flight from the peer: 1525 the implementation transitions to the SENDING state, where it 1526 retransmits the flight, resets the retransmit timer, and returns 1527 to the WAITING state. The rationale here is that the receipt of 1528 a duplicate message is the likely result of timer expiry on the 1529 peer and therefore suggests that part of one's previous flight 1530 was lost. 1532 4. The implementation receives some or all of the next flight of 1533 messages: if this is the final flight of messages, the 1534 implementation transitions to FINISHED. If the implementation 1535 needs to send a new flight, it transitions to the PREPARING 1536 state. Partial reads (whether partial messages or only some of 1537 the messages in the flight) may also trigger the implementation 1538 to send an ACK, as described in Section 7.1. 1540 Because DTLS clients send the first message (ClientHello), they start 1541 in the PREPARING state. DTLS servers start in the WAITING state, but 1542 with empty buffers and no retransmit timer. 1544 In addition, for at least twice the default MSL defined for 1545 [RFC0793], when in the FINISHED state, the server MUST respond to 1546 retransmission of the client's final flight with a retransmit of its 1547 ACK. 1549 Note that because of packet loss, it is possible for one side to be 1550 sending application data even though the other side has not received 1551 the first side's Finished message. Implementations MUST either 1552 discard or buffer all application data records for epoch 3 and above 1553 until they have received the Finished message from the peer. 1554 Implementations MAY treat receipt of application data with a new 1555 epoch prior to receipt of the corresponding Finished message as 1556 evidence of reordering or packet loss and retransmit their final 1557 flight immediately, shortcutting the retransmission timer. 1559 5.8.2. Timer Values 1561 Though timer values are the choice of the implementation, mishandling 1562 of the timer can lead to serious congestion problems, for example if 1563 many instances of a DTLS time out early and retransmit too quickly on 1564 a congested link. Implementations SHOULD use an initial timer value 1565 of 100 msec (the minimum defined in RFC 6298 [RFC6298]) and double 1566 the value at each retransmission, up to no less than the RFC 6298 1567 maximum of 60 seconds. Application specific profiles, such as those 1568 used for the Internet of Things environment, may recommend longer 1569 timer values. Note that a 100 msec timer is recommended rather than 1570 the 3-second RFC 6298 default in order to improve latency for time- 1571 sensitive applications. Because DTLS only uses retransmission for 1572 handshake and not dataflow, the effect on congestion should be 1573 minimal. 1575 Implementations SHOULD retain the current timer value until a message 1576 is transmitted and acknowledged without having to be retransmitted, 1577 at which time the value may be reset to the initial value. After a 1578 long period of idleness, no less than 10 times the current timer 1579 value, implementations MAY reset the timer to the initial value. 1581 5.8.3. Large Flight Sizes 1583 DTLS does not have any built-in congestion control or rate control; 1584 in general this is not an issue because messages tend to be small. 1585 However, in principle, some messages - especially Certificate - can 1586 be quite large. If all the messages in a large flight are sent at 1587 once, this can result in network congestion. A better strategy is to 1588 send out only part of the flight, sending more when messages are 1589 acknowledged. DTLS offers a number of mechanisms for minimizing the 1590 size of the certificate message, including the cached information 1591 extension [RFC7924] and certificate compression [RFC8879]. 1593 5.8.4. State machine duplication for post-handshake messages 1595 DTLS 1.3 makes use of the following categories of post-handshake 1596 messages: 1598 1. NewSessionTicket 1600 2. KeyUpdate 1602 3. NewConnectionId 1604 4. RequestConnectionId 1606 5. Post-handshake client authentication 1608 Messages of each category can be sent independently, and reliability 1609 is established via independent state machines each of which behaves 1610 as described in Section 5.8.1. For example, if a server sends a 1611 NewSessionTicket and a CertificateRequest message, two independent 1612 state machines will be created. 1614 As explained in the corresponding sections, sending multiple 1615 instances of messages of a given category without having completed 1616 earlier transmissions is allowed for some categories, but not for 1617 others. Specifically, a server MAY send multiple NewSessionTicket 1618 messages at once without awaiting ACKs for earlier NewSessionTicket 1619 first. Likewise, a server MAY send multiple CertificateRequest 1620 messages at once without having completed earlier client 1621 authentication requests before. In contrast, implementations MUST 1622 NOT have send KeyUpdate, NewConnectionId or RequestConnectionId 1623 message if an earlier message of the same type has not yet been 1624 acknowledged. 1626 Note: Except for post-handshake client authentication, which involves 1627 handshake messages in both directions, post-handshake messages are 1628 single-flight, and their respective state machines on the sender side 1629 reduce to waiting for an ACK and retransmitting the original message. 1630 In particular, note that a RequestConnectionId message does not force 1631 the receiver to send a NewConnectionId message in reply, and both 1632 messages are therefore treated independently. 1634 Creating and correctly updating multiple state machines requires 1635 feedback from the handshake logic to the state machine layer, 1636 indicating which message belongs to which state machine. For 1637 example, if a server sends multiple CertificateRequest messages and 1638 receives a Certificate message in response, the corresponding state 1639 machine can only be determined after inspecting the 1640 certificate_request_context field. Similarly, a server sending a 1641 single CertificateRequest and receiving a NewConnectionId message in 1642 response can only decide that the NewConnectionId message should be 1643 treated through an independent state machine after inspecting the 1644 handshake message type. 1646 5.9. CertificateVerify and Finished Messages 1648 CertificateVerify and Finished messages have the same format as in 1649 TLS 1.3. Hash calculations include entire handshake messages, 1650 including DTLS-specific fields: message_seq, fragment_offset, and 1651 fragment_length. However, in order to remove sensitivity to 1652 handshake message fragmentation, the CertificateVerify and the 1653 Finished messages MUST be computed as if each handshake message had 1654 been sent as a single fragment following the algorithm described in 1655 Section 4.4.3 and Section 4.4.4 of [TLS13], respectively. 1657 5.10. Cryptographic Label Prefix 1659 Section 7.1 of [TLS13] specifies that HKDF-Expand-Label uses a label 1660 prefix of "tls13 ". For DTLS 1.3, that label SHALL be "dtls13". 1661 This ensures key separation between DTLS 1.3 and TLS 1.3. Note that 1662 there is no trailing space; this is necessary in order to keep the 1663 overall label size inside of one hash iteration because "DTLS" is one 1664 letter longer than "TLS". 1666 5.11. Alert Messages 1668 Note that Alert messages are not retransmitted at all, even when they 1669 occur in the context of a handshake. However, a DTLS implementation 1670 which would ordinarily issue an alert SHOULD generate a new alert 1671 message if the offending record is received again (e.g., as a 1672 retransmitted handshake message). Implementations SHOULD detect when 1673 a peer is persistently sending bad messages and terminate the local 1674 connection state after such misbehavior is detected. Note that 1675 alerts are not reliably transmitted; implementation SHOULD NOT depend 1676 on receiving alerts in order to signal errors or connection closure. 1678 5.12. Establishing New Associations with Existing Parameters 1680 If a DTLS client-server pair is configured in such a way that 1681 repeated connections happen on the same host/port quartet, then it is 1682 possible that a client will silently abandon one connection and then 1683 initiate another with the same parameters (e.g., after a reboot). 1684 This will appear to the server as a new handshake with epoch=0. In 1685 cases where a server believes it has an existing association on a 1686 given host/port quartet and it receives an epoch=0 ClientHello, it 1687 SHOULD proceed with a new handshake but MUST NOT destroy the existing 1688 association until the client has demonstrated reachability either by 1689 completing a cookie exchange or by completing a complete handshake 1690 including delivering a verifiable Finished message. After a correct 1691 Finished message is received, the server MUST abandon the previous 1692 association to avoid confusion between two valid associations with 1693 overlapping epochs. The reachability requirement prevents off-path/ 1694 blind attackers from destroying associations merely by sending forged 1695 ClientHellos. 1697 Note: it is not always possible to distinguish which association a 1698 given record is from. For instance, if the client performs a 1699 handshake, abandons the connection, and then immediately starts a new 1700 handshake, it may not be possible to tell which connection a given 1701 protected record is for. In these cases, trial decryption may be 1702 necessary, though implementations could use CIDs to avoid the 5- 1703 tuple-based ambiguity. 1705 6. Example of Handshake with Timeout and Retransmission 1707 The following is an example of a handshake with lost packets and 1708 retransmissions. Note that the client sends an empty ACK message 1709 because it can only acknowledge Record 1 sent by the server once it 1710 has processed messages in Record 0 needed to establish epoch 2 keys, 1711 which are needed to encrypt to decrypt messages found in Record 1. 1712 Section 7 provides the necessary background details for this 1713 interaction. 1715 Client Server 1716 ------ ------ 1718 Record 0 --------> 1719 ClientHello 1720 (message_seq=0) 1722 X<----- Record 0 1723 (lost) ServerHello 1724 (message_seq=0) 1725 EncryptedExtensions 1726 (message_seq=1) 1727 Certificate 1728 (message_seq=2) 1730 <-------- Record 1 1731 CertificateVerify 1732 (message_seq=3) 1733 Finished 1734 (message_seq=4) 1736 Record 1 --------> 1737 ACK [] 1739 <-------- Record 2 1740 ServerHello 1741 (message_seq=0) 1742 EncryptedExtensions 1743 (message_seq=1) 1744 Certificate 1745 (message_seq=2) 1747 Record 2 --------> 1748 Certificate 1749 (message_seq=1) 1750 CertificateVerify 1751 (message_seq=2) 1752 Finished 1753 (message_seq=3) 1755 <-------- Record 3 1756 ACK [2] 1758 Figure 12: Example DTLS exchange illustrating message loss 1760 6.1. Epoch Values and Rekeying 1762 A recipient of a DTLS message needs to select the correct keying 1763 material in order to process an incoming message. With the 1764 possibility of message loss and re-ordering, an identifier is needed 1765 to determine which cipher state has been used to protect the record 1766 payload. The epoch value fulfills this role in DTLS. In addition to 1767 the TLS 1.3-defined key derivation steps, see Section 7 of [TLS13], a 1768 sender may want to rekey at any time during the lifetime of the 1769 connection. It therefore needs to indicate that it is updating its 1770 sending cryptographic keys. 1772 This version of DTLS assigns dedicated epoch values to messages in 1773 the protocol exchange to allow identification of the correct cipher 1774 state: 1776 * epoch value (0) is used with unencrypted messages. There are 1777 three unencrypted messages in DTLS, namely ClientHello, 1778 ServerHello, and HelloRetryRequest. 1780 * epoch value (1) is used for messages protected using keys derived 1781 from client_early_traffic_secret. Note this epoch is skipped if 1782 the client does not offer early data. 1784 * epoch value (2) is used for messages protected using keys derived 1785 from [sender]_handshake_traffic_secret. Messages transmitted 1786 during the initial handshake, such as EncryptedExtensions, 1787 CertificateRequest, Certificate, CertificateVerify, and Finished 1788 belong to this category. Note, however, post-handshake are 1789 protected under the appropriate application traffic key and are 1790 not included in this category. 1792 * epoch value (3) is used for payloads protected using keys derived 1793 from the initial [sender]_application_traffic_secret_0. This may 1794 include handshake messages, such as post-handshake messages (e.g., 1795 a NewSessionTicket message). 1797 * epoch value (4 to 2^16-1) is used for payloads protected using 1798 keys from the [sender]_application_traffic_secret_N (N>0). 1800 Using these reserved epoch values a receiver knows what cipher state 1801 has been used to encrypt and integrity protect a message. 1802 Implementations that receive a record with an epoch value for which 1803 no corresponding cipher state can be determined SHOULD handle it as a 1804 record which fails deprotection. 1806 Note that epoch values do not wrap. If a DTLS implementation would 1807 need to wrap the epoch value, it MUST terminate the connection. 1809 The traffic key calculation is described in Section 7.3 of [TLS13]. 1811 Figure 13 illustrates the epoch values in an example DTLS handshake. 1813 Client Server 1814 ------ ------ 1816 Record 0 1817 ClientHello 1818 (epoch=0) 1819 --------> 1820 Record 0 1821 <-------- HelloRetryRequest 1822 (epoch=0) 1823 Record 1 1824 ClientHello --------> 1825 (epoch=0) 1826 Record 1 1827 <-------- ServerHello 1828 (epoch=0) 1829 {EncryptedExtensions} 1830 (epoch=2) 1831 {Certificate} 1832 (epoch=2) 1833 {CertificateVerify} 1834 (epoch=2) 1835 {Finished} 1836 (epoch=2) 1837 Record 2 1838 {Certificate} --------> 1839 (epoch=2) 1840 {CertificateVerify} 1841 (epoch=2) 1842 {Finished} 1843 (epoch=2) 1844 Record 2 1845 <-------- [ACK] 1846 (epoch=3) 1847 Record 3 1848 [Application Data] --------> 1849 (epoch=3) 1850 Record 3 1851 <-------- [Application Data] 1852 (epoch=3) 1854 Some time later ... 1855 (Post-Handshake Message Exchange) 1856 Record 4 1858 <-------- [NewSessionTicket] 1859 (epoch=3) 1860 Record 4 1861 [ACK] --------> 1862 (epoch=3) 1864 Some time later ... 1865 (Rekeying) 1866 Record 5 1867 <-------- [Application Data] 1868 (epoch=4) 1869 Record 5 1870 [Application Data] --------> 1871 (epoch=4) 1873 Figure 13: Example DTLS exchange with epoch information 1875 7. ACK Message 1877 The ACK message is used by an endpoint to indicate which handshake 1878 records it has received and processed from the other side. ACK is 1879 not a handshake message but is rather a separate content type, with 1880 code point TBD (proposed, 25). This avoids having ACK being added to 1881 the handshake transcript. Note that ACKs can still be sent in the 1882 same UDP datagram as handshake records. 1884 struct { 1885 RecordNumber record_numbers<0..2^16-1>; 1886 } ACK; 1888 record_numbers: a list of the records containing handshake messages 1889 in the current flight which the endpoint has received and either 1890 processed or buffered, in numerically increasing order. 1892 Implementations MUST NOT acknowledge records containing handshake 1893 messages or fragments which have not been processed or buffered. 1894 Otherwise, deadlock can ensue. As an example, implementations MUST 1895 NOT send ACKs for handshake messages which they discard because they 1896 are not the next expected message. 1898 During the handshake, ACKs only cover the current outstanding flight 1899 (this is possible because DTLS is generally a lockstep protocol). 1900 Thus, an ACK from the server would not cover both the ClientHello and 1901 the client's Certificate. Implementations can accomplish this by 1902 clearing their ACK list upon receiving the start of the next flight. 1904 After the handshake, ACKs SHOULD be sent once for each received and 1905 processed handshake record (potentially subject to some delay) and 1906 MAY cover more than one flight. This includes records containing 1907 messages which are discarded because a previous copy has been 1908 received. 1910 During the handshake, ACK records MUST be sent with an epoch that is 1911 equal to or higher than the record which is being acknowledged. Note 1912 that some care is required when processing flights spanning multiple 1913 epochs. For instance, if the client receives only the Server Hello 1914 and Certificate and wishes to ACK them in a single record, it must do 1915 so in epoch 2, as it is required to use an epoch greater than or 1916 equal to 2 and cannot yet send with any greater epoch. 1917 Implementations SHOULD simply use the highest current sending epoch, 1918 which will generally be the highest available. After the handshake, 1919 implementations MUST use the highest available sending epoch. 1921 7.1. Sending ACKs 1923 When an implementation detects a disruption in the receipt of the 1924 current incoming flight, it SHOULD generate an ACK that covers the 1925 messages from that flight which it has received and processed so far. 1926 Implementations have some discretion about which events to treat as 1927 signs of disruption, but it is RECOMMENDED that they generate ACKs 1928 under two circumstances: 1930 * When they receive a message or fragment which is out of order, 1931 either because it is not the next expected message or because it 1932 is not the next piece of the current message. 1934 * When they have received part of a flight and do not immediately 1935 receive the rest of the flight (which may be in the same UDP 1936 datagram). A reasonable approach here is to set a timer for 1/4 1937 the current retransmit timer value when the first record in the 1938 flight is received and then send an ACK when that timer expires. 1940 In general, flights MUST be ACKed unless they are implicitly 1941 acknowledged. In the present specification the following flights are 1942 implicitly acknowledged by the receipt of the next flight, which 1943 generally immediately follows the flight, 1945 1. Handshake flights other than the client's final flight of the 1946 main handshake. 1948 2. The server's post-handshake CertificateRequest. 1950 ACKs SHOULD NOT be sent for these flights unless generating the 1951 responding flight takes significant time. In this case, 1952 implementations MAY send explicit ACKs for the complete received 1953 flight even though it will eventually also be implicitly acknowledged 1954 through the responding flight. A notable example for this is the 1955 case of client authentication in constrained environments, where 1956 generating the CertificateVerify message can take considerable time 1957 on the client. All other flights MUST be ACKed. Implementations MAY 1958 acknowledge the records corresponding to each transmission of each 1959 flight or simply acknowledge the most recent one. In general, 1960 implementations SHOULD ACK as many received packets as can fit into 1961 the ACK record, as this provides the most complete information and 1962 thus reduces the chance of spurious retransmission; if space is 1963 limited, implementations SHOULD favor including records which have 1964 not yet been acknowledged. 1966 Note: While some post-handshake messages follow a request/response 1967 pattern, this does not necessarily imply receipt. For example, a 1968 KeyUpdate sent in response to a KeyUpdate with request_update set to 1969 'update_requested' does not implicitly acknowledge the earlier 1970 KeyUpdate message because the two KeyUpdate messages might have 1971 crossed in flight. 1973 ACKs MUST NOT be sent for other records of any content type other 1974 than handshake or for records which cannot be unprotected. 1976 Note that in some cases it may be necessary to send an ACK which does 1977 not contain any record numbers. For instance, a client might receive 1978 an EncryptedExtensions message prior to receiving a ServerHello. 1979 Because it cannot decrypt the EncryptedExtensions, it cannot safely 1980 acknowledge it (as it might be damaged). If the client does not send 1981 an ACK, the server will eventually retransmit its first flight, but 1982 this might take far longer than the actual round trip time between 1983 client and server. Having the client send an empty ACK shortcuts 1984 this process. 1986 7.2. Receiving ACKs 1988 When an implementation receives an ACK, it SHOULD record that the 1989 messages or message fragments sent in the records being ACKed were 1990 received and omit them from any future retransmissions. Upon receipt 1991 of an ACK that leaves it with only some messages from a flight having 1992 been acknowledged an implementation SHOULD retransmit the 1993 unacknowledged messages or fragments. Note that this requires 1994 implementations to track which messages appear in which records. 1995 Once all the messages in a flight have been acknowledged, the 1996 implementation MUST cancel all retransmissions of that flight. 1997 Implementations MUST treat a record as having been acknowledged if it 1998 appears in any ACK; this prevents spurious retransmission in cases 1999 where a flight is very large and the receiver is forced to elide 2000 acknowledgements for records which have already been ACKed. As noted 2001 above, the receipt of any record responding to a given flight MUST be 2002 taken as an implicit acknowledgement for the entire flight. 2004 7.3. Design Rationale 2006 ACK messages are used in two circumstances, namely : 2008 * on sign of disruption, or lack of progress, and 2010 * to indicate complete receipt of the last flight in a handshake. 2012 In the first case the use of the ACK message is optional because the 2013 peer will retransmit in any case and therefore the ACK just allows 2014 for selective retransmission, as opposed to the whole flight 2015 retransmission in previous versions of DTLS. For instance in the 2016 flow shown in Figure 11 if the client does not send the ACK message 2017 when it received record 1 indicating loss of record 0, the entire 2018 flight would be retransmitted. When DTLS 1.3 is used in deployments 2019 with lossy networks, such as low-power, long range radio networks as 2020 well as low-power mesh networks, the use of ACKs is recommended. 2022 The use of the ACK for the second case is mandatory for the proper 2023 functioning of the protocol. For instance, the ACK message sent by 2024 the client in Figure 12, acknowledges receipt and processing of 2025 record 4 (containing the NewSessionTicket message) and if it is not 2026 sent the server will continue retransmission of the NewSessionTicket 2027 indefinitely until its transmission cap is reached. 2029 8. Key Updates 2031 As with TLS 1.3, DTLS 1.3 implementations send a KeyUpdate message to 2032 indicate that they are updating their sending keys. As with other 2033 handshake messages with no built-in response, KeyUpdates MUST be 2034 acknowledged. In order to facilitate epoch reconstruction 2035 Section 4.2.2 implementations MUST NOT send records with the new keys 2036 or send a new KeyUpdate until the previous KeyUpdate has been 2037 acknowledged (this avoids having too many epochs in active use). 2039 Due to loss and/or re-ordering, DTLS 1.3 implementations may receive 2040 a record with an older epoch than the current one (the requirements 2041 above preclude receiving a newer record). They SHOULD attempt to 2042 process those records with that epoch (see Section 4.2.2 for 2043 information on determining the correct epoch), but MAY opt to discard 2044 such out-of-epoch records. 2046 Due to the possibility of an ACK message for a KeyUpdate being lost 2047 and thereby preventing the sender of the KeyUpdate from updating its 2048 keying material, receivers MUST retain the pre-update keying material 2049 until receipt and successful decryption of a message using the new 2050 keys. 2052 Figure 14 shows an example exchange illustrating that a successful 2053 ACK processing updates the keys of the KeyUpdate message sender, 2054 which is reflected in the change of epoch values. 2056 Client Server 2058 /-------------------------------------------\ 2059 | | 2060 | Initial Handshake | 2061 \-------------------------------------------/ 2063 [Application Data] --------> 2064 (epoch=3) 2066 <-------- [Application Data] 2067 (epoch=3) 2069 /-------------------------------------------\ 2070 | | 2071 | Some time later ... | 2072 \-------------------------------------------/ 2074 [Application Data] --------> 2075 (epoch=3) 2077 [KeyUpdate] 2078 (+ update_requested --------> 2079 (epoch 3) 2081 <-------- [Application Data] 2082 (epoch=3) 2084 [Ack] 2085 <-------- (epoch=3) 2087 [Application Data] 2088 (epoch=4) --------> 2090 <-------- [KeyUpdate] 2091 (epoch=3) 2093 [Ack] --------> 2094 (epoch=4) 2096 <-------- [Application Data] 2097 (epoch=4) 2099 Figure 14: Example DTLS Key Update 2101 9. Connection ID Updates 2103 If the client and server have negotiated the "connection_id" 2104 extension [I-D.ietf-tls-dtls-connection-id], either side can send a 2105 new CID which it wishes the other side to use in a NewConnectionId 2106 message. 2108 enum { 2109 cid_immediate(0), cid_spare(1), (255) 2110 } ConnectionIdUsage; 2112 opaque ConnectionId<0..2^8-1>; 2114 struct { 2115 ConnectionIds cids<0..2^16-1>; 2116 ConnectionIdUsage usage; 2117 } NewConnectionId; 2119 cid Indicates the set of CIDs which the sender wishes the peer to 2120 use. 2122 usage Indicates whether the new CIDs should be used immediately or 2123 are spare. If usage is set to "cid_immediate", then one of the 2124 new CID MUST be used immediately for all future records. If it is 2125 set to "cid_spare", then either existing or new CID MAY be used. 2127 Endpoints SHOULD use receiver-provided CIDs in the order they were 2128 provided. Endpoints MUST NOT have more than one NewConnectionId 2129 message outstanding. 2131 Implementations which either did not negotiate the "connection_id" 2132 extension or which have negotiated receiving an empty CID MUST NOT 2133 send NewConnectionId. Implementations MUST NOT send 2134 RequestConnectionId when sending an empty connection ID. 2135 Implementations which detect a violation of these rules MUST 2136 terminate the connection with an "unexpected_message" alert. 2138 Implementations SHOULD use a new CID whenever sending on a new path, 2139 and SHOULD request new CIDs for this purpose if path changes are 2140 anticipated. 2142 struct { 2143 uint8 num_cids; 2144 } RequestConnectionId; 2146 num_cids The number of CIDs desired. 2148 Endpoints SHOULD respond to RequestConnectionId by sending a 2149 NewConnectionId with usage "cid_spare" containing num_cid CIDs soon 2150 as possible. Endpoints MUST NOT send a RequestConnectionId message 2151 when an existing request is still unfulfilled; this implies that 2152 endpoints needs to request new CIDs well in advance. An endpoint MAY 2153 handle requests, which it considers excessive, by responding with a 2154 NewConnectionId message containing fewer than num_cid CIDs, including 2155 no CIDs at all. Endpoints MAY handle an excessive number of 2156 RequestConnectionId messages by terminating the connection using a 2157 "too_many_cids_requested" (alert number 52) alert. 2159 Endpoints MUST NOT send either of these messages if they did not 2160 negotiate a CID. If an implementation receives these messages when 2161 CIDs were not negotiated, it MUST abort the connection with an 2162 unexpected_message alert. 2164 9.1. Connection ID Example 2166 Below is an example exchange for DTLS 1.3 using a single CID in each 2167 direction. 2169 Note: The connection_id extension is defined in 2170 [I-D.ietf-tls-dtls-connection-id], which is used in ClientHello and 2171 ServerHello messages. 2173 Client Server 2174 ------ ------ 2176 ClientHello 2177 (connection_id=5) 2178 --------> 2180 <-------- HelloRetryRequest 2181 (cookie) 2183 ClientHello --------> 2184 (connection_id=5) 2185 +cookie 2187 <-------- ServerHello 2188 (connection_id=100) 2189 EncryptedExtensions 2190 (cid=5) 2191 Certificate 2192 (cid=5) 2193 CertificateVerify 2194 (cid=5) 2195 Finished 2196 (cid=5) 2198 Certificate --------> 2199 (cid=100) 2200 CertificateVerify 2201 (cid=100) 2202 Finished 2203 (cid=100) 2204 <-------- Ack 2205 (cid=5) 2207 Application Data ========> 2208 (cid=100) 2209 <======== Application Data 2210 (cid=5) 2212 Figure 15: Example DTLS 1.3 Exchange with CIDs 2214 If no CID is negotiated, then the receiver MUST reject any records it 2215 receives that contain a CID. 2217 10. Application Data Protocol 2219 Application data messages are carried by the record layer and are 2220 split into records and encrypted based on the current connection 2221 state. The messages are treated as transparent data to the record 2222 layer. 2224 11. Security Considerations 2226 Security issues are discussed primarily in [TLS13]. 2228 The primary additional security consideration raised by DTLS is that 2229 of denial of service by excessive resource consumption. DTLS 2230 includes a cookie exchange designed to protect against denial of 2231 service. However, implementations that do not use this cookie 2232 exchange are still vulnerable to DoS. In particular, DTLS servers 2233 that do not use the cookie exchange may be used as attack amplifiers 2234 even if they themselves are not experiencing DoS. Therefore, DTLS 2235 servers SHOULD use the cookie exchange unless there is good reason to 2236 believe that amplification is not a threat in their environment. 2237 Clients MUST be prepared to do a cookie exchange with every 2238 handshake. 2240 DTLS implementations MUST NOT update the address they send to in 2241 response to packets from a different address unless they first 2242 perform some reachability test; no such test is defined in this 2243 specification. Even with such a test, an active on-path adversary 2244 can also black-hole traffic or create a reflection attack against 2245 third parties because a DTLS peer has no means to distinguish a 2246 genuine address update event (for example, due to a NAT rebinding) 2247 from one that is malicious. This attack is of concern when there is 2248 a large asymmetry of request/response message sizes. 2250 With the exception of order protection and non-replayability, the 2251 security guarantees for DTLS 1.3 are the same as TLS 1.3. While TLS 2252 always provides order protection and non-replayability, DTLS does not 2253 provide order protection and may not provide replay protection. 2255 Unlike TLS implementations, DTLS implementations SHOULD NOT respond 2256 to invalid records by terminating the connection. 2258 The security and privacy properties of the CID for DTLS 1.3 builds on 2259 top of what is described for DTLS 1.2 in 2260 [I-D.ietf-tls-dtls-connection-id]. There are, however, several 2261 differences: 2263 * In both versions of DTLS extension negotiation is used to agree on 2264 the use of the CID feature and the CID values. In both versions 2265 the CID is carried in the DTLS record header (if negotiated). 2266 However, the way the CID is included in the record header differs 2267 between the two versions. 2269 * The use of the Post-Handshake message allows the client and the 2270 server to update their CIDs and those values are exchanged with 2271 confidentiality protection. 2273 * The ability to use multiple CIDs allows for improved privacy 2274 properties in multi-homed scenarios. When only a single CID is in 2275 use on multiple paths from such a host, an adversary can correlate 2276 the communication interaction across paths, which adds further 2277 privacy concerns. In order to prevent this, implementations 2278 SHOULD attempt to use fresh CIDs whenever they change local 2279 addresses or ports (though this is not always possible to detect). 2280 The RequestConnectionId message can be used by a peer to ask for 2281 new CIDs to ensure that a pool of suitable CIDs is available. 2283 * The mechanism for encrypting sequence numbers (Section 4.2.3) 2284 prevents trivial tracking by on-path adversaries that attempt to 2285 correlate the pattern of sequence numbers received on different 2286 paths; such tracking could occur even when different CIDs are used 2287 on each path, in the absence of sequence number encryption. 2288 Switching CIDs based on certain events, or even regularly, helps 2289 against tracking by on-path adversaries. Note that sequence 2290 number encryption is used for all encrypted DTLS 1.3 records 2291 irrespective of whether a CID is used or not. Unlike the sequence 2292 number, the epoch is not encrypted because it acts as a key 2293 identifier, which may improve correlation of packets from a single 2294 connection across different network paths. 2296 * DTLS 1.3 encrypts handshake messages much earlier than in previous 2297 DTLS versions. Therefore, less information identifying the DTLS 2298 client, such as the client certificate, is available to an on-path 2299 adversary. 2301 12. Changes since DTLS 1.2 2303 Since TLS 1.3 introduces a large number of changes with respect to 2304 TLS 1.2, the list of changes from DTLS 1.2 to DTLS 1.3 is equally 2305 large. For this reason this section focuses on the most important 2306 changes only. 2308 * New handshake pattern, which leads to a shorter message exchange 2309 * Only AEAD ciphers are supported. Additional data calculation has 2310 been simplified. 2312 * Removed support for weaker and older cryptographic algorithms 2314 * HelloRetryRequest of TLS 1.3 used instead of HelloVerifyRequest 2316 * More flexible ciphersuite negotiation 2318 * New session resumption mechanism 2320 * PSK authentication redefined 2322 * New key derivation hierarchy utilizing a new key derivation 2323 construct 2325 * Improved version negotiation 2327 * Optimized record layer encoding and thereby its size 2329 * Added CID functionality 2331 * Sequence numbers are encrypted. 2333 13. IANA Considerations 2335 IANA is requested to allocate a new value in the "TLS ContentType" 2336 registry for the ACK message, defined in Section 7, with content type 2337 26. The value for the "DTLS-OK" column is "Y". IANA is requested to 2338 reserve the content type range 32-63 so that content types in this 2339 range are not allocated. 2341 IANA is requested to allocate "the too_many_cids_requested" alert in 2342 the "TLS Alerts" registry with value 52. 2344 IANA is requested to allocate two values in the "TLS Handshake Type" 2345 registry, defined in [TLS13], for RequestConnectionId (TBD), and 2346 NewConnectionId (TBD), as defined in this document. The value for 2347 the "DTLS-OK" columns are "Y". 2349 IANA is requested to add this RFC as a reference to the TLS Cipher 2350 Suite Registry. 2352 14. References 2354 14.1. Normative References 2356 [CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 2357 Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, 2358 . 2360 [I-D.ietf-tls-dtls-connection-id] 2361 Rescorla, E., Tschofenig, H., and T. Fossati, "Connection 2362 Identifiers for DTLS 1.2", Work in Progress, Internet- 2363 Draft, draft-ietf-tls-dtls-connection-id-09, 17 January 2364 2021, . 2367 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2368 DOI 10.17487/RFC0768, August 1980, 2369 . 2371 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2372 RFC 793, DOI 10.17487/RFC0793, September 1981, 2373 . 2375 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2376 DOI 10.17487/RFC1191, November 1990, 2377 . 2379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2380 Requirement Levels", BCP 14, RFC 2119, 2381 DOI 10.17487/RFC2119, March 1997, 2382 . 2384 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2385 Control Message Protocol (ICMPv6) for the Internet 2386 Protocol Version 6 (IPv6) Specification", STD 89, 2387 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2388 . 2390 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 2391 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 2392 . 2394 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 2395 "Computing TCP's Retransmission Timer", RFC 6298, 2396 DOI 10.17487/RFC6298, June 2011, 2397 . 2399 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2400 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2401 May 2017, . 2403 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2404 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2405 . 2407 14.2. Informative References 2409 [AEBounds] Luykx, A. and K. Paterson, "Limits on Authenticated 2410 Encryption Use in TLS", 8 March 2016, 2411 . 2413 [CCM-ANALYSIS] 2414 Jonsson, J., "On the Security of CTR + CBC-MAC", Selected 2415 Areas in Cryptography pp. 76-93, 2416 DOI 10.1007/3-540-36492-7_7, 2003, 2417 . 2419 [DEPRECATE] 2420 Moriarty, K. and S. Farrell, "Deprecating TLSv1.0 and 2421 TLSv1.1", Work in Progress, Internet-Draft, draft-ietf- 2422 tls-oldversions-deprecate-11, 15 December 2020, 2423 . 2426 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 2427 Protocol", RFC 2522, DOI 10.17487/RFC2522, March 1999, 2428 . 2430 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 2431 RFC 4303, DOI 10.17487/RFC4303, December 2005, 2432 . 2434 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2435 Congestion Control Protocol (DCCP)", RFC 4340, 2436 DOI 10.17487/RFC4340, March 2006, 2437 . 2439 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 2440 (TLS) Protocol Version 1.1", RFC 4346, 2441 DOI 10.17487/RFC4346, April 2006, 2442 . 2444 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2445 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 2446 . 2448 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 2449 RFC 4960, DOI 10.17487/RFC4960, September 2007, 2450 . 2452 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 2453 the Datagram Congestion Control Protocol (DCCP)", 2454 RFC 5238, DOI 10.17487/RFC5238, May 2008, 2455 . 2457 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2458 (TLS) Protocol Version 1.2", RFC 5246, 2459 DOI 10.17487/RFC5246, August 2008, 2460 . 2462 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2463 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2464 January 2012, . 2466 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 2467 Kivinen, "Internet Key Exchange Protocol Version 2 2468 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2469 2014, . 2471 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2472 "Recommendations for Secure Use of Transport Layer 2473 Security (TLS) and Datagram Transport Layer Security 2474 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2475 2015, . 2477 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 2478 (TLS) Cached Information Extension", RFC 7924, 2479 DOI 10.17487/RFC7924, July 2016, 2480 . 2482 [RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme 2483 Updates for Secure Real-time Transport Protocol (SRTP) 2484 Extension for Datagram Transport Layer Security (DTLS)", 2485 RFC 7983, DOI 10.17487/RFC7983, September 2016, 2486 . 2488 [RFC8879] Ghedini, A. and V. Vasiliev, "TLS Certificate 2489 Compression", RFC 8879, DOI 10.17487/RFC8879, December 2490 2020, . 2492 [ROBUST] Fischlin, M., Günther, F., and C. Janson, "Robust 2493 Channels: Handling Unreliable Networks in the Record 2494 Layers of QUIC and DTLS 1.3", 15 June 2020, 2495 . 2497 Appendix A. Protocol Data Structures and Constant Values 2499 This section provides the normative protocol types and constants 2500 definitions. 2502 A.1. Record Layer 2504 struct { 2505 ContentType type; 2506 ProtocolVersion legacy_record_version; 2507 uint16 epoch = 0 2508 uint48 sequence_number; 2509 uint16 length; 2510 opaque fragment[DTLSPlaintext.length]; 2511 } DTLSPlaintext; 2513 struct { 2514 opaque content[DTLSPlaintext.length]; 2515 ContentType type; 2516 uint8 zeros[length_of_padding]; 2517 } DTLSInnerPlaintext; 2519 struct { 2520 opaque unified_hdr[variable]; 2521 opaque encrypted_record[length]; 2522 } DTLSCiphertext; 2524 0 1 2 3 4 5 6 7 2525 +-+-+-+-+-+-+-+-+ 2526 |0|0|1|C|S|L|E E| 2527 +-+-+-+-+-+-+-+-+ 2528 | Connection ID | Legend: 2529 | (if any, | 2530 / length as / C - Connection ID (CID) present 2531 | negotiated) | S - Sequence number length 2532 +-+-+-+-+-+-+-+-+ L - Length present 2533 | 8 or 16 bit | E - Epoch 2534 |Sequence Number| 2535 +-+-+-+-+-+-+-+-+ 2536 | 16 bit Length | 2537 | (if present) | 2538 +-+-+-+-+-+-+-+-+ 2540 struct { 2541 uint16 epoch; 2542 uint48 sequence_number; 2543 } RecordNumber; 2545 A.2. Handshake Protocol 2547 enum { 2548 hello_request_RESERVED(0), 2549 client_hello(1), 2550 server_hello(2), 2551 hello_verify_request_RESERVED(3), 2552 new_session_ticket(4), 2553 end_of_early_data(5), 2554 hello_retry_request_RESERVED(6), 2555 encrypted_extensions(8), 2556 certificate(11), 2557 server_key_exchange_RESERVED(12), 2558 certificate_request(13), 2559 server_hello_done_RESERVED(14), 2560 certificate_verify(15), 2561 client_key_exchange_RESERVED(16), 2562 finished(20), 2563 certificate_url_RESERVED(21), 2564 certificate_status_RESERVED(22), 2565 supplemental_data_RESERVED(23), 2566 key_update(24), 2567 message_hash(254), 2568 (255) 2569 } HandshakeType; 2571 struct { 2572 HandshakeType msg_type; /* handshake type */ 2573 uint24 length; /* bytes in message */ 2574 uint16 message_seq; /* DTLS-required field */ 2575 uint24 fragment_offset; /* DTLS-required field */ 2576 uint24 fragment_length; /* DTLS-required field */ 2577 select (HandshakeType) { 2578 case client_hello: ClientHello; 2579 case server_hello: ServerHello; 2580 case end_of_early_data: EndOfEarlyData; 2581 case encrypted_extensions: EncryptedExtensions; 2582 case certificate_request: CertificateRequest; 2583 case certificate: Certificate; 2584 case certificate_verify: CertificateVerify; 2585 case finished: Finished; 2586 case new_session_ticket: NewSessionTicket; 2587 case key_update: KeyUpdate; 2588 } body; 2589 } Handshake; 2591 uint16 ProtocolVersion; 2592 opaque Random[32]; 2593 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 2595 struct { 2596 ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2 2597 Random random; 2598 opaque legacy_session_id<0..32>; 2599 opaque legacy_cookie<0..2^8-1>; // DTLS 2600 CipherSuite cipher_suites<2..2^16-2>; 2601 opaque legacy_compression_methods<1..2^8-1>; 2602 Extension extensions<8..2^16-1>; 2603 } ClientHello; 2605 A.3. ACKs 2607 struct { 2608 RecordNumber record_numbers<0..2^16-1>; 2609 } ACK; 2611 A.4. Connection ID Management 2613 enum { 2614 cid_immediate(0), cid_spare(1), (255) 2615 } ConnectionIdUsage; 2617 opaque ConnectionId<0..2^8-1>; 2619 struct { 2620 ConnectionIds cids<0..2^16-1>; 2621 ConnectionIdUsage usage; 2622 } NewConnectionId; 2624 struct { 2625 uint8 num_cids; 2626 } RequestConnectionId; 2628 Appendix B. Analysis of Limits on CCM Usage 2630 TLS [TLS13] and [AEBounds] do not specify limits on key usage for 2631 AEAD_AES_128_CCM. However, any AEAD that is used with DTLS requires 2632 limits on use that ensure that both confidentiality and integrity are 2633 preserved. This section documents that analysis for 2634 AEAD_AES_128_CCM. 2636 [CCM-ANALYSIS] is used as the basis of this analysis. The results of 2637 that analysis are used to derive usage limits that are based on those 2638 chosen in [TLS13]. 2640 This analysis uses symbols for multiplication (*), division (/), and 2641 exponentiation (^), plus parentheses for establishing precedence. 2642 The following symbols are also used: 2644 t: The size of the authentication tag in bits. For this cipher, t 2645 is 128. 2647 n: The size of the block function in bits. For this cipher, n is 2648 128. 2650 l: The number of blocks in each packet (see below). 2652 q: The number of genuine packets created and protected by endpoints. 2653 This value is the bound on the number of packets that can be 2654 protected before updating keys. 2656 v: The number of forged packets that endpoints will accept. This 2657 value is the bound on the number of forged packets that an 2658 endpoint can reject before updating keys. 2660 The analysis of AEAD_AES_128_CCM relies on a count of the number of 2661 block operations involved in producing each message. For simplicity, 2662 and to match the analysis of other AEAD functions in [AEBounds], this 2663 analysis assumes a packet length of 2^10 blocks and a packet size 2664 limit of 2^14 bytes. 2666 For AEAD_AES_128_CCM, the total number of block cipher operations is 2667 the sum of: the length of the associated data in blocks, the length 2668 of the ciphertext in blocks, and the length of the plaintext in 2669 blocks, plus 1. In this analysis, this is simplified to a value of 2670 twice the maximum length of a record in blocks (that is, "2l = 2671 2^11"). This simplification is based on the associated data being 2672 limited to one block. 2674 B.1. Confidentiality Limits 2676 For confidentiality, Theorem 2 in [CCM-ANALYSIS] establishes that an 2677 attacker gains a distinguishing advantage over an ideal pseudorandom 2678 permutation (PRP) of no more than: 2680 (2l * q)^2 / 2^n 2682 For a target advantage of 2^-60, which matches that used by [TLS13], 2683 this results in the relation: 2685 q <= 2^23 2686 That is, endpoints cannot protect more than 2^23 packets with the 2687 same set of keys without causing an attacker to gain an larger 2688 advantage than the target of 2^-60. 2690 B.2. Integrity Limits 2692 For integrity, Theorem 1 in [CCM-ANALYSIS] establishes that an 2693 attacker gains an advantage over an ideal PRP of no more than: 2695 v / 2^t + (2l * (v + q))^2 / 2^n 2697 The goal is to limit this advantage to 2^-57, to match the target in 2698 [TLS13]. As "t" and "n" are both 128, the first term is negligible 2699 relative to the second, so that term can be removed without a 2700 significant effect on the result. This produces the relation: 2702 v + q <= 2^24.5 2704 Using the previously-established value of 2^23 for "q" and rounding, 2705 this leads to an upper limit on "v" of 2^23.5. That is, endpoints 2706 cannot attempt to authenticate more than 2^23.5 packets with the same 2707 set of keys without causing an attacker to gain an larger advantage 2708 than the target of 2^-57. 2710 B.3. Limits for AEAD_AES_128_CCM_8 2712 The TLS_AES_128_CCM_8_SHA256 cipher suite uses the AEAD_AES_128_CCM_8 2713 function, which uses a short authentication tag (that is, t=64). 2715 The confidentiality limits of AEAD_AES_128_CCM_8 are the same as 2716 those for AEAD_AES_128_CCM, as this does not depend on the tag 2717 length; see Appendix B.1. 2719 The shorter tag length of 64 bits means that the simplification used 2720 in Appendix B.2 does not apply to AEAD_AES_128_CCM_8. If the goal is 2721 to preserve the same margins as other cipher suites, then the limit 2722 on forgeries is largely dictated by the first term of the advantage 2723 formula: 2725 v <= 2^7 2727 As this represents attempts to fail authentication, applying this 2728 limit might be feasible in some environments. However, applying this 2729 limit in an implementation intended for general use exposes 2730 connections to an inexpensive denial of service attack. 2732 This analysis supports the view that TLS_AES_128_CCM_8_SHA256 is not 2733 suitable for general use. Specifically, TLS_AES_128_CCM_8_SHA256 2734 cannot be used without additional measures to prevent forgery of 2735 records, or to mitigate the effect of forgeries. This might require 2736 understanding the constraints that exist in a particular deployment 2737 or application. For instance, it might be possible to set a 2738 different target for the advantage an attacker gains based on an 2739 understanding of the constraints imposed on a specific usage of DTLS. 2741 Appendix C. History 2743 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 2745 (*) indicates a change that may affect interoperability. 2747 IETF Drafts 2749 draft-40 2751 - Clarified encrypted_record structure in DTLS 1.3 record layer 2752 - Added description of the demultiplexing process 2753 - Added text about the DTLS 1.2 and DTLS 1.3 CID mechanism 2754 - Forbid going from an empty CID to a non-empty CID (*) 2755 - Add warning about certificates and congestion 2756 - Use DTLS style version values, even for DTLS 1.3 (*) 2757 - Describe how to distinguish DTLS 1.2 and DTLS 1.3 connections 2758 - Updated examples 2759 - Included editorial improvements from Ben Kaduk 2760 - Removed stale text about out-of-epoch records 2761 - Added clarifications around when ACKs are sent 2762 - Noted that alerts are unreliable 2763 - Clarify when you can reset the timer 2764 - Indicated that records with bogus epochs should be discarded 2765 - Relax age out text 2766 - Updates to cookie text 2767 - Require that cipher suites define a record number encryption algorithm 2768 - Clean up use of connection and association 2769 - Reference tls-old-versions-deprecate 2771 draft-39 - Updated Figure 4 due to misalignment with Figure 3 content 2773 draft-38 - Ban implicit connection IDs (*) - ACKs are processed as 2774 the union. 2776 draft-37: - Fix the other place where we have ACK. 2778 draft-36: - Some editorial changes. - Changed the content type to not 2779 conflict with existing allocations (*) 2780 draft-35: - I-D.ietf-tls-dtls-connection-id became a normative 2781 reference - Removed duplicate reference to I-D.ietf-tls-dtls- 2782 connection-id. - Fix figure 11 to have the right numbers andno cookie 2783 in message 1. - Clarify when you can ACK. - Clarify additional data 2784 computation. 2786 draft-33: - Key separation between TLS and DTLS. Issue #72. 2788 draft-32: - Editorial improvements and clarifications. 2790 draft-31: - Editorial improvements in text and figures. - Added 2791 normative reference to ChaCha20 and Poly1305. 2793 draft-30: - Changed record format - Added text about end of early 2794 data - Changed format of the Connection ID Update message - Added 2795 Appendix A "Protocol Data Structures and Constant Values" 2797 draft-29: - Added support for sequence number encryption - Update to 2798 new record format - Emphasize that compatibility mode isn't used. 2800 draft-28: - Version bump to align with TLS 1.3 pre-RFC version. 2802 draft-27: - Incorporated unified header format. - Added support for 2803 CIDs. 2805 draft-04 - 26: - Submissions to align with TLS 1.3 draft versions 2807 draft-03 - Only update keys after KeyUpdate is ACKed. 2809 draft-02 - Shorten the protected record header and introduce an 2810 ultra-short version of the record header. - Reintroduce KeyUpdate, 2811 which works properly now that we have ACK. - Clarify the ACK rules. 2813 draft-01 - Restructured the ACK to contain a list of records and also 2814 be a record rather than a handshake message. 2816 draft-00 - First IETF Draft 2818 Personal Drafts draft-01 - Alignment with version -19 of the TLS 1.3 2819 specification 2821 draft-00 2823 * Initial version using TLS 1.3 as a baseline. 2825 * Use of epoch values instead of KeyUpdate message 2826 * Use of cookie extension instead of cookie field in ClientHello and 2827 HelloVerifyRequest messages 2829 * Added ACK message 2831 * Text about sequence number handling 2833 Appendix D. Working Group Information 2835 RFC EDITOR: PLEASE REMOVE THIS SECTION. 2837 The discussion list for the IETF TLS working group is located at the 2838 e-mail address tls@ietf.org (mailto:tls@ietf.org). Information on 2839 the group and information on how to subscribe to the list is at 2840 https://www1.ietf.org/mailman/listinfo/tls 2841 (https://www1.ietf.org/mailman/listinfo/tls) 2843 Archives of the list can be found at: https://www.ietf.org/mail- 2844 archive/web/tls/current/index.html (https://www.ietf.org/mail- 2845 archive/web/tls/current/index.html) 2847 Appendix E. Contributors 2849 Many people have contributed to previous DTLS versions and they are 2850 acknowledged in prior versions of DTLS specifications or in the 2851 referenced specifications. The sequence number encryption concept is 2852 taken from the QUIC specification. We would like to thank the 2853 authors of the QUIC specification for their work. Felix Guenther and 2854 Martin Thomson contributed the analysis in Appendix B. 2856 In addition, we would like to thank: 2858 * David Benjamin 2859 Google 2860 davidben@google.com 2862 * Thomas Fossati 2863 Arm Limited 2864 Thomas.Fossati@arm.com 2866 * Tobias Gondrom 2867 Huawei 2868 tobias.gondrom@gondrom.org 2870 * Felix Günther 2871 ETH Zurich 2872 mail@felixguenther.info 2874 * Ilari Liusvaara 2875 Independent 2876 ilariliusvaara@welho.com 2878 * Martin Thomson 2879 Mozilla 2880 martin.thomson@gmail.com 2882 * Christopher A. Wood 2883 Apple Inc. 2884 cawood@apple.com 2886 * Yin Xinxing 2887 Huawei 2888 yinxinxing@huawei.com 2890 * Hanno Becker 2891 Arm Limited 2892 Hanno.Becker@arm.com 2894 Appendix F. Acknowledgements 2896 We would like to thank Jonathan Hammell and Andy Cunningham for their 2897 review comments. 2899 Authors' Addresses 2901 Eric Rescorla 2902 RTFM, Inc. 2904 Email: ekr@rtfm.com 2906 Hannes Tschofenig 2907 Arm Limited 2909 Email: hannes.tschofenig@arm.com 2911 Nagendra Modadugu 2912 Google, Inc. 2914 Email: nagendra@cs.stanford.edu