idnits 2.17.1 draft-ietf-tls-dtls13-41.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 (7 February 2021) is 1174 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 2666 -- Looks like a reference, but probably isn't: '2' on line 2668 == Missing Reference: 'ACK' is mentioned on line 1869, but not defined == Missing Reference: 'NewSessionTicket' is mentioned on line 1866, but not defined == Missing Reference: 'KeyUpdate' is mentioned on line 2101, but not defined == Missing Reference: 'Ack' is mentioned on line 2104, 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) -- Duplicate reference: RFC8446, mentioned in 'TLS13', was also mentioned in 'RFC8446'. == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-09 -- 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 (==), 12 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: 11 August 2021 N. Modadugu 7 Google, Inc. 8 7 February 2021 10 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 11 draft-ietf-tls-dtls13-41 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 11 August 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 73 3. DTLS Design Rationale and Overview . . . . . . . . . . . . . 6 74 3.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 7 75 3.2. Reordering . . . . . . . . . . . . . . . . . . . . . . . 7 76 3.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . 53 120 13. Updates affecting DTLS 1.2 . . . . . . . . . . . . . . . . . 54 121 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 122 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 123 15.1. Normative References . . . . . . . . . . . . . . . . . . 55 124 15.2. Informative References . . . . . . . . . . . . . . . . . 56 125 Appendix A. Protocol Data Structures and Constant Values . . . . 58 126 A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 58 127 A.2. Handshake Protocol . . . . . . . . . . . . . . . . . . . 59 128 A.3. ACKs . . . . . . . . . . . . . . . . . . . . . . . . . . 61 129 A.4. Connection ID Management . . . . . . . . . . . . . . . . 61 130 Appendix B. Analysis of Limits on CCM Usage . . . . . . . . . . 61 131 B.1. Confidentiality Limits . . . . . . . . . . . . . . . . . 62 132 B.2. Integrity Limits . . . . . . . . . . . . . . . . . . . . 63 133 B.3. Limits for AEAD_AES_128_CCM_8 . . . . . . . . . . . . . . 63 134 Appendix C. Implementation Pitfalls . . . . . . . . . . . . . . 64 135 Appendix D. History . . . . . . . . . . . . . . . . . . . . . . 64 136 Appendix E. Working Group Information . . . . . . . . . . . . . 66 137 Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 67 138 Appendix G. Acknowledgements . . . . . . . . . . . . . . . . . . 68 139 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68 141 1. Introduction 143 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH 145 The source for this draft is maintained in GitHub. Suggested changes 146 should be submitted as pull requests at https://github.com/tlswg/ 147 dtls13-spec. Instructions are on that page as well. Editorial 148 changes can be managed in GitHub, but any substantive change should 149 be discussed on the TLS mailing list. 151 The primary goal of the TLS protocol is to establish an 152 authenticated, confidentiality and integrity protected channel 153 between two communicating peers. The TLS protocol is composed of two 154 layers: the TLS Record Protocol and the TLS Handshake Protocol. 155 However, TLS must run over a reliable transport channel - typically 156 TCP [RFC0793]. 158 There are applications that use UDP [RFC0768] as a transport and to 159 offer communication security protection for those applications the 160 Datagram Transport Layer Security (DTLS) protocol has been developed. 161 DTLS is deliberately designed to be as similar to TLS as possible, 162 both to minimize new security invention and to maximize the amount of 163 code and infrastructure reuse. 165 DTLS 1.0 [RFC4347] was originally defined as a delta from TLS 1.1 166 [RFC4346] and DTLS 1.2 [RFC6347] was defined as a series of deltas to 167 TLS 1.2 [RFC5246]. There is no DTLS 1.1; that version number was 168 skipped in order to harmonize version numbers with TLS. This 169 specification describes the most current version of the DTLS protocol 170 based on TLS 1.3 [TLS13]. 172 Implementations that speak both DTLS 1.2 and DTLS 1.3 can 173 interoperate with those that speak only DTLS 1.2 (using DTLS 1.2 of 174 course), just as TLS 1.3 implementations can interoperate with TLS 175 1.2 (see Appendix D of [TLS13] for details). While backwards 176 compatibility with DTLS 1.0 is possible the use of DTLS 1.0 is not 177 recommended as explained in Section 3.1.2 of RFC 7525 [RFC7525] and 178 [DEPRECATE]. 180 2. Conventions and Terminology 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 184 "OPTIONAL" in this document are to be interpreted as described in BCP 185 14 [RFC2119] [RFC8174] when, and only when, they appear in all 186 capitals, as shown here. 188 The following terms are used: 190 * client: The endpoint initiating the DTLS connection. 192 * association: Shared state between two endpoints established with a 193 DTLS handshake. 195 * connection: Synonym for association. 197 * endpoint: Either the client or server of the connection. 199 * handshake: An initial negotiation between client and server that 200 establishes the parameters of the connection. 202 * peer: An endpoint. When discussing a particular endpoint, "peer" 203 refers to the endpoint that is remote to the primary subject of 204 discussion. 206 * receiver: An endpoint that is receiving records. 208 * sender: An endpoint that is transmitting records. 210 * server: The endpoint which did not initiate the DTLS connection. 212 * CID: Connection ID 214 * MSL: Maximum Segment Lifetime 216 The reader is assumed to be familiar with the TLS 1.3 specification 217 since this document is defined as a delta from TLS 1.3. As in TLS 218 1.3 the HelloRetryRequest has the same format as a ServerHello 219 message but for convenience we use the term HelloRetryRequest 220 throughout this document as if it were a distinct message. 222 The reader is also as to be familiar with 223 [I-D.ietf-tls-dtls-connection-id] as this document applies the CID 224 functionality to DTLS 1.3. 226 Figures in this document illustrate various combinations of the DTLS 227 protocol exchanges and the symbols have the following meaning: 229 * '+' indicates noteworthy extensions sent in the previously noted 230 message. 232 * '*' indicates optional or situation-dependent messages/extensions 233 that are not always sent. 235 * '{}' indicates messages protected using keys derived from a 236 [sender]_handshake_traffic_secret. 238 * '[]' indicates messages protected using keys derived from 239 traffic_secret_N. 241 3. DTLS Design Rationale and Overview 243 The basic design philosophy of DTLS is to construct "TLS over 244 datagram transport". Datagram transport does not require nor provide 245 reliable or in-order delivery of data. The DTLS protocol preserves 246 this property for application data. Applications such as media 247 streaming, Internet telephony, and online gaming use datagram 248 transport for communication due to the delay-sensitive nature of 249 transported data. The behavior of such applications is unchanged 250 when the DTLS protocol is used to secure communication, since the 251 DTLS protocol does not compensate for lost or reordered data traffic. 253 TLS cannot be used directly in datagram environments for the 254 following five reasons: 256 1. TLS relies on an implicit sequence number on records. If a 257 record is not received, then the recipient will use the wrong 258 sequence number when attempting to remove record protection from 259 subsequent records. DTLS solves this problem by adding sequence 260 numbers to records. 262 2. The TLS handshake is a lock-step cryptographic protocol. 263 Messages must be transmitted and received in a defined order; any 264 other order is an error. The DTLS handshake includes message 265 sequence numbers to enable reassembly in the correct order in 266 case datagrams are lost or reordered. 268 3. During the handshake, messages are implicitly acknowledged by 269 other handshake messages. Some handshake messages, such as the 270 NewSessionTicket message, do not result in any direct response 271 that would allow the sender to detect loss. DTLS adds an 272 acknowledgment message to enable better loss recovery. 274 4. Handshake messages are potentially larger than can be contained 275 in a single datagram. DTLS adds fields to handshake messages to 276 support fragmentation and reassembly. 278 5. Datagram transport protocols, like UDP, are susceptible to 279 abusive behavior effecting denial of service attacks against 280 nonparticipants. DTLS adds a return-routability check and DTLS 281 1.3 uses the TLS 1.3 HelloRetryRequest message (see Section 5.1 282 for details). 284 3.1. Packet Loss 286 DTLS uses a simple retransmission timer to handle packet loss. 287 Figure 1 demonstrates the basic concept, using the first phase of the 288 DTLS handshake: 290 Client Server 291 ------ ------ 292 ClientHello ------> 294 X<-- HelloRetryRequest 295 (lost) 297 [Timer Expires] 299 ClientHello ------> 300 (retransmit) 302 Figure 1: DTLS retransmission example 304 Once the client has transmitted the ClientHello message, it expects 305 to see a HelloRetryRequest or a ServerHello from the server. 306 However, if the server's message is lost, the client knows that 307 either the ClientHello or the response from the server has been lost 308 and retransmits. When the server receives the retransmission, it 309 knows to retransmit. 311 The server also maintains a retransmission timer and retransmits when 312 that timer expires. 314 Note that timeout and retransmission do not apply to the 315 HelloRetryRequest since this would require creating state on the 316 server. The HelloRetryRequest is designed to be small enough that it 317 will not itself be fragmented, thus avoiding concerns about 318 interleaving multiple HelloRetryRequests. 320 3.2. Reordering 322 In DTLS, each handshake message is assigned a specific sequence 323 number. When a peer receives a handshake message, it can quickly 324 determine whether that message is the next message it expects. If it 325 is, then it processes it. If not, it queues it for future handling 326 once all previous messages have been received. 328 3.3. Fragmentation 330 TLS and DTLS handshake messages can be quite large (in theory up to 331 2^24-1 bytes, in practice many kilobytes). By contrast, UDP 332 datagrams are often limited to less than 1500 bytes if IP 333 fragmentation is not desired. In order to compensate for this 334 limitation, each DTLS handshake message may be fragmented over 335 several DTLS records, each of which is intended to fit in a single 336 UDP datagram. Each DTLS handshake message contains both a fragment 337 offset and a fragment length. Thus, a recipient in possession of all 338 bytes of a handshake message can reassemble the original unfragmented 339 message. 341 3.4. Replay Detection 343 DTLS optionally supports record replay detection. The technique used 344 is the same as in IPsec AH/ESP, by maintaining a bitmap window of 345 received records. Records that are too old to fit in the window and 346 records that have previously been received are silently discarded. 347 The replay detection feature is optional, since packet duplication is 348 not always malicious, but can also occur due to routing errors. 349 Applications may conceivably detect duplicate packets and accordingly 350 modify their data transmission strategy. 352 4. The DTLS Record Layer 354 The DTLS 1.3 record layer is different from the TLS 1.3 record layer 355 and also different from the DTLS 1.2 record layer. 357 1. The DTLSCiphertext structure omits the superfluous version number 358 and type fields. 360 2. DTLS adds an epoch and sequence number to the TLS record header. 361 This sequence number allows the recipient to correctly verify the 362 DTLS MAC. However, the number of bits used for the epoch and 363 sequence number fields in the DTLSCiphertext structure have been 364 reduced from those in previous versions. 366 3. The DTLSCiphertext structure has a variable length header. 368 DTLSPlaintext records are used to send unprotected records and 369 DTLSCiphertext records are used to send protected records. 371 The DTLS record formats are shown below. Unless explicitly stated 372 the meaning of the fields is unchanged from previous TLS / DTLS 373 versions. 375 struct { 376 ContentType type; 377 ProtocolVersion legacy_record_version; 378 uint16 epoch = 0 379 uint48 sequence_number; 380 uint16 length; 381 opaque fragment[DTLSPlaintext.length]; 382 } DTLSPlaintext; 384 struct { 385 opaque content[DTLSPlaintext.length]; 386 ContentType type; 387 uint8 zeros[length_of_padding]; 388 } DTLSInnerPlaintext; 390 struct { 391 opaque unified_hdr[variable]; 392 opaque encrypted_record[length]; 393 } DTLSCiphertext; 395 Figure 2: DTLS 1.3 Record Formats 397 legacy_record_version This value MUST be set to {254, 253} for all 398 records other than the initial ClientHello (i.e., one not 399 generated after a HelloRetryRequest), where it may also be {254, 400 255} for compatibility purposes. It MUST be ignored for all 401 purposes. See [TLS13]; Appendix D.1 for the rationale for this. 403 unified_hdr: The unified header (unified_hdr) is a structure of 404 variable length, as shown in Figure 3. 406 encrypted_record: The AEAD-encrypted form of the serialized 407 DTLSInnerPlaintext structure. 409 0 1 2 3 4 5 6 7 410 +-+-+-+-+-+-+-+-+ 411 |0|0|1|C|S|L|E E| 412 +-+-+-+-+-+-+-+-+ 413 | Connection ID | Legend: 414 | (if any, | 415 / length as / C - Connection ID (CID) present 416 | negotiated) | S - Sequence number length 417 +-+-+-+-+-+-+-+-+ L - Length present 418 | 8 or 16 bit | E - Epoch 419 |Sequence Number| 420 +-+-+-+-+-+-+-+-+ 421 | 16 bit Length | 422 | (if present) | 423 +-+-+-+-+-+-+-+-+ 425 Figure 3: DTLS 1.3 Unified Header 427 Fixed Bits: The three high bits of the first byte of the unified 428 header are set to 001. This ensures that the value will fit 429 within the DTLS region when multiplexing is performed as described 430 in [RFC7983]. It also ensures that distinguishing encrypted DTLS 431 1.3 records from encrypted DTLS 1.2 records is possible when they 432 are carried on the same host/port quartet; such multiplexing is 433 only possible when CIDs [I-D.ietf-tls-dtls-connection-id] are in 434 use, in which case DTLS 1.2 records will have the content type 435 tls12_cid (25). 437 C: The C bit (0x10) is set if the Connection ID is present. 439 S: The S bit (0x08) indicates the size of the sequence number. 0 440 means an 8-bit sequence number, 1 means 16-bit. Implementations 441 MAY mix sequence numbers of different lengths on the same 442 connection. 444 L: The L bit (0x04) is set if the length is present. 446 E: The two low bits (0x03) include the low order two bits of the 447 epoch. 449 Connection ID: Variable length CID. The CID functionality is 450 described in [I-D.ietf-tls-dtls-connection-id]. An example can be 451 found in Section 9.1. 453 Sequence Number: The low order 8 or 16 bits of the record sequence 454 number. This value is 16 bits if the S bit is set to 1, and 8 455 bits if the S bit is 0. 457 Length: Identical to the length field in a TLS 1.3 record. 459 As with previous versions of DTLS, multiple DTLSPlaintext and 460 DTLSCiphertext records can be included in the same underlying 461 transport datagram. 463 Figure 4 illustrates different record headers. 465 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 466 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 467 | Content Type | |0|0|1|1|1|1|E E| |0|0|1|0|0|0|E E| 468 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 469 | 16 bit | | | |8-bit Seq. No. | 470 | Version | / Connection ID / +-+-+-+-+-+-+-+-+ 471 +-+-+-+-+-+-+-+-+ | | | | 472 | 16 bit | +-+-+-+-+-+-+-+-+ | Encrypted | 473 | Epoch | | 16 bit | / Record / 474 +-+-+-+-+-+-+-+-+ |Sequence Number| | | 475 | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 476 | | | 16 bit | 477 | 48 bit | | Length | DTLSCiphertext 478 |Sequence Number| +-+-+-+-+-+-+-+-+ Structure 479 | | | | (minimal) 480 | | | Encrypted | 481 +-+-+-+-+-+-+-+-+ / Record / 482 | 16 bit | | | 483 | Length | +-+-+-+-+-+-+-+-+ 484 +-+-+-+-+-+-+-+-+ 485 | | DTLSCiphertext 486 | | Structure 487 / Fragment / (full) 488 | | 489 +-+-+-+-+-+-+-+-+ 491 DTLSPlaintext 492 Structure 494 Figure 4: DTLS 1.3 Header Examples 496 The length field MAY be omitted by clearing the L bit, which means 497 that the record consumes the entire rest of the datagram in the lower 498 level transport. In this case it is not possible to have multiple 499 DTLSCiphertext format records without length fields in the same 500 datagram. Omitting the length field MUST only be used for the last 501 record in a datagram. Implementations MAY mix records with and 502 without length fields on the same connection. 504 If a connection ID is negotiated, then it MUST be contained in all 505 datagrams. Sending implementations MUST NOT mix records from 506 multiple DTLS associations in the same datagram. If the second or 507 later record has a connection ID which does not correspond to the 508 same association used for previous records, the rest of the datagram 509 MUST be discarded. 511 When expanded, the epoch and sequence number can be combined into an 512 unpacked RecordNumber structure, as shown below: 514 struct { 515 uint16 epoch; 516 uint48 sequence_number; 517 } RecordNumber; 519 This 64-bit value is used in the ACK message as well as in the 520 "record_sequence_number" input to the AEAD function. 522 The entire header value shown in Figure 4 (but prior to record number 523 encryption, see Section 4.2.3) is used as as the additional data 524 value for the AEAD function. For instance, if the minimal variant is 525 used, the AAD is 2 octets long. Note that this design is different 526 from the additional data calculation for DTLS 1.2 and for DTLS 1.2 527 with Connection ID. 529 4.1. Demultiplexing DTLS Records 531 DTLS 1.3 uses a variable length record format and hence the 532 demultiplexing process is more complex since more header formats need 533 to be distinguished. Implementations can demultiplex DTLS 1.3 534 records by examining the first byte as follows: 536 * If the first byte is alert(21), handshake(22), or ack(proposed, 537 26), the record MUST be interpreted as a DTLSPlaintext record. 539 * If the first byte is any other value, then receivers MUST check to 540 see if the leading bits of the first byte are 001. If so, the 541 implementation MUST process the record as DTLSCiphertext; the true 542 content type will be inside the protected portion. 544 * Otherwise, the record MUST be rejected as if it had failed 545 deprotection, as described in Section 4.5.2. 547 Figure 5 shows this demultiplexing procedure graphically taking DTLS 548 1.3 and earlier versions of DTLS into account. 550 +----------------+ 551 | Outer Content | 552 | Type (OCT) | 553 | | 554 | OCT == 20 -+--> ChangeCipherSpec (DTLS <1.3) 555 | OCT == 21 -+--> Alert (Plaintext) 556 | OCT == 22 -+--> Handshake (Plaintext) 557 | OCT == 23 -+--> Application Data (DTLS <1.3) 558 | OCT == 24 -+--> Heartbeat (DTLS <1.3) 559 packet --> | OCT == 25 -+--> DTLSCipherText with CID (DTLS 1.2) 560 | OCT == 26 -+--> ACK (DTLS 1.3, Plaintext) 561 | | 562 | | /+----------------+\ 563 | 31 < OCT < 64 -+--> |DTLS Ciphertext | 564 | | |(header bits | 565 | else | | start with 001)| 566 | | | /+-------+--------+\ 567 +-------+--------+ | 568 | | 569 v Decryption | 570 +---------+ +------+ 571 | Reject | | 572 +---------+ v 573 +----------------+ 574 | Decrypted | 575 | Content Type | 576 | (DCT) | 577 | | 578 | DCT == 21 -+--> Alert 579 | DCT == 22 -+--> Handshake 580 | DCT == 23 -+--> Application Data 581 | DCT == 24 -+--> Heartbeat 582 | DCT == 26 -+--> ACK 583 | | 584 +----------------+ 586 Figure 5: Demultiplexing DTLS 1.2 and DTLS 1.3 Records 588 4.2. Sequence Number and Epoch 590 DTLS uses an explicit or partly explicit sequence number, rather than 591 an implicit one, carried in the sequence_number field of the record. 592 Sequence numbers are maintained separately for each epoch, with each 593 sequence_number initially being 0 for each epoch. 595 The epoch number is initially zero and is incremented each time 596 keying material changes and a sender aims to rekey. More details are 597 provided in Section 6.1. 599 4.2.1. Processing Guidelines 601 Because DTLS records could be reordered, a record from epoch M may be 602 received after epoch N (where N > M) has begun. In general, 603 implementations SHOULD discard records from earlier epochs, but if 604 packet loss causes noticeable problems implementations MAY choose to 605 retain keying material from previous epochs for up to the default MSL 606 specified for TCP [RFC0793] to allow for packet reordering. (Note 607 that the intention here is that implementers use the current guidance 608 from the IETF for MSL, as specified in [RFC0793] or successors, not 609 that they attempt to interrogate the MSL that the system TCP stack is 610 using.) 612 Conversely, it is possible for records that are protected with the 613 new epoch to be received prior to the completion of a handshake. For 614 instance, the server may send its Finished message and then start 615 transmitting data. Implementations MAY either buffer or discard such 616 records, though when DTLS is used over reliable transports (e.g., 617 SCTP [RFC4960]), they SHOULD be buffered and processed once the 618 handshake completes. Note that TLS's restrictions on when records 619 may be sent still apply, and the receiver treats the records as if 620 they were sent in the right order. 622 Implementations MUST send retransmissions of lost messages using the 623 same epoch and keying material as the original transmission. 625 Implementations MUST either abandon an association or re-key prior to 626 allowing the sequence number to wrap. 628 Implementations MUST NOT allow the epoch to wrap, but instead MUST 629 establish a new association, terminating the old association. 631 4.2.2. Reconstructing the Sequence Number and Epoch 633 When receiving protected DTLS records, the recipient does not have a 634 full epoch or sequence number value in the record and so there is 635 some opportunity for ambiguity. Because the full epoch and sequence 636 number are used to compute the per-record nonce, failure to 637 reconstruct these values leads to failure to deprotect the record, 638 and so implementations MAY use a mechanism of their choice to 639 determine the full values. This section provides an algorithm which 640 is comparatively simple and which implementations are RECOMMENDED to 641 follow. 643 If the epoch bits match those of the current epoch, then 644 implementations SHOULD reconstruct the sequence number by computing 645 the full sequence number which is numerically closest to one plus the 646 sequence number of the highest successfully deprotected record in the 647 current epoch. 649 During the handshake phase, the epoch bits unambiguously indicate the 650 correct key to use. After the handshake is complete, if the epoch 651 bits do not match those from the current epoch implementations SHOULD 652 use the most recent past epoch which has matching bits, and then 653 reconstruct the sequence number for that epoch as described above. 655 4.2.3. Record Number Encryption 657 In DTLS 1.3, when records are encrypted, record sequence numbers are 658 also encrypted. The basic pattern is that the underlying encryption 659 algorithm used with the AEAD algorithm is used to generate a mask 660 which is then XORed with the sequence number. 662 When the AEAD is based on AES, then the Mask is generated by 663 computing AES-ECB on the first 16 bytes of the ciphertext: 665 Mask = AES-ECB(sn_key, Ciphertext[0..15]) 667 When the AEAD is based on ChaCha20, then the mask is generated by 668 treating the first 4 bytes of the ciphertext as the block counter and 669 the next 12 bytes as the nonce, passing them to the ChaCha20 block 670 function (Section 2.3 of [CHACHA]): 672 Mask = ChaCha20(sn_key, Ciphertext[0..3], Ciphertext[4..15]) 674 The sn_key is computed as follows: 676 [sender]_sn_key = HKDF-Expand-Label(Secret, "sn" , "", key_length) 678 [sender] denotes the sending side. The Secret value to be used is 679 described in Section 7.3 of [TLS13]. 681 The encrypted sequence number is computed by XORing the leading bytes 682 of the Mask with the sequence number. Decryption is accomplished by 683 the same process. 685 This procedure requires the ciphertext length be at least 16 bytes. 686 Receivers MUST reject shorter records as if they had failed 687 deprotection, as described in Section 4.5.2. Senders MUST pad short 688 plaintexts out (using the conventional record padding mechanism) in 689 order to make a suitable-length ciphertext. Note most of the DTLS 690 AEAD algorithms have a 16-byte authentication tag and need no 691 padding. However, some algorithms such as TLS_AES_128_CCM_8_SHA256 692 have a shorter authentication tag and may require padding for short 693 inputs. 695 Future cipher suites, which are not based on AES or ChaCha20, MUST 696 define their own record sequence number encryption in order to be 697 used with DTLS. 699 Note that sequence number encryption is only applied to the 700 DTLSCiphertext structure and not to the DTLSPlaintext structure, 701 which also contains a sequence number. 703 4.3. Transport Layer Mapping 705 DTLS messages MAY be fragmented into multiple DTLS records. Each 706 DTLS record MUST fit within a single datagram. In order to avoid IP 707 fragmentation, clients of the DTLS record layer SHOULD attempt to 708 size records so that they fit within any PMTU estimates obtained from 709 the record layer. 711 Multiple DTLS records MAY be placed in a single datagram. Records 712 are encoded consecutively. The length field from DTLS records 713 containing that field can be used to determine the boundaries between 714 records. The final record in a datagram can omit the length field. 715 The first byte of the datagram payload MUST be the beginning of a 716 record. Records MUST NOT span datagrams. 718 DTLS records without CIDs do not contain any association identifiers 719 and applications must arrange to multiplex between associations. 720 With UDP, the host/port number is used to look up the appropriate 721 security association for incoming records without CIDs. 723 Some transports, such as DCCP [RFC4340], provide their own sequence 724 numbers. When carried over those transports, both the DTLS and the 725 transport sequence numbers will be present. Although this introduces 726 a small amount of inefficiency, the transport layer and DTLS sequence 727 numbers serve different purposes; therefore, for conceptual 728 simplicity, it is superior to use both sequence numbers. 730 Some transports provide congestion control for traffic carried over 731 them. If the congestion window is sufficiently narrow, DTLS 732 handshake retransmissions may be held rather than transmitted 733 immediately, potentially leading to timeouts and spurious 734 retransmission. When DTLS is used over such transports, care should 735 be taken not to overrun the likely congestion window. [RFC5238] 736 defines a mapping of DTLS to DCCP that takes these issues into 737 account. 739 4.4. PMTU Issues 741 In general, DTLS's philosophy is to leave PMTU discovery to the 742 application. However, DTLS cannot completely ignore PMTU for three 743 reasons: 745 * The DTLS record framing expands the datagram size, thus lowering 746 the effective PMTU from the application's perspective. 748 * In some implementations, the application may not directly talk to 749 the network, in which case the DTLS stack may absorb ICMP 750 [RFC1191] "Datagram Too Big" indications or ICMPv6 [RFC4443] 751 "Packet Too Big" indications. 753 * The DTLS handshake messages can exceed the PMTU. 755 In order to deal with the first two issues, the DTLS record layer 756 SHOULD behave as described below. 758 If PMTU estimates are available from the underlying transport 759 protocol, they should be made available to upper layer protocols. In 760 particular: 762 * For DTLS over UDP, the upper layer protocol SHOULD be allowed to 763 obtain the PMTU estimate maintained in the IP layer. 765 * For DTLS over DCCP, the upper layer protocol SHOULD be allowed to 766 obtain the current estimate of the PMTU. 768 * For DTLS over TCP or SCTP, which automatically fragment and 769 reassemble datagrams, there is no PMTU limitation. However, the 770 upper layer protocol MUST NOT write any record that exceeds the 771 maximum record size of 2^14 bytes. 773 The DTLS record layer SHOULD also allow the upper layer protocol to 774 discover the amount of record expansion expected by the DTLS 775 processing; alternately it MAY report PMTU estimates minus the 776 estimated expansion from the transport layer and DTLS record framing. 778 Note that DTLS does not defend against spoofed ICMP messages; 779 implementations SHOULD ignore any such messages that indicate PMTUs 780 below the IPv4 and IPv6 minimums of 576 and 1280 bytes respectively 782 If there is a transport protocol indication that the PMTU was 783 exceeded (either via ICMP or via a refusal to send the datagram as in 784 Section 14 of [RFC4340]), then the DTLS record layer MUST inform the 785 upper layer protocol of the error. 787 The DTLS record layer SHOULD NOT interfere with upper layer protocols 788 performing PMTU discovery, whether via [RFC1191] or [RFC4821] 789 mechanisms. In particular: 791 * Where allowed by the underlying transport protocol, the upper 792 layer protocol SHOULD be allowed to set the state of the DF bit 793 (in IPv4) or prohibit local fragmentation (in IPv6). 795 * If the underlying transport protocol allows the application to 796 request PMTU probing (e.g., DCCP), the DTLS record layer SHOULD 797 honor this request. 799 The final issue is the DTLS handshake protocol. From the perspective 800 of the DTLS record layer, this is merely another upper layer 801 protocol. However, DTLS handshakes occur infrequently and involve 802 only a few round trips; therefore, the handshake protocol PMTU 803 handling places a premium on rapid completion over accurate PMTU 804 discovery. In order to allow connections under these circumstances, 805 DTLS implementations SHOULD follow the following rules: 807 * If the DTLS record layer informs the DTLS handshake layer that a 808 message is too big, the handshake layer SHOULD immediately attempt 809 to fragment the message, using any existing information about the 810 PMTU. 812 * If repeated retransmissions do not result in a response, and the 813 PMTU is unknown, subsequent retransmissions SHOULD back off to a 814 smaller record size, fragmenting the handshake message as 815 appropriate. This specification does not specify an exact number 816 of retransmits to attempt before backing off, but 2-3 seems 817 appropriate. 819 4.5. Record Payload Protection 821 Like TLS, DTLS transmits data as a series of protected records. The 822 rest of this section describes the details of that format. 824 4.5.1. Anti-Replay 826 Each DTLS record contains a sequence number to provide replay 827 protection. Sequence number verification SHOULD be performed using 828 the following sliding window procedure, borrowed from Section 3.4.3 829 of [RFC4303]. Because each epoch resets the sequence number space, a 830 separate sliding window is needed for each epoch. 832 The received record counter for an epoch MUST be initialized to zero 833 when that epoch is first used. For each received record, the 834 receiver MUST verify that the record contains a sequence number that 835 does not duplicate the sequence number of any other record received 836 in that epoch during the lifetime of the association. This check 837 SHOULD happen after deprotecting the record; otherwise the record 838 discard might itself serve as a timing channel for the record number. 839 Note that computing the full record number from the partial is still 840 a potential timing channel for the record number, though a less 841 powerful one than whether the record was deprotected. 843 Duplicates are rejected through the use of a sliding receive window. 844 (How the window is implemented is a local matter, but the following 845 text describes the functionality that the implementation must 846 exhibit.) The receiver SHOULD pick a window large enough to handle 847 any plausible reordering, which depends on the data rate. (The 848 receiver does not notify the sender of the window size.) 850 The "right" edge of the window represents the highest validated 851 sequence number value received in the epoch. Records that contain 852 sequence numbers lower than the "left" edge of the window are 853 rejected. Records falling within the window are checked against a 854 list of received records within the window. An efficient means for 855 performing this check, based on the use of a bit mask, is described 856 in Section 3.4.3 of [RFC4303]. If the received record falls within 857 the window and is new, or if the record is to the right of the 858 window, then the record is new. 860 The window MUST NOT be updated until the record has been deprotected 861 successfully. 863 4.5.2. Handling Invalid Records 865 Unlike TLS, DTLS is resilient in the face of invalid records (e.g., 866 invalid formatting, length, MAC, etc.). In general, invalid records 867 SHOULD be silently discarded, thus preserving the association; 868 however, an error MAY be logged for diagnostic purposes. 869 Implementations which choose to generate an alert instead, MUST 870 generate error alerts to avoid attacks where the attacker repeatedly 871 probes the implementation to see how it responds to various types of 872 error. Note that if DTLS is run over UDP, then any implementation 873 which does this will be extremely susceptible to denial-of-service 874 (DoS) attacks because UDP forgery is so easy. Thus, this practice is 875 NOT RECOMMENDED for such transports, both to increase the reliability 876 of DTLS service and to avoid the risk of spoofing attacks sending 877 traffic to unrelated third parties. 879 If DTLS is being carried over a transport that is resistant to 880 forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts 881 because an attacker will have difficulty forging a datagram that will 882 not be rejected by the transport layer. 884 4.5.3. AEAD Limits 886 Section 5.5 of TLS [TLS13] defines limits on the number of records 887 that can be protected using the same keys. These limits are specific 888 to an AEAD algorithm, and apply equally to DTLS. Implementations 889 SHOULD NOT protect more records than allowed by the limit specified 890 for the negotiated AEAD. Implementations SHOULD initiate a key 891 update before reaching this limit. 893 [TLS13] does not specify a limit for AEAD_AES_128_CCM, but the 894 analysis in Appendix B shows that a limit of 2^23 packets can be used 895 to obtain the same confidentiality protection as the limits specified 896 in TLS. 898 The usage limits defined in TLS 1.3 exist for protection against 899 attacks on confidentiality and apply to successful applications of 900 AEAD protection. The integrity protections in authenticated 901 encryption also depend on limiting the number of attempts to forge 902 packets. TLS achieves this by closing connections after any record 903 fails an authentication check. In comparison, DTLS ignores any 904 packet that cannot be authenticated, allowing multiple forgery 905 attempts. 907 Implementations MUST count the number of received packets that fail 908 authentication with each key. If the number of packets that fail 909 authentication exceed a limit that is specific to the AEAD in use, an 910 implementation SHOULD immediately close the connection. 911 Implementations SHOULD initiate a key update with update_requested 912 before reaching this limit. Once a key update has been initiated, 913 the previous keys can be dropped when the limit is reached rather 914 than closing the connection. Applying a limit reduces the 915 probability that an attacker is able to successfully forge a packet; 916 see [AEBounds] and [ROBUST]. 918 For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305, 919 the limit on the number of records that fail authentication is 2^36. 920 Note that the analysis in [AEBounds] supports a higher limit for the 921 AEAD_AES_128_GCM and AEAD_AES_256_GCM, but this specification 922 recommends a lower limit. For AEAD_AES_128_CCM, the limit on the 923 number of records that fail authentication is 2^23.5; see Appendix B. 925 The AEAD_AES_128_CCM_8 AEAD, as used in TLS_AES_128_CCM_8_SHA256, 926 does not have a limit on the number of records that fail 927 authentication that both limits the probability of forgery by the 928 same amount and does not expose implementations to the risk of denial 929 of service; see Appendix B.3. Therefore, TLS_AES_128_CCM_8_SHA256 930 MUST NOT used in DTLS without additional safeguards against forgery. 931 Implementations MUST set usage limits for AEAD_AES_128_CCM_8 based on 932 an understanding of any additional forgery protections that are used. 934 Any TLS cipher suite that is specified for use with DTLS MUST define 935 limits on the use of the associated AEAD function that preserves 936 margins for both confidentiality and integrity. That is, limits MUST 937 be specified for the number of packets that can be authenticated and 938 for the number of packets that can fail authentication before a key 939 update is required. Providing a reference to any analysis upon which 940 values are based - and any assumptions used in that analysis - allows 941 limits to be adapted to varying usage conditions. 943 5. The DTLS Handshake Protocol 945 DTLS 1.3 re-uses the TLS 1.3 handshake messages and flows, with the 946 following changes: 948 1. To handle message loss, reordering, and fragmentation 949 modifications to the handshake header are necessary. 951 2. Retransmission timers are introduced to handle message loss. 953 3. A new ACK content type has been added for reliable message 954 delivery of handshake messages. 956 Note that TLS 1.3 already supports a cookie extension, which is used 957 to prevent denial-of-service attacks. This DoS prevention mechanism 958 is described in more detail below since UDP-based protocols are more 959 vulnerable to amplification attacks than a connection-oriented 960 transport like TCP that performs return-routability checks as part of 961 the connection establishment. 963 DTLS implementations do not use the TLS 1.3 "compatibility mode" 964 described in Section D.4 of [TLS13]. DTLS servers MUST NOT echo the 965 "legacy_session_id" value from the client and endpoints MUST NOT send 966 ChangeCipherSpec messages. 968 With these exceptions, the DTLS message formats, flows, and logic are 969 the same as those of TLS 1.3. 971 5.1. Denial-of-Service Countermeasures 973 Datagram security protocols are extremely susceptible to a variety of 974 DoS attacks. Two attacks are of particular concern: 976 1. An attacker can consume excessive resources on the server by 977 transmitting a series of handshake initiation requests, causing 978 the server to allocate state and potentially to perform expensive 979 cryptographic operations. 981 2. An attacker can use the server as an amplifier by sending 982 connection initiation messages with a forged source address that 983 belongs to a victim. The server then sends its response to the 984 victim machine, thus flooding it. Depending on the selected 985 parameters this response message can be quite large, as is the 986 case for a Certificate message. 988 In order to counter both of these attacks, DTLS borrows the stateless 989 cookie technique used by Photuris [RFC2522] and IKE [RFC7296]. When 990 the client sends its ClientHello message to the server, the server 991 MAY respond with a HelloRetryRequest message. The HelloRetryRequest 992 message, as well as the cookie extension, is defined in TLS 1.3. The 993 HelloRetryRequest message contains a stateless cookie (see [TLS13]; 994 Section 4.2.2). The client MUST send a new ClientHello with the 995 cookie added as an extension. The server then verifies the cookie 996 and proceeds with the handshake only if it is valid. This mechanism 997 forces the attacker/client to be able to receive the cookie, which 998 makes DoS attacks with spoofed IP addresses difficult. This 999 mechanism does not provide any defense against DoS attacks mounted 1000 from valid IP addresses. 1002 The DTLS 1.3 specification changes how cookies are exchanged compared 1003 to DTLS 1.2. DTLS 1.3 re-uses the HelloRetryRequest message and 1004 conveys the cookie to the client via an extension. The client 1005 receiving the cookie uses the same extension to place the cookie 1006 subsequently into a ClientHello message. DTLS 1.2 on the other hand 1007 used a separate message, namely the HelloVerifyRequest, to pass a 1008 cookie to the client and did not utilize the extension mechanism. 1009 For backwards compatibility reasons, the cookie field in the 1010 ClientHello is present in DTLS 1.3 but is ignored by a DTLS 1.3 1011 compliant server implementation. 1013 The exchange is shown in Figure 6. Note that the figure focuses on 1014 the cookie exchange; all other extensions are omitted. 1016 Client Server 1017 ------ ------ 1018 ClientHello ------> 1020 <----- HelloRetryRequest 1021 + cookie 1023 ClientHello ------> 1024 + cookie 1026 [Rest of handshake] 1028 Figure 6: DTLS exchange with HelloRetryRequest containing the 1029 "cookie" extension 1031 The cookie extension is defined in Section 4.2.2 of [TLS13]. When 1032 sending the initial ClientHello, the client does not have a cookie 1033 yet. In this case, the cookie extension is omitted and the 1034 legacy_cookie field in the ClientHello message MUST be set to a zero 1035 length vector (i.e., a single zero byte length field). 1037 When responding to a HelloRetryRequest, the client MUST create a new 1038 ClientHello message following the description in Section 4.1.2 of 1039 [TLS13]. 1041 If the HelloRetryRequest message is used, the initial ClientHello and 1042 the HelloRetryRequest are included in the calculation of the 1043 transcript hash. The computation of the message hash for the 1044 HelloRetryRequest is done according to the description in 1045 Section 4.4.1 of [TLS13]. 1047 The handshake transcript is not reset with the second ClientHello and 1048 a stateless server-cookie implementation requires the content or hash 1049 of the initial ClientHello (and HelloRetryRequest) to be stored in 1050 the cookie. The initial ClientHello is included in the handshake 1051 transcript as a synthetic "message_hash" message, so only the hash 1052 value is needed for the handshake to complete, though the complete 1053 HelloRetryRequest contents are needed. 1055 When the second ClientHello is received, the server can verify that 1056 the cookie is valid and that the client can receive packets at the 1057 given IP address. If the client's apparent IP address is embedded in 1058 the cookie, this prevents an attacker from generating an acceptable 1059 ClientHello apparently from another user. 1061 One potential attack on this scheme is for the attacker to collect a 1062 number of cookies from different addresses where it controls 1063 endpoints and then reuse them to attack the server. The server can 1064 defend against this attack by changing the secret value frequently, 1065 thus invalidating those cookies. If the server wishes to allow 1066 legitimate clients to handshake through the transition (e.g., a 1067 client received a cookie with Secret 1 and then sent the second 1068 ClientHello after the server has changed to Secret 2), the server can 1069 have a limited window during which it accepts both secrets. 1070 [RFC7296] suggests adding a key identifier to cookies to detect this 1071 case. An alternative approach is simply to try verifying with both 1072 secrets. It is RECOMMENDED that servers implement a key rotation 1073 scheme that allows the server to manage keys with overlapping 1074 lifetime. 1076 Alternatively, the server can store timestamps in the cookie and 1077 reject cookies that were generated outside a certain interval of 1078 time. 1080 DTLS servers SHOULD perform a cookie exchange whenever a new 1081 handshake is being performed. If the server is being operated in an 1082 environment where amplification is not a problem, the server MAY be 1083 configured not to perform a cookie exchange. The default SHOULD be 1084 that the exchange is performed, however. In addition, the server MAY 1085 choose not to do a cookie exchange when a session is resumed or, more 1086 generically, when the DTLS handshake uses a PSK-based key exchange. 1087 Servers which process 0-RTT requests and send 0.5-RTT responses 1088 without a cookie exchange risk being used in an amplification attack 1089 if the size of outgoing messages greatly exceeds the size of those 1090 that are received. A server SHOULD limit the amount of data it sends 1091 toward a client address before it verifies that the client is able to 1092 receive data at that address. A client address is valid after a 1093 cookie exchange or handshake completion. A server MAY apply a higher 1094 limit based on heuristics, such as if the client uses the same IP 1095 address as the connection on which the cookie was created. Clients 1096 MUST be prepared to do a cookie exchange with every handshake. 1098 If a server receives a ClientHello with an invalid cookie, it MUST 1099 terminate the handshake with an "illegal_parameter" alert. This 1100 allows the client to restart the connection from scratch without a 1101 cookie. 1103 As described in Section 4.1.4 of [TLS13], clients MUST abort the 1104 handshake with an "unexpected_message" alert in response to any 1105 second HelloRetryRequest which was sent in the same connection (i.e., 1106 where the ClientHello was itself in response to a HelloRetryRequest). 1108 5.2. DTLS Handshake Message Format 1110 In order to support message loss, reordering, and message 1111 fragmentation, DTLS modifies the TLS 1.3 handshake header: 1113 enum { 1114 client_hello(1), 1115 server_hello(2), 1116 new_session_ticket(4), 1117 end_of_early_data(5), 1118 encrypted_extensions(8), 1119 certificate(11), 1120 certificate_request(13), 1121 certificate_verify(15), 1122 finished(20), 1123 key_update(24), 1124 message_hash(254), 1125 (255) 1126 } HandshakeType; 1128 struct { 1129 HandshakeType msg_type; /* handshake type */ 1130 uint24 length; /* bytes in message */ 1131 uint16 message_seq; /* DTLS-required field */ 1132 uint24 fragment_offset; /* DTLS-required field */ 1133 uint24 fragment_length; /* DTLS-required field */ 1134 select (HandshakeType) { 1135 case client_hello: ClientHello; 1136 case server_hello: ServerHello; 1137 case end_of_early_data: EndOfEarlyData; 1138 case encrypted_extensions: EncryptedExtensions; 1139 case certificate_request: CertificateRequest; 1140 case certificate: Certificate; 1141 case certificate_verify: CertificateVerify; 1142 case finished: Finished; 1143 case new_session_ticket: NewSessionTicket; 1144 case key_update: KeyUpdate; 1145 } body; 1146 } Handshake; 1148 The first message each side transmits in each association always has 1149 message_seq = 0. Whenever a new message is generated, the 1150 message_seq value is incremented by one. When a message is 1151 retransmitted, the old message_seq value is re-used, i.e., not 1152 incremented. From the perspective of the DTLS record layer, the 1153 retransmission is a new record. This record will have a new 1154 DTLSPlaintext.sequence_number value. 1156 Note: In DTLS 1.2 the message_seq was reset to zero in case of a 1157 rehandshake (i.e., renegotiation). On the surface, a rehandshake in 1158 DTLS 1.2 shares similarities with a post-handshake message exchange 1159 in DTLS 1.3. However, in DTLS 1.3 the message_seq is not reset to 1160 allow distinguishing a retransmission from a previously sent post- 1161 handshake message from a newly sent post-handshake message. 1163 DTLS implementations maintain (at least notionally) a 1164 next_receive_seq counter. This counter is initially set to zero. 1165 When a handshake message is received, if its message_seq value 1166 matches next_receive_seq, next_receive_seq is incremented and the 1167 message is processed. If the sequence number is less than 1168 next_receive_seq, the message MUST be discarded. If the sequence 1169 number is greater than next_receive_seq, the implementation SHOULD 1170 queue the message but MAY discard it. (This is a simple space/ 1171 bandwidth tradeoff). 1173 In addition to the handshake messages that are deprecated by the TLS 1174 1.3 specification, DTLS 1.3 furthermore deprecates the 1175 HelloVerifyRequest message originally defined in DTLS 1.0. DTLS 1176 1.3-compliant implements MUST NOT use the HelloVerifyRequest to 1177 execute a return-routability check. A dual-stack DTLS 1.2/DTLS 1.3 1178 client MUST, however, be prepared to interact with a DTLS 1.2 server. 1180 5.3. ClientHello Message 1182 The format of the ClientHello used by a DTLS 1.3 client differs from 1183 the TLS 1.3 ClientHello format as shown below. 1185 uint16 ProtocolVersion; 1186 opaque Random[32]; 1188 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 1190 struct { 1191 ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2 1192 Random random; 1193 opaque legacy_session_id<0..32>; 1194 opaque legacy_cookie<0..2^8-1>; // DTLS 1195 CipherSuite cipher_suites<2..2^16-2>; 1196 opaque legacy_compression_methods<1..2^8-1>; 1197 Extension extensions<8..2^16-1>; 1198 } ClientHello; 1200 legacy_version: In previous versions of DTLS, this field was used 1201 for version negotiation and represented the highest version number 1202 supported by the client. Experience has shown that many servers 1203 do not properly implement version negotiation, leading to "version 1204 intolerance" in which the server rejects an otherwise acceptable 1205 ClientHello with a version number higher than it supports. In 1206 DTLS 1.3, the client indicates its version preferences in the 1207 "supported_versions" extension (see Section 4.2.1 of [TLS13]) and 1208 the legacy_version field MUST be set to {254, 253}, which was the 1209 version number for DTLS 1.2. The supported_versions entries for 1210 DTLS 1.0 and DTLS 1.2 are 0xfeff and 0xfefd (to match the wire 1211 versions). The value 0xfefc is used to indicate DTLS 1.3. 1213 random: Same as for TLS 1.3, except that the downgrade sentinels 1214 described in Section 4.1.3 of [RFC8446] when TLS 1.2 and TLS 1.1 1215 and below are negotiated apply to DTLS 1.2 and DTLS 1.0 1216 respectively. 1218 legacy_session_id: Versions of TLS and DTLS before version 1.3 1219 supported a "session resumption" feature which has been merged 1220 with pre-shared keys in version 1.3. A client which has a cached 1221 session ID set by a pre-DTLS 1.3 server SHOULD set this field to 1222 that value. Otherwise, it MUST be set as a zero-length vector 1223 (i.e., a zero-valued single byte length field). 1225 legacy_cookie: A DTLS 1.3-only client MUST set the legacy_cookie 1226 field to zero length. If a DTLS 1.3 ClientHello is received with 1227 any other value in this field, the server MUST abort the handshake 1228 with an "illegal_parameter" alert. 1230 cipher_suites: Same as for TLS 1.3; only suites with DTLS-OK=Y may 1231 be used. 1233 legacy_compression_methods: Same as for TLS 1.3. 1235 extensions: Same as for TLS 1.3. 1237 5.4. ServerHello Message 1239 The DTLS 1.3 ServerHello message is the same as the TLS 1.3 1240 ServerHello message, except that the legacy_version field is set to 1241 0xfefd, indicating DTLS 1.2. 1243 5.5. Handshake Message Fragmentation and Reassembly 1245 As described in Section 4.3 one or more handshake messages may be 1246 carried in a single datagram. However, handshake messages are 1247 potentially bigger than the size allowed by the underlying datagram 1248 transport. DTLS provides a mechanism for fragmenting a handshake 1249 message over a number of records, each of which can be transmitted in 1250 separate datagrams, thus avoiding IP fragmentation. 1252 When transmitting the handshake message, the sender divides the 1253 message into a series of N contiguous data ranges. The ranges MUST 1254 NOT overlap. The sender then creates N handshake messages, all with 1255 the same message_seq value as the original handshake message. Each 1256 new message is labeled with the fragment_offset (the number of bytes 1257 contained in previous fragments) and the fragment_length (the length 1258 of this fragment). The length field in all messages is the same as 1259 the length field of the original message. An unfragmented message is 1260 a degenerate case with fragment_offset=0 and fragment_length=length. 1261 Each handshake message fragment that is placed into a record MUST be 1262 delivered in a single UDP datagram. 1264 When a DTLS implementation receives a handshake message fragment 1265 corresponding to the next expected handshake message sequence number, 1266 it MUST buffer it until it has the entire handshake message. DTLS 1267 implementations MUST be able to handle overlapping fragment ranges. 1268 This allows senders to retransmit handshake messages with smaller 1269 fragment sizes if the PMTU estimate changes. Senders MUST NOT change 1270 handshake message bytes upon retransmission. Receivers MAY check 1271 that retransmitted bytes are identical and SHOULD abort the handshake 1272 with an "illegal_parameter" alert if the value of a byte changes. 1274 Note that as with TLS, multiple handshake messages may be placed in 1275 the same DTLS record, provided that there is room and that they are 1276 part of the same flight. Thus, there are two acceptable ways to pack 1277 two DTLS handshake messages into the same datagram: in the same 1278 record or in separate records. 1280 5.6. End Of Early Data 1282 The DTLS 1.3 handshake has one important difference from the TLS 1.3 1283 handshake: the EndOfEarlyData message is omitted both from the wire 1284 and the handshake transcript: because DTLS records have epochs, 1285 EndOfEarlyData is not necessary to determine when the early data is 1286 complete, and because DTLS is lossy, attackers can trivially mount 1287 the deletion attacks that EndOfEarlyData prevents in TLS. Servers 1288 SHOULD NOT accept records from epoch 1 indefinitely once they are 1289 able to process records from epoch 3. Though reordering of IP 1290 packets can result in records from epoch 1 arriving after records 1291 from epoch 3, this is not likely to persist for very long relative to 1292 the round trip time. Servers could discard epoch 1 keys after the 1293 first epoch 3 data arrives, or retain keys for processing epoch 1 1294 data for a short period. (See Section 6.1 for the definitions of 1295 each epoch.) 1297 5.7. DTLS Handshake Flights 1299 DTLS handshake messages are grouped into a series of message flights. 1300 A flight starts with the handshake message transmission of one peer 1301 and ends with the expected response from the other peer. Table 1 1302 contains a complete list of message combinations that consitute 1303 flights. 1305 +======+========+========+===================================+ 1306 | Note | Client | Server | Handshake Messages | 1307 +======+========+========+===================================+ 1308 | | x | | ClientHello | 1309 +------+--------+--------+-----------------------------------+ 1310 | | | x | HelloRetryRequest | 1311 +------+--------+--------+-----------------------------------+ 1312 | | | x | ServerHello, EncryptedExtensions, | 1313 | | | | CertificateRequest, Certificate, | 1314 | | | | CertificateVerify, Finished | 1315 +------+--------+--------+-----------------------------------+ 1316 | 1 | x | | Certificate, CertificateVerify, | 1317 | | | | Finished | 1318 +------+--------+--------+-----------------------------------+ 1319 | | | x | ACK | 1320 +------+--------+--------+-----------------------------------+ 1321 | 1 | | x | NewSessionTicket | 1322 +------+--------+--------+-----------------------------------+ 1324 Table 1: Flight Handshake Message Combinations. 1326 Remarks: 1328 * Table 1 does not highlight any of the optional messages. 1330 * Regarding note (1): When a handshake flight is sent without any 1331 expected response, as it is the case with the client's final 1332 flight or with the NewSessionTicket message, the flight must be 1333 acknowledged with an ACK message. 1335 Below are several example message exchange illustrating the flight 1336 concept. The notational conventions from [RFC8446] are used. 1338 Client Server 1340 +--------+ 1341 ClientHello | Flight | 1342 --------> +--------+ 1344 +--------+ 1345 <-------- HelloRetryRequest | Flight | 1346 + cookie +--------+ 1348 +--------+ 1349 ClientHello | Flight | 1350 + cookie --------> +--------+ 1352 ServerHello 1353 {EncryptedExtensions} +--------+ 1354 {CertificateRequest*} | Flight | 1355 {Certificate*} +--------+ 1356 {CertificateVerify*} 1357 {Finished} 1358 <-------- [Application Data*] 1360 {Certificate*} +--------+ 1361 {CertificateVerify*} | Flight | 1362 {Finished} --------> +--------+ 1363 [Application Data] 1365 +--------+ 1366 <-------- [ACK] | Flight | 1367 [Application Data*] +--------+ 1369 [Application Data] <-------> [Application Data] 1371 Figure 7: Message flights for a full DTLS Handshake (with cookie 1372 exchange) 1374 ClientHello +--------+ 1375 + pre_shared_key | Flight | 1376 + psk_key_exchange_modes +--------+ 1377 + key_share* --------> 1379 ServerHello 1380 + pre_shared_key +--------+ 1381 + key_share* | Flight | 1382 {EncryptedExtensions} +--------+ 1383 <-------- {Finished} 1384 [Application Data*] 1385 +--------+ 1386 {Finished} --------> | Flight | 1387 [Application Data*] +--------+ 1389 +--------+ 1390 <-------- [ACK] | Flight | 1391 [Application Data*] +--------+ 1393 [Application Data] <-------> [Application Data] 1395 Figure 8: Message flights for resumption and PSK handshake 1396 (without cookie exchange) 1398 Client Server 1400 ClientHello 1401 + early_data 1402 + psk_key_exchange_modes +--------+ 1403 + key_share* | Flight | 1404 + pre_shared_key +--------+ 1405 (Application Data*) --------> 1407 ServerHello 1408 + pre_shared_key 1409 + key_share* +--------+ 1410 {EncryptedExtensions} | Flight | 1411 {Finished} +--------+ 1412 <-------- [Application Data*] 1414 +--------+ 1415 {Finished} --------> | Flight | 1416 [Application Data*] +--------+ 1418 +--------+ 1419 <-------- [ACK] | Flight | 1420 [Application Data*] +--------+ 1422 [Application Data] <-------> [Application Data] 1424 Figure 9: Message flights for the Zero-RTT handshake 1426 Client Server 1428 +--------+ 1429 <-------- [NewSessionTicket] | Flight | 1430 +--------+ 1432 +--------+ 1433 [ACK] --------> | Flight | 1434 +--------+ 1436 Figure 10: Message flights for the NewSessionTicket message 1438 KeyUpdate, NewConnectionId and RequestConnectionId follow a similar 1439 pattern to NewSessionTicket: a single message sent by one side 1440 followed by an ACK by the other. 1442 5.8. Timeout and Retransmission 1444 5.8.1. State Machine 1446 DTLS uses a simple timeout and retransmission scheme with the state 1447 machine shown in Figure 11. Because DTLS clients send the first 1448 message (ClientHello), they start in the PREPARING state. DTLS 1449 servers start in the WAITING state, but with empty buffers and no 1450 retransmit timer. 1452 +-----------+ 1453 | PREPARING | 1454 +----------> | | 1455 | | | 1456 | +-----------+ 1457 | | 1458 | | Buffer next flight 1459 | | 1460 | \|/ 1461 | +-----------+ 1462 | | | 1463 | | SENDING |<------------------+ 1464 | | | | 1465 | +-----------+ | 1466 Receive | | | 1467 next | | Send flight or partial | 1468 flight | | flight | 1469 | | | 1470 | | Set retransmit timer | 1471 | \|/ | 1472 | +-----------+ | 1473 | | | | 1474 +------------| WAITING |-------------------+ 1475 | +----->| | Timer expires | 1476 | | +-----------+ | 1477 | | | | | | 1478 | | | | | | 1479 | +----------+ | +--------------------+ 1480 | Receive record | Read retransmit or ACK 1481 Receive | (Maybe Send ACK) | 1482 last | | 1483 flight | | Receive ACK 1484 | | for last flight 1485 \|/ | 1486 | 1487 +-----------+ | 1488 | | <---------+ 1489 | FINISHED | 1490 | | 1491 +-----------+ 1492 | /|\ 1493 | | 1494 | | 1495 +---+ 1497 Server read retransmit 1498 Retransmit ACK 1500 Figure 11: DTLS timeout and retransmission state machine 1502 The state machine has four basic states: PREPARING, SENDING, WAITING, 1503 and FINISHED. 1505 In the PREPARING state, the implementation does whatever computations 1506 are necessary to prepare the next flight of messages. It then 1507 buffers them up for transmission (emptying the transmission buffer 1508 first) and enters the SENDING state. 1510 In the SENDING state, the implementation transmits the buffered 1511 flight of messages. If the implementation has received one or more 1512 ACKs (see Section 7) from the peer, then it SHOULD omit any messages 1513 or message fragments which have already been ACKed. Once the 1514 messages have been sent, the implementation then sets a retransmit 1515 timer and enters the WAITING state. 1517 There are four ways to exit the WAITING state: 1519 1. The retransmit timer expires: the implementation transitions to 1520 the SENDING state, where it retransmits the flight, resets the 1521 retransmit timer, and returns to the WAITING state. 1523 2. The implementation reads an ACK from the peer: upon receiving an 1524 ACK for a partial flight (as mentioned in Section 7.1), the 1525 implementation transitions to the SENDING state, where it 1526 retransmits the unacked portion of the flight, resets the 1527 retransmit timer, and returns to the WAITING state. Upon 1528 receiving an ACK for a complete flight, the implementation 1529 cancels all retransmissions and either remains in WAITING, or, if 1530 the ACK was for the final flight, transitions to FINISHED. 1532 3. The implementation reads a retransmitted flight from the peer: 1533 the implementation transitions to the SENDING state, where it 1534 retransmits the flight, resets the retransmit timer, and returns 1535 to the WAITING state. The rationale here is that the receipt of 1536 a duplicate message is the likely result of timer expiry on the 1537 peer and therefore suggests that part of one's previous flight 1538 was lost. 1540 4. The implementation receives some or all of the next flight of 1541 messages: if this is the final flight of messages, the 1542 implementation transitions to FINISHED. If the implementation 1543 needs to send a new flight, it transitions to the PREPARING 1544 state. Partial reads (whether partial messages or only some of 1545 the messages in the flight) may also trigger the implementation 1546 to send an ACK, as described in Section 7.1. 1548 Because DTLS clients send the first message (ClientHello), they start 1549 in the PREPARING state. DTLS servers start in the WAITING state, but 1550 with empty buffers and no retransmit timer. 1552 In addition, for at least twice the default MSL defined for 1553 [RFC0793], when in the FINISHED state, the server MUST respond to 1554 retransmission of the client's final flight with a retransmit of its 1555 ACK. 1557 Note that because of packet loss, it is possible for one side to be 1558 sending application data even though the other side has not received 1559 the first side's Finished message. Implementations MUST either 1560 discard or buffer all application data records for epoch 3 and above 1561 until they have received the Finished message from the peer. 1562 Implementations MAY treat receipt of application data with a new 1563 epoch prior to receipt of the corresponding Finished message as 1564 evidence of reordering or packet loss and retransmit their final 1565 flight immediately, shortcutting the retransmission timer. 1567 5.8.2. Timer Values 1569 Though timer values are the choice of the implementation, mishandling 1570 of the timer can lead to serious congestion problems, for example if 1571 many instances of a DTLS time out early and retransmit too quickly on 1572 a congested link. Implementations SHOULD use an initial timer value 1573 of 100 msec (the minimum defined in RFC 6298 [RFC6298]) and double 1574 the value at each retransmission, up to no less than 60 seconds (the 1575 RFC 6298 maximum). Application specific profiles, such as those used 1576 for the Internet of Things environment, may recommend longer timer 1577 values. Note that a 100 msec timer is recommended rather than the 1578 3-second RFC 6298 default in order to improve latency for time- 1579 sensitive applications. Because DTLS only uses retransmission for 1580 handshake and not dataflow, the effect on congestion should be 1581 minimal. 1583 Implementations SHOULD retain the current timer value until a message 1584 is transmitted and acknowledged without having to be retransmitted, 1585 at which time the value may be reset to the initial value. After a 1586 long period of idleness, no less than 10 times the current timer 1587 value, implementations MAY reset the timer to the initial value. 1589 5.8.3. Large Flight Sizes 1591 DTLS does not have any built-in congestion control or rate control; 1592 in general this is not an issue because messages tend to be small. 1593 However, in principle, some messages - especially Certificate - can 1594 be quite large. If all the messages in a large flight are sent at 1595 once, this can result in network congestion. A better strategy is to 1596 send out only part of the flight, sending more when messages are 1597 acknowledged. DTLS offers a number of mechanisms for minimizing the 1598 size of the certificate message, including the cached information 1599 extension [RFC7924] and certificate compression [RFC8879]. 1601 5.8.4. State machine duplication for post-handshake messages 1603 DTLS 1.3 makes use of the following categories of post-handshake 1604 messages: 1606 1. NewSessionTicket 1608 2. KeyUpdate 1610 3. NewConnectionId 1612 4. RequestConnectionId 1614 5. Post-handshake client authentication 1616 Messages of each category can be sent independently, and reliability 1617 is established via independent state machines each of which behaves 1618 as described in Section 5.8.1. For example, if a server sends a 1619 NewSessionTicket and a CertificateRequest message, two independent 1620 state machines will be created. 1622 As explained in the corresponding sections, sending multiple 1623 instances of messages of a given category without having completed 1624 earlier transmissions is allowed for some categories, but not for 1625 others. Specifically, a server MAY send multiple NewSessionTicket 1626 messages at once without awaiting ACKs for earlier NewSessionTicket 1627 first. Likewise, a server MAY send multiple CertificateRequest 1628 messages at once without having completed earlier client 1629 authentication requests before. In contrast, implementations MUST 1630 NOT have send KeyUpdate, NewConnectionId or RequestConnectionId 1631 message if an earlier message of the same type has not yet been 1632 acknowledged. 1634 Note: Except for post-handshake client authentication, which involves 1635 handshake messages in both directions, post-handshake messages are 1636 single-flight, and their respective state machines on the sender side 1637 reduce to waiting for an ACK and retransmitting the original message. 1638 In particular, note that a RequestConnectionId message does not force 1639 the receiver to send a NewConnectionId message in reply, and both 1640 messages are therefore treated independently. 1642 Creating and correctly updating multiple state machines requires 1643 feedback from the handshake logic to the state machine layer, 1644 indicating which message belongs to which state machine. For 1645 example, if a server sends multiple CertificateRequest messages and 1646 receives a Certificate message in response, the corresponding state 1647 machine can only be determined after inspecting the 1648 certificate_request_context field. Similarly, a server sending a 1649 single CertificateRequest and receiving a NewConnectionId message in 1650 response can only decide that the NewConnectionId message should be 1651 treated through an independent state machine after inspecting the 1652 handshake message type. 1654 5.9. CertificateVerify and Finished Messages 1656 CertificateVerify and Finished messages have the same format as in 1657 TLS 1.3. Hash calculations include entire handshake messages, 1658 including DTLS-specific fields: message_seq, fragment_offset, and 1659 fragment_length. However, in order to remove sensitivity to 1660 handshake message fragmentation, the CertificateVerify and the 1661 Finished messages MUST be computed as if each handshake message had 1662 been sent as a single fragment following the algorithm described in 1663 Section 4.4.3 and Section 4.4.4 of [TLS13], respectively. 1665 5.10. Cryptographic Label Prefix 1667 Section 7.1 of [TLS13] specifies that HKDF-Expand-Label uses a label 1668 prefix of "tls13 ". For DTLS 1.3, that label SHALL be "dtls13". 1669 This ensures key separation between DTLS 1.3 and TLS 1.3. Note that 1670 there is no trailing space; this is necessary in order to keep the 1671 overall label size inside of one hash iteration because "DTLS" is one 1672 letter longer than "TLS". 1674 5.11. Alert Messages 1676 Note that Alert messages are not retransmitted at all, even when they 1677 occur in the context of a handshake. However, a DTLS implementation 1678 which would ordinarily issue an alert SHOULD generate a new alert 1679 message if the offending record is received again (e.g., as a 1680 retransmitted handshake message). Implementations SHOULD detect when 1681 a peer is persistently sending bad messages and terminate the local 1682 connection state after such misbehavior is detected. Note that 1683 alerts are not reliably transmitted; implementation SHOULD NOT depend 1684 on receiving alerts in order to signal errors or connection closure. 1686 5.12. Establishing New Associations with Existing Parameters 1688 If a DTLS client-server pair is configured in such a way that 1689 repeated connections happen on the same host/port quartet, then it is 1690 possible that a client will silently abandon one connection and then 1691 initiate another with the same parameters (e.g., after a reboot). 1692 This will appear to the server as a new handshake with epoch=0. In 1693 cases where a server believes it has an existing association on a 1694 given host/port quartet and it receives an epoch=0 ClientHello, it 1695 SHOULD proceed with a new handshake but MUST NOT destroy the existing 1696 association until the client has demonstrated reachability either by 1697 completing a cookie exchange or by completing a complete handshake 1698 including delivering a verifiable Finished message. After a correct 1699 Finished message is received, the server MUST abandon the previous 1700 association to avoid confusion between two valid associations with 1701 overlapping epochs. The reachability requirement prevents off-path/ 1702 blind attackers from destroying associations merely by sending forged 1703 ClientHellos. 1705 Note: it is not always possible to distinguish which association a 1706 given record is from. For instance, if the client performs a 1707 handshake, abandons the connection, and then immediately starts a new 1708 handshake, it may not be possible to tell which connection a given 1709 protected record is for. In these cases, trial decryption may be 1710 necessary, though implementations could use CIDs to avoid the 5- 1711 tuple-based ambiguity. 1713 6. Example of Handshake with Timeout and Retransmission 1715 The following is an example of a handshake with lost packets and 1716 retransmissions. Note that the client sends an empty ACK message 1717 because it can only acknowledge Record 1 sent by the server once it 1718 has processed messages in Record 0 needed to establish epoch 2 keys, 1719 which are needed to encrypt to decrypt messages found in Record 1. 1720 Section 7 provides the necessary background details for this 1721 interaction. 1723 Client Server 1724 ------ ------ 1726 Record 0 --------> 1727 ClientHello 1728 (message_seq=0) 1730 X<----- Record 0 1731 (lost) ServerHello 1732 (message_seq=0) 1733 EncryptedExtensions 1734 (message_seq=1) 1735 Certificate 1736 (message_seq=2) 1738 <-------- Record 1 1739 CertificateVerify 1740 (message_seq=3) 1741 Finished 1742 (message_seq=4) 1744 Record 1 --------> 1745 ACK [] 1747 <-------- Record 2 1748 ServerHello 1749 (message_seq=0) 1750 EncryptedExtensions 1751 (message_seq=1) 1752 Certificate 1753 (message_seq=2) 1755 Record 2 --------> 1756 Certificate 1757 (message_seq=1) 1758 CertificateVerify 1759 (message_seq=2) 1760 Finished 1761 (message_seq=3) 1763 <-------- Record 3 1764 ACK [2] 1766 Figure 12: Example DTLS exchange illustrating message loss 1768 6.1. Epoch Values and Rekeying 1770 A recipient of a DTLS message needs to select the correct keying 1771 material in order to process an incoming message. With the 1772 possibility of message loss and re-ordering, an identifier is needed 1773 to determine which cipher state has been used to protect the record 1774 payload. The epoch value fulfills this role in DTLS. In addition to 1775 the TLS 1.3-defined key derivation steps, see Section 7 of [TLS13], a 1776 sender may want to rekey at any time during the lifetime of the 1777 connection. It therefore needs to indicate that it is updating its 1778 sending cryptographic keys. 1780 This version of DTLS assigns dedicated epoch values to messages in 1781 the protocol exchange to allow identification of the correct cipher 1782 state: 1784 * epoch value (0) is used with unencrypted messages. There are 1785 three unencrypted messages in DTLS, namely ClientHello, 1786 ServerHello, and HelloRetryRequest. 1788 * epoch value (1) is used for messages protected using keys derived 1789 from client_early_traffic_secret. Note this epoch is skipped if 1790 the client does not offer early data. 1792 * epoch value (2) is used for messages protected using keys derived 1793 from [sender]_handshake_traffic_secret. Messages transmitted 1794 during the initial handshake, such as EncryptedExtensions, 1795 CertificateRequest, Certificate, CertificateVerify, and Finished 1796 belong to this category. Note, however, post-handshake are 1797 protected under the appropriate application traffic key and are 1798 not included in this category. 1800 * epoch value (3) is used for payloads protected using keys derived 1801 from the initial [sender]_application_traffic_secret_0. This may 1802 include handshake messages, such as post-handshake messages (e.g., 1803 a NewSessionTicket message). 1805 * epoch value (4 to 2^16-1) is used for payloads protected using 1806 keys from the [sender]_application_traffic_secret_N (N>0). 1808 Using these reserved epoch values a receiver knows what cipher state 1809 has been used to encrypt and integrity protect a message. 1810 Implementations that receive a record with an epoch value for which 1811 no corresponding cipher state can be determined SHOULD handle it as a 1812 record which fails deprotection. 1814 Note that epoch values do not wrap. If a DTLS implementation would 1815 need to wrap the epoch value, it MUST terminate the connection. 1817 The traffic key calculation is described in Section 7.3 of [TLS13]. 1819 Figure 13 illustrates the epoch values in an example DTLS handshake. 1821 Client Server 1822 ------ ------ 1824 Record 0 1825 ClientHello 1826 (epoch=0) 1827 --------> 1828 Record 0 1829 <-------- HelloRetryRequest 1830 (epoch=0) 1831 Record 1 1832 ClientHello --------> 1833 (epoch=0) 1834 Record 1 1835 <-------- ServerHello 1836 (epoch=0) 1837 {EncryptedExtensions} 1838 (epoch=2) 1839 {Certificate} 1840 (epoch=2) 1841 {CertificateVerify} 1842 (epoch=2) 1843 {Finished} 1844 (epoch=2) 1845 Record 2 1846 {Certificate} --------> 1847 (epoch=2) 1848 {CertificateVerify} 1849 (epoch=2) 1850 {Finished} 1851 (epoch=2) 1852 Record 2 1853 <-------- [ACK] 1854 (epoch=3) 1855 Record 3 1856 [Application Data] --------> 1857 (epoch=3) 1858 Record 3 1859 <-------- [Application Data] 1860 (epoch=3) 1862 Some time later ... 1863 (Post-Handshake Message Exchange) 1864 Record 4 1866 <-------- [NewSessionTicket] 1867 (epoch=3) 1868 Record 4 1869 [ACK] --------> 1870 (epoch=3) 1872 Some time later ... 1873 (Rekeying) 1874 Record 5 1875 <-------- [Application Data] 1876 (epoch=4) 1877 Record 5 1878 [Application Data] --------> 1879 (epoch=4) 1881 Figure 13: Example DTLS exchange with epoch information 1883 7. ACK Message 1885 The ACK message is used by an endpoint to indicate which handshake 1886 records it has received and processed from the other side. ACK is 1887 not a handshake message but is rather a separate content type, with 1888 code point TBD (proposed, 25). This avoids having ACK being added to 1889 the handshake transcript. Note that ACKs can still be sent in the 1890 same UDP datagram as handshake records. 1892 struct { 1893 RecordNumber record_numbers<0..2^16-1>; 1894 } ACK; 1896 record_numbers: a list of the records containing handshake messages 1897 in the current flight which the endpoint has received and either 1898 processed or buffered, in numerically increasing order. 1900 Implementations MUST NOT acknowledge records containing handshake 1901 messages or fragments which have not been processed or buffered. 1902 Otherwise, deadlock can ensue. As an example, implementations MUST 1903 NOT send ACKs for handshake messages which they discard because they 1904 are not the next expected message. 1906 During the handshake, ACKs only cover the current outstanding flight 1907 (this is possible because DTLS is generally a lockstep protocol). In 1908 particular, receiving a message from a handshake flight implicitly 1909 acknowledges all messages from the previous flight(s). Accordingly, 1910 an ACK from the server would not cover both the ClientHello and the 1911 client's Certificate, because the ClientHello and client Certificate 1912 are in different flights. Implementations can accomplish this by 1913 clearing their ACK list upon receiving the start of the next flight. 1915 After the handshake, ACKs SHOULD be sent once for each received and 1916 processed handshake record (potentially subject to some delay) and 1917 MAY cover more than one flight. This includes records containing 1918 messages which are discarded because a previous copy has been 1919 received. 1921 During the handshake, ACK records MUST be sent with an epoch that is 1922 equal to or higher than the record which is being acknowledged. Note 1923 that some care is required when processing flights spanning multiple 1924 epochs. For instance, if the client receives only the Server Hello 1925 and Certificate and wishes to ACK them in a single record, it must do 1926 so in epoch 2, as it is required to use an epoch greater than or 1927 equal to 2 and cannot yet send with any greater epoch. 1928 Implementations SHOULD simply use the highest current sending epoch, 1929 which will generally be the highest available. After the handshake, 1930 implementations MUST use the highest available sending epoch. 1932 7.1. Sending ACKs 1934 When an implementation detects a disruption in the receipt of the 1935 current incoming flight, it SHOULD generate an ACK that covers the 1936 messages from that flight which it has received and processed so far. 1937 Implementations have some discretion about which events to treat as 1938 signs of disruption, but it is RECOMMENDED that they generate ACKs 1939 under two circumstances: 1941 * When they receive a message or fragment which is out of order, 1942 either because it is not the next expected message or because it 1943 is not the next piece of the current message. 1945 * When they have received part of a flight and do not immediately 1946 receive the rest of the flight (which may be in the same UDP 1947 datagram). A reasonable approach here is to set a timer for 1/4 1948 the current retransmit timer value when the first record in the 1949 flight is received and then send an ACK when that timer expires. 1951 In general, flights MUST be ACKed unless they are implicitly 1952 acknowledged. In the present specification the following flights are 1953 implicitly acknowledged by the receipt of the next flight, which 1954 generally immediately follows the flight, 1956 1. Handshake flights other than the client's final flight of the 1957 main handshake. 1959 2. The server's post-handshake CertificateRequest. 1961 ACKs SHOULD NOT be sent for these flights unless generating the 1962 responding flight takes significant time. In this case, 1963 implementations MAY send explicit ACKs for the complete received 1964 flight even though it will eventually also be implicitly acknowledged 1965 through the responding flight. A notable example for this is the 1966 case of client authentication in constrained environments, where 1967 generating the CertificateVerify message can take considerable time 1968 on the client. All other flights MUST be ACKed. Implementations MAY 1969 acknowledge the records corresponding to each transmission of each 1970 flight or simply acknowledge the most recent one. In general, 1971 implementations SHOULD ACK as many received packets as can fit into 1972 the ACK record, as this provides the most complete information and 1973 thus reduces the chance of spurious retransmission; if space is 1974 limited, implementations SHOULD favor including records which have 1975 not yet been acknowledged. 1977 Note: While some post-handshake messages follow a request/response 1978 pattern, this does not necessarily imply receipt. For example, a 1979 KeyUpdate sent in response to a KeyUpdate with request_update set to 1980 'update_requested' does not implicitly acknowledge the earlier 1981 KeyUpdate message because the two KeyUpdate messages might have 1982 crossed in flight. 1984 ACKs MUST NOT be sent for other records of any content type other 1985 than handshake or for records which cannot be unprotected. 1987 Note that in some cases it may be necessary to send an ACK which does 1988 not contain any record numbers. For instance, a client might receive 1989 an EncryptedExtensions message prior to receiving a ServerHello. 1990 Because it cannot decrypt the EncryptedExtensions, it cannot safely 1991 acknowledge it (as it might be damaged). If the client does not send 1992 an ACK, the server will eventually retransmit its first flight, but 1993 this might take far longer than the actual round trip time between 1994 client and server. Having the client send an empty ACK shortcuts 1995 this process. 1997 7.2. Receiving ACKs 1999 When an implementation receives an ACK, it SHOULD record that the 2000 messages or message fragments sent in the records being ACKed were 2001 received and omit them from any future retransmissions. Upon receipt 2002 of an ACK that leaves it with only some messages from a flight having 2003 been acknowledged an implementation SHOULD retransmit the 2004 unacknowledged messages or fragments. Note that this requires 2005 implementations to track which messages appear in which records. 2006 Once all the messages in a flight have been acknowledged, the 2007 implementation MUST cancel all retransmissions of that flight. 2008 Implementations MUST treat a record as having been acknowledged if it 2009 appears in any ACK; this prevents spurious retransmission in cases 2010 where a flight is very large and the receiver is forced to elide 2011 acknowledgements for records which have already been ACKed. As noted 2012 above, the receipt of any record responding to a given flight MUST be 2013 taken as an implicit acknowledgement for the entire flight. 2015 7.3. Design Rationale 2017 ACK messages are used in two circumstances, namely : 2019 * on sign of disruption, or lack of progress, and 2021 * to indicate complete receipt of the last flight in a handshake. 2023 In the first case the use of the ACK message is optional because the 2024 peer will retransmit in any case and therefore the ACK just allows 2025 for selective retransmission, as opposed to the whole flight 2026 retransmission in previous versions of DTLS. For instance in the 2027 flow shown in Figure 11 if the client does not send the ACK message 2028 when it received record 1 indicating loss of record 0, the entire 2029 flight would be retransmitted. When DTLS 1.3 is used in deployments 2030 with lossy networks, such as low-power, long range radio networks as 2031 well as low-power mesh networks, the use of ACKs is recommended. 2033 The use of the ACK for the second case is mandatory for the proper 2034 functioning of the protocol. For instance, the ACK message sent by 2035 the client in Figure 13, acknowledges receipt and processing of 2036 record 4 (containing the NewSessionTicket message) and if it is not 2037 sent the server will continue retransmission of the NewSessionTicket 2038 indefinitely until its transmission cap is reached. 2040 8. Key Updates 2042 As with TLS 1.3, DTLS 1.3 implementations send a KeyUpdate message to 2043 indicate that they are updating their sending keys. As with other 2044 handshake messages with no built-in response, KeyUpdates MUST be 2045 acknowledged. In order to facilitate epoch reconstruction 2046 Section 4.2.2 implementations MUST NOT send records with the new keys 2047 or send a new KeyUpdate until the previous KeyUpdate has been 2048 acknowledged (this avoids having too many epochs in active use). 2050 Due to loss and/or re-ordering, DTLS 1.3 implementations may receive 2051 a record with an older epoch than the current one (the requirements 2052 above preclude receiving a newer record). They SHOULD attempt to 2053 process those records with that epoch (see Section 4.2.2 for 2054 information on determining the correct epoch), but MAY opt to discard 2055 such out-of-epoch records. 2057 Due to the possibility of an ACK message for a KeyUpdate being lost 2058 and thereby preventing the sender of the KeyUpdate from updating its 2059 keying material, receivers MUST retain the pre-update keying material 2060 until receipt and successful decryption of a message using the new 2061 keys. 2063 Figure 14 shows an example exchange illustrating that a successful 2064 ACK processing updates the keys of the KeyUpdate message sender, 2065 which is reflected in the change of epoch values. 2067 Client Server 2069 /-------------------------------------------\ 2070 | | 2071 | Initial Handshake | 2072 \-------------------------------------------/ 2074 [Application Data] --------> 2075 (epoch=3) 2077 <-------- [Application Data] 2078 (epoch=3) 2080 /-------------------------------------------\ 2081 | | 2082 | Some time later ... | 2083 \-------------------------------------------/ 2085 [Application Data] --------> 2086 (epoch=3) 2088 [KeyUpdate] 2089 (+ update_requested --------> 2090 (epoch 3) 2092 <-------- [Application Data] 2093 (epoch=3) 2095 [Ack] 2096 <-------- (epoch=3) 2098 [Application Data] 2099 (epoch=4) --------> 2101 <-------- [KeyUpdate] 2102 (epoch=3) 2104 [Ack] --------> 2105 (epoch=4) 2107 <-------- [Application Data] 2108 (epoch=4) 2110 Figure 14: Example DTLS Key Update 2112 9. Connection ID Updates 2114 If the client and server have negotiated the "connection_id" 2115 extension [I-D.ietf-tls-dtls-connection-id], either side can send a 2116 new CID which it wishes the other side to use in a NewConnectionId 2117 message. 2119 enum { 2120 cid_immediate(0), cid_spare(1), (255) 2121 } ConnectionIdUsage; 2123 opaque ConnectionId<0..2^8-1>; 2125 struct { 2126 ConnectionIds cids<0..2^16-1>; 2127 ConnectionIdUsage usage; 2128 } NewConnectionId; 2130 cid Indicates the set of CIDs which the sender wishes the peer to 2131 use. 2133 usage Indicates whether the new CIDs should be used immediately or 2134 are spare. If usage is set to "cid_immediate", then one of the 2135 new CID MUST be used immediately for all future records. If it is 2136 set to "cid_spare", then either existing or new CID MAY be used. 2138 Endpoints SHOULD use receiver-provided CIDs in the order they were 2139 provided. Endpoints MUST NOT have more than one NewConnectionId 2140 message outstanding. 2142 Implementations which either did not negotiate the "connection_id" 2143 extension or which have negotiated receiving an empty CID MUST NOT 2144 send NewConnectionId. Implementations MUST NOT send 2145 RequestConnectionId when sending an empty connection ID. 2146 Implementations which detect a violation of these rules MUST 2147 terminate the connection with an "unexpected_message" alert. 2149 Implementations SHOULD use a new CID whenever sending on a new path, 2150 and SHOULD request new CIDs for this purpose if path changes are 2151 anticipated. 2153 struct { 2154 uint8 num_cids; 2155 } RequestConnectionId; 2157 num_cids The number of CIDs desired. 2159 Endpoints SHOULD respond to RequestConnectionId by sending a 2160 NewConnectionId with usage "cid_spare" containing num_cid CIDs soon 2161 as possible. Endpoints MUST NOT send a RequestConnectionId message 2162 when an existing request is still unfulfilled; this implies that 2163 endpoints needs to request new CIDs well in advance. An endpoint MAY 2164 handle requests, which it considers excessive, by responding with a 2165 NewConnectionId message containing fewer than num_cid CIDs, including 2166 no CIDs at all. Endpoints MAY handle an excessive number of 2167 RequestConnectionId messages by terminating the connection using a 2168 "too_many_cids_requested" (alert number 52) alert. 2170 Endpoints MUST NOT send either of these messages if they did not 2171 negotiate a CID. If an implementation receives these messages when 2172 CIDs were not negotiated, it MUST abort the connection with an 2173 unexpected_message alert. 2175 9.1. Connection ID Example 2177 Below is an example exchange for DTLS 1.3 using a single CID in each 2178 direction. 2180 Note: The connection_id extension is defined in 2181 [I-D.ietf-tls-dtls-connection-id], which is used in ClientHello and 2182 ServerHello messages. 2184 Client Server 2185 ------ ------ 2187 ClientHello 2188 (connection_id=5) 2189 --------> 2191 <-------- HelloRetryRequest 2192 (cookie) 2194 ClientHello --------> 2195 (connection_id=5) 2196 +cookie 2198 <-------- ServerHello 2199 (connection_id=100) 2200 EncryptedExtensions 2201 (cid=5) 2202 Certificate 2203 (cid=5) 2204 CertificateVerify 2205 (cid=5) 2206 Finished 2207 (cid=5) 2209 Certificate --------> 2210 (cid=100) 2211 CertificateVerify 2212 (cid=100) 2213 Finished 2214 (cid=100) 2215 <-------- Ack 2216 (cid=5) 2218 Application Data ========> 2219 (cid=100) 2220 <======== Application Data 2221 (cid=5) 2223 Figure 15: Example DTLS 1.3 Exchange with CIDs 2225 If no CID is negotiated, then the receiver MUST reject any records it 2226 receives that contain a CID. 2228 10. Application Data Protocol 2230 Application data messages are carried by the record layer and are 2231 split into records and encrypted based on the current connection 2232 state. The messages are treated as transparent data to the record 2233 layer. 2235 11. Security Considerations 2237 Security issues are discussed primarily in [TLS13]. 2239 The primary additional security consideration raised by DTLS is that 2240 of denial of service by excessive resource consumption. DTLS 2241 includes a cookie exchange designed to protect against denial of 2242 service. However, implementations that do not use this cookie 2243 exchange are still vulnerable to DoS. In particular, DTLS servers 2244 that do not use the cookie exchange may be used as attack amplifiers 2245 even if they themselves are not experiencing DoS. Therefore, DTLS 2246 servers SHOULD use the cookie exchange unless there is good reason to 2247 believe that amplification is not a threat in their environment. 2248 Clients MUST be prepared to do a cookie exchange with every 2249 handshake. 2251 Some key properties required of the cookie for the cookie-exchange 2252 mechanism to be functional are described in Section 3.3 of [RFC2522]: 2254 * the cookie MUST depend on the client's address. 2256 * it MUST NOT be possible for anyone other than the issuing entity 2257 to generate cookies that are accepted as valid by that entity. 2258 This typically entails an integrity check based on a secret key. 2260 * cookie generation and verification are triggered by 2261 unauthenticated parties, and as such their resource consumption 2262 needs to be restrained in order to avoid having the cookie- 2263 exchange mechanism itself serve as a DoS vector. 2265 Although the cookie must allow the server to produce the right 2266 handshake transcript, they SHOULD be constructed so that knowledge of 2267 the cookie is insufficient to reproduce the ClientHello contents. 2268 Otherwise, this may create problems with future extensions such as 2269 [I-D.ietf-tls-esni]. 2271 When cookies are generated using a keyed authentication mechanism it 2272 should be possible to rotate the associated secret key, so that 2273 temporary compromise of the key does not permanently compromise the 2274 integrity of the cookie-exchange mechanism. Though this secret is 2275 not as high-value as, e.g., a session-ticket-encryption key, rotating 2276 the cookie-generation key on a similar timescale would ensure that 2277 the key-rotation functionality is exercised regularly and thus in 2278 working order. 2280 The cookie exchange provides address validation during the initial 2281 handshake. DTLS with connection IDs allow for endpoint addresses to 2282 change during the association; any such updated addresses are not 2283 covered by the cookie exchange during the handshake. DTLS 2284 implementations MUST NOT update the address they send to in response 2285 to packets from a different address unless they first perform some 2286 reachability test; no such test is defined in this specification. 2287 Even with such a test, an active on-path adversary can also black- 2288 hole traffic or create a reflection attack against third parties 2289 because a DTLS peer has no means to distinguish a genuine address 2290 update event (for example, due to a NAT rebinding) from one that is 2291 malicious. This attack is of concern when there is a large asymmetry 2292 of request/response message sizes. 2294 With the exception of order protection and non-replayability, the 2295 security guarantees for DTLS 1.3 are the same as TLS 1.3. While TLS 2296 always provides order protection and non-replayability, DTLS does not 2297 provide order protection and may not provide replay protection. 2299 Unlike TLS implementations, DTLS implementations SHOULD NOT respond 2300 to invalid records by terminating the connection. 2302 TLS 1.3 requires replay protection for 0-RTT data (or rather, for 2303 connections that use 0-RTT data; see Section 8 of [TLS13]). DTLS 2304 provides an optional per-record replay-protection mechanism, since 2305 datagram protocols are inherently subject to message reordering and 2306 replay. These two replay-protection mechanisms are orthogonal, and 2307 neither mechanism meets the requirements for the other. 2309 The security and privacy properties of the CID for DTLS 1.3 builds on 2310 top of what is described for DTLS 1.2 in 2311 [I-D.ietf-tls-dtls-connection-id]. There are, however, several 2312 differences: 2314 * In both versions of DTLS extension negotiation is used to agree on 2315 the use of the CID feature and the CID values. In both versions 2316 the CID is carried in the DTLS record header (if negotiated). 2317 However, the way the CID is included in the record header differs 2318 between the two versions. 2320 * The use of the Post-Handshake message allows the client and the 2321 server to update their CIDs and those values are exchanged with 2322 confidentiality protection. 2324 * The ability to use multiple CIDs allows for improved privacy 2325 properties in multi-homed scenarios. When only a single CID is in 2326 use on multiple paths from such a host, an adversary can correlate 2327 the communication interaction across paths, which adds further 2328 privacy concerns. In order to prevent this, implementations 2329 SHOULD attempt to use fresh CIDs whenever they change local 2330 addresses or ports (though this is not always possible to detect). 2331 The RequestConnectionId message can be used by a peer to ask for 2332 new CIDs to ensure that a pool of suitable CIDs is available. 2334 * The mechanism for encrypting sequence numbers (Section 4.2.3) 2335 prevents trivial tracking by on-path adversaries that attempt to 2336 correlate the pattern of sequence numbers received on different 2337 paths; such tracking could occur even when different CIDs are used 2338 on each path, in the absence of sequence number encryption. 2339 Switching CIDs based on certain events, or even regularly, helps 2340 against tracking by on-path adversaries. Note that sequence 2341 number encryption is used for all encrypted DTLS 1.3 records 2342 irrespective of whether a CID is used or not. Unlike the sequence 2343 number, the epoch is not encrypted because it acts as a key 2344 identifier, which may improve correlation of packets from a single 2345 connection across different network paths. 2347 * DTLS 1.3 encrypts handshake messages much earlier than in previous 2348 DTLS versions. Therefore, less information identifying the DTLS 2349 client, such as the client certificate, is available to an on-path 2350 adversary. 2352 12. Changes since DTLS 1.2 2354 Since TLS 1.3 introduces a large number of changes with respect to 2355 TLS 1.2, the list of changes from DTLS 1.2 to DTLS 1.3 is equally 2356 large. For this reason this section focuses on the most important 2357 changes only. 2359 * New handshake pattern, which leads to a shorter message exchange 2361 * Only AEAD ciphers are supported. Additional data calculation has 2362 been simplified. 2364 * Removed support for weaker and older cryptographic algorithms 2366 * HelloRetryRequest of TLS 1.3 used instead of HelloVerifyRequest 2368 * More flexible ciphersuite negotiation 2370 * New session resumption mechanism 2371 * PSK authentication redefined 2373 * New key derivation hierarchy utilizing a new key derivation 2374 construct 2376 * Improved version negotiation 2378 * Optimized record layer encoding and thereby its size 2380 * Added CID functionality 2382 * Sequence numbers are encrypted. 2384 13. Updates affecting DTLS 1.2 2386 This document defines several changes that optionally affect 2387 implementations of DTLS 1.2, including those which do not also 2388 support DTLS 1.3. 2390 * A version downgrade protection mechanism as described in 2391 [RFC8446]; Section 4.1.3 and applying to DTLS as described in 2392 Section 5.3. 2394 * The updates described in [RFC8446]; Section 3. 2396 * The new compliance requirements described in [RFC8446]; 2397 Section 9.3. 2399 14. IANA Considerations 2401 IANA is requested to allocate a new value in the "TLS ContentType" 2402 registry for the ACK message, defined in Section 7, with content type 2403 26. The value for the "DTLS-OK" column is "Y". IANA is requested to 2404 reserve the content type range 32-63 so that content types in this 2405 range are not allocated. 2407 IANA is requested to allocate "the too_many_cids_requested" alert in 2408 the "TLS Alerts" registry with value 52. 2410 IANA is requested to allocate two values in the "TLS Handshake Type" 2411 registry, defined in [TLS13], for RequestConnectionId (TBD), and 2412 NewConnectionId (TBD), as defined in this document. The value for 2413 the "DTLS-OK" columns are "Y". 2415 IANA is requested to add this RFC as a reference to the TLS Cipher 2416 Suite Registry. 2418 15. References 2419 15.1. Normative References 2421 [CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 2422 Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, 2423 . 2425 [I-D.ietf-tls-dtls-connection-id] 2426 Rescorla, E., Tschofenig, H., and T. Fossati, "Connection 2427 Identifiers for DTLS 1.2", Work in Progress, Internet- 2428 Draft, draft-ietf-tls-dtls-connection-id-09, 17 January 2429 2021, . 2432 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2433 DOI 10.17487/RFC0768, August 1980, 2434 . 2436 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2437 RFC 793, DOI 10.17487/RFC0793, September 1981, 2438 . 2440 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2441 DOI 10.17487/RFC1191, November 1990, 2442 . 2444 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2445 Requirement Levels", BCP 14, RFC 2119, 2446 DOI 10.17487/RFC2119, March 1997, 2447 . 2449 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2450 Control Message Protocol (ICMPv6) for the Internet 2451 Protocol Version 6 (IPv6) Specification", STD 89, 2452 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2453 . 2455 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 2456 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 2457 . 2459 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 2460 "Computing TCP's Retransmission Timer", RFC 6298, 2461 DOI 10.17487/RFC6298, June 2011, 2462 . 2464 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2465 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2466 May 2017, . 2468 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2469 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2470 . 2472 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2473 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2474 . 2476 15.2. Informative References 2478 [AEBounds] Luykx, A. and K. Paterson, "Limits on Authenticated 2479 Encryption Use in TLS", 8 March 2016, 2480 . 2482 [CCM-ANALYSIS] 2483 Jonsson, J., "On the Security of CTR + CBC-MAC", Selected 2484 Areas in Cryptography pp. 76-93, 2485 DOI 10.1007/3-540-36492-7_7, 2003, 2486 . 2488 [DEPRECATE] 2489 Moriarty, K. and S. Farrell, "Deprecating TLSv1.0 and 2490 TLSv1.1", Work in Progress, Internet-Draft, draft-ietf- 2491 tls-oldversions-deprecate-12, 21 January 2021, 2492 . 2495 [I-D.ietf-tls-esni] 2496 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS 2497 Encrypted Client Hello", Work in Progress, Internet-Draft, 2498 draft-ietf-tls-esni-09, 16 December 2020, 2499 . 2502 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 2503 Protocol", RFC 2522, DOI 10.17487/RFC2522, March 1999, 2504 . 2506 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 2507 RFC 4303, DOI 10.17487/RFC4303, December 2005, 2508 . 2510 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2511 Congestion Control Protocol (DCCP)", RFC 4340, 2512 DOI 10.17487/RFC4340, March 2006, 2513 . 2515 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 2516 (TLS) Protocol Version 1.1", RFC 4346, 2517 DOI 10.17487/RFC4346, April 2006, 2518 . 2520 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2521 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 2522 . 2524 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 2525 RFC 4960, DOI 10.17487/RFC4960, September 2007, 2526 . 2528 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 2529 the Datagram Congestion Control Protocol (DCCP)", 2530 RFC 5238, DOI 10.17487/RFC5238, May 2008, 2531 . 2533 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2534 (TLS) Protocol Version 1.2", RFC 5246, 2535 DOI 10.17487/RFC5246, August 2008, 2536 . 2538 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2539 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2540 January 2012, . 2542 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 2543 Kivinen, "Internet Key Exchange Protocol Version 2 2544 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2545 2014, . 2547 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2548 "Recommendations for Secure Use of Transport Layer 2549 Security (TLS) and Datagram Transport Layer Security 2550 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2551 2015, . 2553 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 2554 (TLS) Cached Information Extension", RFC 7924, 2555 DOI 10.17487/RFC7924, July 2016, 2556 . 2558 [RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme 2559 Updates for Secure Real-time Transport Protocol (SRTP) 2560 Extension for Datagram Transport Layer Security (DTLS)", 2561 RFC 7983, DOI 10.17487/RFC7983, September 2016, 2562 . 2564 [RFC8879] Ghedini, A. and V. Vasiliev, "TLS Certificate 2565 Compression", RFC 8879, DOI 10.17487/RFC8879, December 2566 2020, . 2568 [ROBUST] Fischlin, M., Günther, F., and C. Janson, "Robust 2569 Channels: Handling Unreliable Networks in the Record 2570 Layers of QUIC and DTLS 1.3", 15 June 2020, 2571 . 2573 Appendix A. Protocol Data Structures and Constant Values 2575 This section provides the normative protocol types and constants 2576 definitions. 2578 A.1. Record Layer 2579 struct { 2580 ContentType type; 2581 ProtocolVersion legacy_record_version; 2582 uint16 epoch = 0 2583 uint48 sequence_number; 2584 uint16 length; 2585 opaque fragment[DTLSPlaintext.length]; 2586 } DTLSPlaintext; 2588 struct { 2589 opaque content[DTLSPlaintext.length]; 2590 ContentType type; 2591 uint8 zeros[length_of_padding]; 2592 } DTLSInnerPlaintext; 2594 struct { 2595 opaque unified_hdr[variable]; 2596 opaque encrypted_record[length]; 2597 } DTLSCiphertext; 2599 0 1 2 3 4 5 6 7 2600 +-+-+-+-+-+-+-+-+ 2601 |0|0|1|C|S|L|E E| 2602 +-+-+-+-+-+-+-+-+ 2603 | Connection ID | Legend: 2604 | (if any, | 2605 / length as / C - Connection ID (CID) present 2606 | negotiated) | S - Sequence number length 2607 +-+-+-+-+-+-+-+-+ L - Length present 2608 | 8 or 16 bit | E - Epoch 2609 |Sequence Number| 2610 +-+-+-+-+-+-+-+-+ 2611 | 16 bit Length | 2612 | (if present) | 2613 +-+-+-+-+-+-+-+-+ 2615 struct { 2616 uint16 epoch; 2617 uint48 sequence_number; 2618 } RecordNumber; 2620 A.2. Handshake Protocol 2621 enum { 2622 hello_request_RESERVED(0), 2623 client_hello(1), 2624 server_hello(2), 2625 hello_verify_request_RESERVED(3), 2626 new_session_ticket(4), 2627 end_of_early_data(5), 2628 hello_retry_request_RESERVED(6), 2629 encrypted_extensions(8), 2630 certificate(11), 2631 server_key_exchange_RESERVED(12), 2632 certificate_request(13), 2633 server_hello_done_RESERVED(14), 2634 certificate_verify(15), 2635 client_key_exchange_RESERVED(16), 2636 finished(20), 2637 certificate_url_RESERVED(21), 2638 certificate_status_RESERVED(22), 2639 supplemental_data_RESERVED(23), 2640 key_update(24), 2641 message_hash(254), 2642 (255) 2643 } HandshakeType; 2645 struct { 2646 HandshakeType msg_type; /* handshake type */ 2647 uint24 length; /* bytes in message */ 2648 uint16 message_seq; /* DTLS-required field */ 2649 uint24 fragment_offset; /* DTLS-required field */ 2650 uint24 fragment_length; /* DTLS-required field */ 2651 select (HandshakeType) { 2652 case client_hello: ClientHello; 2653 case server_hello: ServerHello; 2654 case end_of_early_data: EndOfEarlyData; 2655 case encrypted_extensions: EncryptedExtensions; 2656 case certificate_request: CertificateRequest; 2657 case certificate: Certificate; 2658 case certificate_verify: CertificateVerify; 2659 case finished: Finished; 2660 case new_session_ticket: NewSessionTicket; 2661 case key_update: KeyUpdate; 2662 } body; 2663 } Handshake; 2665 uint16 ProtocolVersion; 2666 opaque Random[32]; 2668 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 2669 struct { 2670 ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2 2671 Random random; 2672 opaque legacy_session_id<0..32>; 2673 opaque legacy_cookie<0..2^8-1>; // DTLS 2674 CipherSuite cipher_suites<2..2^16-2>; 2675 opaque legacy_compression_methods<1..2^8-1>; 2676 Extension extensions<8..2^16-1>; 2677 } ClientHello; 2679 A.3. ACKs 2681 struct { 2682 RecordNumber record_numbers<0..2^16-1>; 2683 } ACK; 2685 A.4. Connection ID Management 2687 enum { 2688 cid_immediate(0), cid_spare(1), (255) 2689 } ConnectionIdUsage; 2691 opaque ConnectionId<0..2^8-1>; 2693 struct { 2694 ConnectionIds cids<0..2^16-1>; 2695 ConnectionIdUsage usage; 2696 } NewConnectionId; 2698 struct { 2699 uint8 num_cids; 2700 } RequestConnectionId; 2702 Appendix B. Analysis of Limits on CCM Usage 2704 TLS [TLS13] and [AEBounds] do not specify limits on key usage for 2705 AEAD_AES_128_CCM. However, any AEAD that is used with DTLS requires 2706 limits on use that ensure that both confidentiality and integrity are 2707 preserved. This section documents that analysis for 2708 AEAD_AES_128_CCM. 2710 [CCM-ANALYSIS] is used as the basis of this analysis. The results of 2711 that analysis are used to derive usage limits that are based on those 2712 chosen in [TLS13]. 2714 This analysis uses symbols for multiplication (*), division (/), and 2715 exponentiation (^), plus parentheses for establishing precedence. 2716 The following symbols are also used: 2718 t: The size of the authentication tag in bits. For this cipher, t 2719 is 128. 2721 n: The size of the block function in bits. For this cipher, n is 2722 128. 2724 l: The number of blocks in each packet (see below). 2726 q: The number of genuine packets created and protected by endpoints. 2727 This value is the bound on the number of packets that can be 2728 protected before updating keys. 2730 v: The number of forged packets that endpoints will accept. This 2731 value is the bound on the number of forged packets that an 2732 endpoint can reject before updating keys. 2734 The analysis of AEAD_AES_128_CCM relies on a count of the number of 2735 block operations involved in producing each message. For simplicity, 2736 and to match the analysis of other AEAD functions in [AEBounds], this 2737 analysis assumes a packet length of 2^10 blocks and a packet size 2738 limit of 2^14 bytes. 2740 For AEAD_AES_128_CCM, the total number of block cipher operations is 2741 the sum of: the length of the associated data in blocks, the length 2742 of the ciphertext in blocks, and the length of the plaintext in 2743 blocks, plus 1. In this analysis, this is simplified to a value of 2744 twice the maximum length of a record in blocks (that is, "2l = 2745 2^11"). This simplification is based on the associated data being 2746 limited to one block. 2748 B.1. Confidentiality Limits 2750 For confidentiality, Theorem 2 in [CCM-ANALYSIS] establishes that an 2751 attacker gains a distinguishing advantage over an ideal pseudorandom 2752 permutation (PRP) of no more than: 2754 (2l * q)^2 / 2^n 2756 For a target advantage of 2^-60, which matches that used by [TLS13], 2757 this results in the relation: 2759 q <= 2^23 2761 That is, endpoints cannot protect more than 2^23 packets with the 2762 same set of keys without causing an attacker to gain an larger 2763 advantage than the target of 2^-60. 2765 B.2. Integrity Limits 2767 For integrity, Theorem 1 in [CCM-ANALYSIS] establishes that an 2768 attacker gains an advantage over an ideal PRP of no more than: 2770 v / 2^t + (2l * (v + q))^2 / 2^n 2772 The goal is to limit this advantage to 2^-57, to match the target in 2773 [TLS13]. As "t" and "n" are both 128, the first term is negligible 2774 relative to the second, so that term can be removed without a 2775 significant effect on the result. This produces the relation: 2777 v + q <= 2^24.5 2779 Using the previously-established value of 2^23 for "q" and rounding, 2780 this leads to an upper limit on "v" of 2^23.5. That is, endpoints 2781 cannot attempt to authenticate more than 2^23.5 packets with the same 2782 set of keys without causing an attacker to gain an larger advantage 2783 than the target of 2^-57. 2785 B.3. Limits for AEAD_AES_128_CCM_8 2787 The TLS_AES_128_CCM_8_SHA256 cipher suite uses the AEAD_AES_128_CCM_8 2788 function, which uses a short authentication tag (that is, t=64). 2790 The confidentiality limits of AEAD_AES_128_CCM_8 are the same as 2791 those for AEAD_AES_128_CCM, as this does not depend on the tag 2792 length; see Appendix B.1. 2794 The shorter tag length of 64 bits means that the simplification used 2795 in Appendix B.2 does not apply to AEAD_AES_128_CCM_8. If the goal is 2796 to preserve the same margins as other cipher suites, then the limit 2797 on forgeries is largely dictated by the first term of the advantage 2798 formula: 2800 v <= 2^7 2802 As this represents attempts to fail authentication, applying this 2803 limit might be feasible in some environments. However, applying this 2804 limit in an implementation intended for general use exposes 2805 connections to an inexpensive denial of service attack. 2807 This analysis supports the view that TLS_AES_128_CCM_8_SHA256 is not 2808 suitable for general use. Specifically, TLS_AES_128_CCM_8_SHA256 2809 cannot be used without additional measures to prevent forgery of 2810 records, or to mitigate the effect of forgeries. This might require 2811 understanding the constraints that exist in a particular deployment 2812 or application. For instance, it might be possible to set a 2813 different target for the advantage an attacker gains based on an 2814 understanding of the constraints imposed on a specific usage of DTLS. 2816 Appendix C. Implementation Pitfalls 2818 In addition to the aspects of TLS that have been a source of 2819 interoperability and security problems (Section C.3 of [TLS13]), DTLS 2820 presents a few new potential sources of issues, noted here. 2822 * Do you correctly handle messages received from multiple epochs 2823 during a key transition? This includes locating the correct key 2824 as well as performing replay detection, if enabled. 2826 * Do you retransmit handshake messages that are not (implicitly or 2827 explicitly) acknowledged (Section 5.8)? 2829 * Do you correctly handle handshake message fragments received, 2830 including when they are out of order? 2832 * Do you correctly handle handshake messages received out of order? 2833 This may include either buffering or discarding them. 2835 * Do you limit how much data you send to a peer before its address 2836 is validated? 2838 * Do you verify that the explicit record length is contained within 2839 the datagram in which it is contained? 2841 Appendix D. History 2843 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 2845 (*) indicates a change that may affect interoperability. 2847 IETF Drafts 2849 draft-40 2850 - Clarified encrypted_record structure in DTLS 1.3 record layer 2851 - Added description of the demultiplexing process 2852 - Added text about the DTLS 1.2 and DTLS 1.3 CID mechanism 2853 - Forbid going from an empty CID to a non-empty CID (*) 2854 - Add warning about certificates and congestion 2855 - Use DTLS style version values, even for DTLS 1.3 (*) 2856 - Describe how to distinguish DTLS 1.2 and DTLS 1.3 connections 2857 - Updated examples 2858 - Included editorial improvements from Ben Kaduk 2859 - Removed stale text about out-of-epoch records 2860 - Added clarifications around when ACKs are sent 2861 - Noted that alerts are unreliable 2862 - Clarify when you can reset the timer 2863 - Indicated that records with bogus epochs should be discarded 2864 - Relax age out text 2865 - Updates to cookie text 2866 - Require that cipher suites define a record number encryption algorithm 2867 - Clean up use of connection and association 2868 - Reference tls-old-versions-deprecate 2870 draft-39 - Updated Figure 4 due to misalignment with Figure 3 content 2872 draft-38 - Ban implicit connection IDs (*) - ACKs are processed as 2873 the union. 2875 draft-37: - Fix the other place where we have ACK. 2877 draft-36: - Some editorial changes. - Changed the content type to not 2878 conflict with existing allocations (*) 2880 draft-35: - I-D.ietf-tls-dtls-connection-id became a normative 2881 reference - Removed duplicate reference to I-D.ietf-tls-dtls- 2882 connection-id. - Fix figure 11 to have the right numbers andno cookie 2883 in message 1. - Clarify when you can ACK. - Clarify additional data 2884 computation. 2886 draft-33: - Key separation between TLS and DTLS. Issue #72. 2888 draft-32: - Editorial improvements and clarifications. 2890 draft-31: - Editorial improvements in text and figures. - Added 2891 normative reference to ChaCha20 and Poly1305. 2893 draft-30: - Changed record format - Added text about end of early 2894 data - Changed format of the Connection ID Update message - Added 2895 Appendix A "Protocol Data Structures and Constant Values" 2896 draft-29: - Added support for sequence number encryption - Update to 2897 new record format - Emphasize that compatibility mode isn't used. 2899 draft-28: - Version bump to align with TLS 1.3 pre-RFC version. 2901 draft-27: - Incorporated unified header format. - Added support for 2902 CIDs. 2904 draft-04 - 26: - Submissions to align with TLS 1.3 draft versions 2906 draft-03 - Only update keys after KeyUpdate is ACKed. 2908 draft-02 - Shorten the protected record header and introduce an 2909 ultra-short version of the record header. - Reintroduce KeyUpdate, 2910 which works properly now that we have ACK. - Clarify the ACK rules. 2912 draft-01 - Restructured the ACK to contain a list of records and also 2913 be a record rather than a handshake message. 2915 draft-00 - First IETF Draft 2917 Personal Drafts draft-01 - Alignment with version -19 of the TLS 1.3 2918 specification 2920 draft-00 2922 * Initial version using TLS 1.3 as a baseline. 2924 * Use of epoch values instead of KeyUpdate message 2926 * Use of cookie extension instead of cookie field in ClientHello and 2927 HelloVerifyRequest messages 2929 * Added ACK message 2931 * Text about sequence number handling 2933 Appendix E. Working Group Information 2935 RFC EDITOR: PLEASE REMOVE THIS SECTION. 2937 The discussion list for the IETF TLS working group is located at the 2938 e-mail address tls@ietf.org (mailto:tls@ietf.org). Information on 2939 the group and information on how to subscribe to the list is at 2940 https://www1.ietf.org/mailman/listinfo/tls 2941 (https://www1.ietf.org/mailman/listinfo/tls) 2942 Archives of the list can be found at: https://www.ietf.org/mail- 2943 archive/web/tls/current/index.html (https://www.ietf.org/mail- 2944 archive/web/tls/current/index.html) 2946 Appendix F. Contributors 2948 Many people have contributed to previous DTLS versions and they are 2949 acknowledged in prior versions of DTLS specifications or in the 2950 referenced specifications. The sequence number encryption concept is 2951 taken from the QUIC specification. We would like to thank the 2952 authors of the QUIC specification for their work. Felix Guenther and 2953 Martin Thomson contributed the analysis in Appendix B. 2955 In addition, we would like to thank: 2957 * David Benjamin 2958 Google 2959 davidben@google.com 2961 * Thomas Fossati 2962 Arm Limited 2963 Thomas.Fossati@arm.com 2965 * Tobias Gondrom 2966 Huawei 2967 tobias.gondrom@gondrom.org 2969 * Felix Günther 2970 ETH Zurich 2971 mail@felixguenther.info 2973 * Ilari Liusvaara 2974 Independent 2975 ilariliusvaara@welho.com 2977 * Martin Thomson 2978 Mozilla 2979 martin.thomson@gmail.com 2981 * Christopher A. Wood 2982 Apple Inc. 2983 cawood@apple.com 2985 * Yin Xinxing 2986 Huawei 2987 yinxinxing@huawei.com 2989 * Hanno Becker 2990 Arm Limited 2991 Hanno.Becker@arm.com 2993 Appendix G. Acknowledgements 2995 We would like to thank Jonathan Hammell and Andy Cunningham for their 2996 review comments. 2998 Authors' Addresses 3000 Eric Rescorla 3001 RTFM, Inc. 3003 Email: ekr@rtfm.com 3005 Hannes Tschofenig 3006 Arm Limited 3008 Email: hannes.tschofenig@arm.com 3010 Nagendra Modadugu 3011 Google, Inc. 3013 Email: nagendra@cs.stanford.edu