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