idnits 2.17.1 draft-ietf-tls-rfc4347-bis-06.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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 4, 2011) is 4672 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ChangeCipherSpec' is mentioned on line 950, but not defined ** Obsolete normative reference: RFC 1885 (Obsoleted by RFC 2463) ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 5246 (ref. 'TLS12') (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 4347 (ref. 'DTLS1') (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. 'IKEv2') (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 4346 (ref. 'TLS11') (Obsoleted by RFC 5246) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT E. Rescorla 3 Obsoletes (if approved): RFC 4347 RTFM, Inc. 4 Intended Status: Proposed Standard N. Modadugu 5 Expires: January 4, 2012 Stanford University 6 July 4, 2011 8 Datagram Transport Layer Security version 1.2 9 draft-ietf-tls-rfc4347-bis-06.txt 11 Abstract 13 This document specifies Version 1.2 of the Datagram Transport Layer 14 Security (DTLS) protocol. The DTLS protocol provides communications 15 privacy for datagram protocols. The protocol allows client/server 16 applications to communicate in a way that is designed to prevent 17 eavesdropping, tampering, or message forgery. The DTLS protocol is 18 based on the Transport Layer Security (TLS) protocol and provides 19 equivalent security guarantees. Datagram semantics of the underlying 20 transport are preserved by the DTLS protocol. This document 21 updates DTLS 1.0 to work with TLS version 1.2. 23 Legal 25 This documents and the information contained therein are provided on 26 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 27 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 28 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 29 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 30 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 31 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 32 FOR A PARTICULAR PURPOSE. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 14, 2011. 50 Copyright Notice 52 Copyright (c) 2011 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction 3 80 1.1. Requirements Terminology 4 81 2. Usage Model 4 82 3. Overview of DTLS 5 83 3.1. Loss-Insensitive Messaging 5 84 3.2. Providing Reliability for Handshake 5 85 3.2.1. Packet Loss 6 86 3.2.2. Reordering 6 87 3.2.3. Message Size 7 88 3.3. Replay Detection 7 89 4. Differences from TLS 7 90 4.1. Record Layer 7 91 4.1.1. Transport Layer Mapping 9 92 4.1.1.1. PMTU Issues 10 93 4.1.2. Record Payload Protection 12 94 4.1.2.1. MAC 12 95 4.1.2.2. Null or Standard Stream Cipher 12 96 4.1.2.3. Block Cipher 12 97 4.1.2.3. AEAD Ciphers 13 98 4.1.2.5. New Cipher Suites 13 99 4.1.2.6. Anti-replay 13 100 4.1.2.7. Handling Invalid Records 14 101 4.2. The DTLS Handshake Protocol 14 102 4.2.1. Denial of Service Countermeasures 14 103 4.2.2. Handshake Message Format 17 104 4.2.3. Handshake Message Fragmentation and Reassembly 19 105 4.2.4. Timeout and Retransmission 19 106 4.2.4.1. Timer Values 24 107 4.2.5. ChangeCipherSpec 24 108 4.2.6. CertificateVerify and Finished Messages 25 109 4.2.7. Alert Messages 25 110 4.2.8. Establishing New Associations With Existing Parameters 25 111 4.3. Summary of new syntax 26 112 4.3.1. Record Layer 27 113 4.3.2. Handshake Protocol 27 114 5. Security Considerations 28 115 6. Acknowledgements 30 116 7. IANA Considerations 30 117 8. Changes Since DTLS 1.0 30 118 9. References 31 119 9.1. Normative References 31 120 9.2. Informative References 32 122 1. Introduction 124 TLS [TLS] is the most widely deployed protocol for securing network 125 traffic. It is widely used for protecting Web traffic and for e-mail 126 protocols such as IMAP [IMAP] and POP [POP]. The primary advantage 127 of TLS is that it provides a transparent connection-oriented channel. 128 Thus, it is easy to secure an application protocol by inserting TLS 129 between the application layer and the transport layer. However, TLS 130 must run over a reliable transport channel -- typically TCP [TCP]. 131 It therefore cannot be used to secure unreliable datagram traffic. 133 However, an increasing number of application layer protocols have 134 been designed that use UDP transport. In particular protocols such 135 as the Session Initiation Protocol (SIP) [SIP] and electronic gaming 136 protocols are increasingly popular. (Note that SIP can run over both 137 TCP and UDP, but that there are situations in which UDP is 138 preferable). Currently, designers of these applications are faced 139 with a number of unsatisfactory choices. First, they can use IPsec 140 [RFC4301]. However, for a number of reasons detailed in [WHYIPSEC], 141 this is only suitable for some applications. Second, they can design 142 a custom application layer security protocol. Unfortunately, 143 although application layer security protocols generally provide 144 superior security properties (e.g., end-to-end security in the case 145 of S/MIME), they typically require a large amount of effort to design 146 -- in contrast to the relatively small amount of effort required to 147 run the protocol over TLS. 149 In many cases, the most desirable way to secure client/server 150 applications would be to use TLS; however, the requirement for 151 datagram semantics automatically prohibits use of TLS. This memo 152 describes a protocol for this purpose: Datagram Transport Layer 153 Security (DTLS). DTLS is deliberately designed to be as similar to 154 TLS as possible, both to minimize new security invention and to 155 maximize the amount of code and infrastructure reuse. 157 DTLS 1.0 [DTLS1] was originally defined as a delta from [TLS11]. This 158 document introduces a new version of DTLS, DTLS 1.2, which is defined 159 as a series of deltas to TLS 1.2 [TLS12] There is no DTLS 1.1. That 160 version number was skipped in order to harmonize version numbers with 161 TLS. This version also clarifies some confusing points in the DTLS 162 1.0 specification. 164 Implementations that speak both DTLS 1.2 and DTLS 1.0 can 165 interoperate with those that speak only DTLS 1.0 (using DTLS 1.0 of 166 course), just as TLS 1.2 implementations can interoperate with 167 previous versions (See Appendix E.1 of [TLS12] for details) with the 168 exception that there is no DTLS version of SSLv2 or SSLv3 so that the 169 backward compatibility issues for those protocols do not apply. 171 1.1. Requirements Terminology 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in RFC 2119 [REQ]. 177 2. Usage Model 179 The DTLS protocol is designed to secure data between communicating 180 applications. It is designed to run in application space, without 181 requiring any kernel modifications. 183 Datagram transport does not require or provide reliable or in-order 184 delivery of data. The DTLS protocol preserves this property for 185 payload data. Applications such as media streaming, Internet 186 telephony, and online gaming use datagram transport for communication 187 due to the delay-sensitive nature of transported data. The behavior 188 of such applications is unchanged when the DTLS protocol is used to 189 secure communication, since the DTLS protocol does not compensate for 190 lost or re-ordered data traffic. 192 3. Overview of DTLS 194 The basic design philosophy of DTLS is to construct "TLS over 195 datagram transport." The reason that TLS cannot be used directly in 196 datagram environments is simply that packets may be lost or 197 reordered. TLS has no internal facilities to handle this kind of 198 unreliability, and therefore TLS implementations break when rehosted 199 on datagram transport. The purpose of DTLS is to make only the 200 minimal changes to TLS required to fix this problem. To the greatest 201 extent possible, DTLS is identical to TLS. Whenever we need to 202 invent new mechanisms, we attempt to do so in such a way that 203 preserves the style of TLS. 205 Unreliability creates problems for TLS at two levels: 207 1. TLS does not allow independent decryption of individual 208 records. Because the integrity check depends on the sequence 209 number, if record N is not received, then the integrity check on 210 record N+1 will be based on the wrong sequence number and thus 211 will fail. [Note that prior to TLS 1.1, there was no explicit IV 212 and so decryption would also fail.] 214 2. The TLS handshake layer assumes that handshake messages are 215 delivered reliably and breaks if those messages are lost. 217 The rest of this section describes the approach that DTLS uses to 218 solve these problems. 220 3.1. Loss-Insensitive Messaging 222 In TLS's traffic encryption layer (called the TLS Record Layer), 223 records are not independent. There are two kinds of inter-record 224 dependency: 226 1. Cryptographic context (stream cipher key stream) is retained 227 between records. 229 2. Anti-replay and message reordering protection are provided by a 230 MAC that includes a sequence number, but the sequence numbers are 231 implicit in the records. 233 DTLS solves the first problem by banning stream ciphers. DTLS solves 234 the second problem by adding explicit sequence numbers. 236 3.2. Providing Reliability for Handshake 238 The TLS handshake is a lockstep cryptographic handshake. Messages 239 must be transmitted and received in a defined order, and any other 240 order is an error. Clearly, this is incompatible with reordering and 241 message loss. In addition, TLS handshake messages are potentially 242 larger than any given datagram, thus creating the problem of IP 243 fragmentation. DTLS must provide fixes for both of these problems. 245 3.2.1. Packet Loss 247 DTLS uses a simple retransmission timer to handle packet loss. The 248 following figure demonstrates the basic concept, using the first 249 phase of the DTLS handshake: 251 Client Server 252 ------ ------ 253 ClientHello ------> 255 X<-- HelloVerifyRequest 256 (lost) 258 [Timer Expires] 260 ClientHello ------> 261 (retransmit) 263 Once the client has transmitted the ClientHello message, it expects 264 to see a HelloVerifyRequest from the server. However, if the 265 server's message is lost the client knows that either the ClientHello 266 or the HelloVerifyRequest has been lost and retransmits. When the 267 server receives the retransmission, it knows to retransmit. The 268 server also maintains a retransmission timer and retransmits when 269 that timer expires. 271 Note: timeout and retransmission do not apply to the 272 HelloVerifyRequest, because this requires creating state on the 273 server. 275 Note: The HelloVerifyRequest is designed to be small enough that it 276 will not itself be fragmented, thus avoiding concerns about 277 interleaving multiple HelloVerifyRequests. 279 3.2.2. Reordering 281 In DTLS, each handshake message is assigned a specific sequence 282 number within that handshake. When a peer receives a handshake 283 message, it can quickly determine whether that message is the next 284 message it expects. If it is, then it processes it. If not, it 285 queues it up for future handling once all previous messages have been 286 received. 288 3.2.3. Message Size 290 TLS and DTLS handshake messages can be quite large (in theory up to 291 2^24-1 bytes, in practice many kilobytes). By contrast, UDP 292 datagrams are often limited to <1500 bytes if IP fragmentation is not 293 desired. In order to compensate for this limitation, each DTLS 294 handshake message may be fragmented over several DTLS records, each 295 of which is intended to fit in a single IP datagram. Each DTLS 296 handshake message contains both a fragment offset and a fragment 297 length. Thus, a recipient in possession of all bytes of a handshake 298 message can reassemble the original unfragmented message. 300 3.3. Replay Detection 302 DTLS optionally supports record replay detection. The technique used 303 is the same as in IPsec AH/ESP, by maintaining a bitmap window of 304 received records. Records that are too old to fit in the window and 305 records that have previously been received are silently discarded. 306 The replay detection feature is optional, since packet duplication is 307 not always malicious, but can also occur due to routing errors. 308 Applications may conceivably detect duplicate packets and accordingly 309 modify their data transmission strategy. 311 4. Differences from TLS 313 As mentioned in Section 3, DTLS is intentionally very similar to TLS. 314 Therefore, instead of presenting DTLS as a new protocol, we present 315 it as a series of deltas from TLS 1.2 [TLS12]. Where we do not 316 explicitly call out differences, DTLS is the same as in [TLS12]. 318 4.1. Record Layer 320 The DTLS record layer is extremely similar to that of TLS 1.2. The 321 only change is the inclusion of an explicit sequence number in the 322 record. This sequence number allows the recipient to correctly 323 verify the TLS MAC. The DTLS record format is shown below: 325 struct { 326 ContentType type; 327 ProtocolVersion version; 328 uint16 epoch; // New field 329 uint48 sequence_number; // New field 330 uint16 length; 331 opaque fragment[DTLSPlaintext.length]; 332 } DTLSPlaintext; 334 type 335 Equivalent to the type field in a TLS 1.2 record. 337 version 338 The version of the protocol being employed. This document 339 describes DTLS Version 1.2, which uses the version { 254, 253 340 }. The version value of 254.253 is the 1's complement of DTLS 341 Version 1.2. This maximal spacing between TLS and DTLS version 342 numbers ensures that records from the two protocols can be 343 easily distinguished. It should be noted that future on-the-wire 344 version numbers of DTLS are decreasing in value (while the true 345 version number is increasing in value.) 347 epoch 348 A counter value that is incremented on every cipher state 349 change. 351 sequence_number 352 The sequence number for this record. 354 length 355 Identical to the length field in a TLS 1.2 record. As in TLS 356 1.2, the length should not exceed 2^14. 358 fragment 359 Identical to the fragment field of a TLS 1.2 record. 361 DTLS uses an explicit sequence number, rather than an implicit one, 362 carried in the sequence_number field of the record. Sequence numbers 363 are maintained separately for each epoch, with each sequence_number 364 initially being 0 for each epoch. For instance, if a handshake 365 message from epoch 0 is retransmitted, it might have a sequence 366 number after a message from epoch 1, even if the message from epoch 1 367 was transmitted first. Note that some care needs to be taken during 368 the handshake to ensure that retransmitted messages use the right 369 epoch and keying material. 371 If several handshakes are performed in close succession, there might 372 be multiple records on the wire with the same sequence number but 373 from different cipher states. The epoch field allows recipients to 374 distinguish such packets. The epoch number is initially zero and is 375 incremented each time the ChangeCipherSpec messages is sent. In 376 order to ensure that any given sequence/epoch pair is unique, 377 implementations MUST NOT allow the same epoch value to be reused 378 within two times the TCP maximum segment lifetime. In practice, TLS 379 implementations rarely rehandshake and we therefore do not expect 380 this to be a problem. 382 Note that because DTLS records may be reordered, a record from epoch 383 1 may be received after epoch 2 has begun. In general, 384 implementations SHOULD discard packets from earlier epochs, but if 385 packet loss causes noticeable problems MAY choose to retain keying 386 material from previous epochs for up to the default MSL specified for 387 TCP [TCP] to allow for packet reordering. (Note: the intention here 388 is that implementors use the current guidance from the IETF for MSL, 389 not that they attempt to interrogate the MSL the system TCP stack is 390 using.) Until the handshake has completed, implementations MUST 391 accept packets from the old epoch. 393 Conversely, it is possible for records that are protected by the 394 newly negotiated context to be received prior to the completion of a 395 handshake. For instance, the server may send its Finished and then 396 start transmitting data. Implementations MAY either buffer or 397 discard such packets, though when DTLS is used over reliable 398 transports (e.g., SCTP), they SHOULD be buffered and processed once 399 the handshake completes. Note that TLS's restrictions on when 400 packets may be sent still apply, and the receiver treats the packets 401 as if they were sent in the right order. In particular, it is still 402 impermissible to send data prior to completion of the first 403 handshake. 405 Note that in the special case of a rehandshake on an existing 406 association, it is safe to process a data packet immediately even if 407 the ChangeCipherSpec or Finished has not yet been received provided 408 that either the rehandshake resumes the existing session or that it 409 uses exactly the same security parameters as the existing 410 association. In any other case, the implementation MUST wait for the 411 receipt of the Finished to prevent downgrade attack. 413 As in TLS, implementations MUST either abandon an association or 414 rehandshake prior to allowing the sequence number to wrap. Similarly, 415 implementations MUST NOT allow the epoch to wrap, but instead MUST 416 establish a new association, terminating the old association as 417 described in Section 4.2.8. In practice, implementations rarely 418 rehandshake repeatedly on the same channel, so this is not likely to 419 be an issue. 421 4.1.1. Transport Layer Mapping 423 Each DTLS record MUST fit within a single datagram. In order to 424 avoid IP fragmentation, clients of the DTLS record layer SHOULD 425 attempt to size records so that they fit within any PMTU estimates 426 obtained from the record layer. 428 Note that unlike IPsec, DTLS records do not contain any association 429 identifiers. Applications must arrange to multiplex between 430 associations. With UDP, this is presumably done with host/port 431 number. 433 Multiple DTLS records may be placed in a single datagram. They are 434 simply encoded consecutively. The DTLS record framing is sufficient 435 to determine the boundaries. Note, however, that the first byte of 436 the datagram payload must be the beginning of a record. Records may 437 not span datagrams. 439 Some transports, such as DCCP [DCCP] provide their own sequence 440 numbers. When carried over those transports, both the DTLS and the 441 transport sequence numbers will be present. Although this introduces 442 a small amount of inefficiency, the transport layer and DTLS sequence 443 numbers serve different purposes, and therefore for conceptual 444 simplicity it is superior to use both sequence numbers. In the 445 future, extensions to DTLS may be specified that allow the use of 446 only one set of sequence numbers for deployment in constrained 447 environments. 449 Some transports, such as DCCP, provide congestion control for traffic 450 carried over them. If the congestion window is sufficiently narrow, 451 DTLS handshake retransmissions may be held rather than transmitted 452 immediately, potentially leading to timeouts and spurious 453 retransmission. When DTLS is used over such transports, care should 454 be taken not to overrun the likely congestion window. [DCCPDTLS] 455 defines a mapping of DTLS to DCCP that takes these issues into 456 account. 458 4.1.1.1. PMTU Issues 460 In general, DTLS's philosophy is to leave PMTU discovery to the 461 application. However, DTLS cannot completely ignore PMTU for three 462 reasons: 464 - The DTLS record framing expands the datagram size, 465 thus lowering the effective PMTU from the application's 466 perspective. 468 - In some implementations the application may not directly 469 talk to the network, in which case the DTLS stack may 470 absorb ICMP [RFC1191] Datagram Too Big indications 471 or ICMPv6 [RFC1885] Packet Too Big indications. 473 - The DTLS handshake messages can exceed the PMTU. 475 In order to deal with the first two issues, the DTLS record layer 476 SHOULD behave as described below. 478 If PMTU estimates are available from the underlying transport 479 protocol, they should be made available to upper layer protocols. In 480 particular: 482 - For DTLS over UDP, the upper layer protocol SHOULD be allowed 483 to obtain the PMTU estimate maintained in the IP layer. 485 - For DTLS over DCCP, the upper layer protocol 486 SHOULD be allowed to obtain the current estimate of the 487 PMTU. 489 - For DTLS over TCP or SCTP, which automatically fragment 490 and reassemble datagrams, there is no PMTU limitation. 491 However, the upper layer protocol MUST NOT write any 492 record that exceeds the maximum record size of 2^14 bytes. 494 The DTLS record layer SHOULD allow the upper layer protocol to 495 discover the amount of record expansion expected by the DTLS 496 processing. Note that this number is only an estimate because of 497 block padding and the potential use of DTLS compression. 499 If there is a transport protocol indication (either via ICMP or via a 500 refusal to send the datagram as in DCCP Section 14), then the DTLS 501 record layer MUST inform the upper layer protocol of the error. 503 The DTLS record layer SHOULD NOT interfere with upper layer protocols 504 performing PMTU discovery, whether via [RFC1191] or [RFC4821] 505 mechanisms. In particular: 507 - Where allowed by the underlying transport protocol, 508 the upper layer protocol SHOULD be allowed to set 509 the state of the DF bit (in IPv4) or prohibit local 510 fragmentation (in IPv6). 512 - If the underlying transport protocol allows the application 513 to request PMTU probing (e.g., DCCP), the DTLS record 514 layer should honor this request. 516 The final issue is the DTLS handshake protocol. From the perspective 517 of the DTLS record layer, this is merely another upper layer 518 protocol. However, DTLS handshakes occur infrequently and involve 519 only a few round trips, and therefore the handshake protocol PMTU 520 handling places a premium on rapid completion over accurate PMTU 521 discovery. In order to allow connections under these circumstances, 522 DTLS implementations SHOULD follow the following rules: 524 - If the DTLS record layer informs the DTLS handshake layer 525 that a message is too big, it SHOULD immediately attempt 526 to fragment it, using any existing information about the 527 PMTU. 529 - If repeated retransmissions do not result in a response, and the 530 PMTU is unknown, subsequent retransmissions SHOULD back off to a 531 smaller record size, fragmenting the handshake message as 532 appropriate. This standard does not specify an exact number 533 of retransmits to attempt before backing off, but 2-3 seems 534 appropriate. 536 4.1.2. Record Payload Protection 538 Like TLS, DTLS transmits data as a series of protected records. The 539 rest of this section describes the details of that format. 541 4.1.2.1. MAC 543 The DTLS MAC is the same as that of TLS 1.2. However, rather than 544 using TLS's implicit sequence number, the sequence number used to 545 compute the MAC is the 64-bit value formed by concatenating the epoch 546 and the sequence number in the order they appear on the wire. Note 547 that the DTLS epoch + sequence number is the same length as the TLS 548 sequence number. 550 TLS MAC calculation is parameterized on the protocol version number, 551 which, in the case of DTLS, is the on-the-wire version, i.e., {254, 552 253} for DTLS 1.2. 554 Note that one important difference between DTLS and TLS MAC handling 555 is that in TLS MAC errors must result in connection termination. In 556 DTLS, the receiving implementation MAY simply discard the offending 557 record and continue with the connection. This change is possible 558 because DTLS records are not dependent on each other in the way that 559 TLS records are. 561 In general, DTLS implementations SHOULD silently discard records with 562 bad MACs or that are otherwise invalid. They MAY log an error. If a 563 DTLS implementation chooses to generate an alert when it receives a 564 message with an invalid MAC, it MUST generate a bad_record_mac alert 565 with level fatal and terminate its connection state. 567 4.1.2.2. Null or Standard Stream Cipher 569 The DTLS NULL cipher is performed exactly as the TLS 1.2 NULL cipher. 571 The only stream cipher described in TLS 1.2 is RC4, which cannot be 572 randomly accessed. RC4 MUST NOT be used with DTLS. 574 4.1.2.3. Block Cipher 576 DTLS block cipher encryption and decryption are performed exactly as 577 with TLS 1.2. 579 4.1.2.3. AEAD Ciphers 581 TLS 1.2 introduced authenticated encryption with additional data 582 (AEAD) cipher suites. The existing AEAD cipher suites, defined in 583 [ECCGCM] and [RSAGCM] can be used with DTLS exactly as with TLS 1.2. 585 4.1.2.5. New Cipher Suites 587 Upon registration, new TLS cipher suites MUST indicate whether they 588 are suitable for DTLS usage and what, if any, adaptations must be 589 made (See Section 7 for IANA considerations). 591 4.1.2.6. Anti-replay 593 DTLS records contain a sequence number to provide replay protection. 594 Sequence number verification SHOULD be performed using the following 595 sliding window procedure, borrowed from Section 3.4.3 of [ESP]. 597 The receiver packet counter for this session MUST be initialized to 598 zero when the session is established. For each received record, the 599 receiver MUST verify that the record contains a Sequence Number that 600 does not duplicate the Sequence Number of any other record received 601 during the life of this session. This SHOULD be the first check 602 applied to a packet after it has been matched to a session, to speed 603 rejection of duplicate records. 605 Duplicates are rejected through the use of a sliding receive window. 606 (How the window is implemented is a local matter, but the following 607 text describes the functionality that the implementation must 608 exhibit.) A minimum window size of 32 MUST be supported, but a 609 window size of 64 is preferred and SHOULD be employed as the default. 610 Another window size (larger than the minimum) MAY be chosen by the 611 receiver. (The receiver does not notify the sender of the window 612 size.) 614 The "right" edge of the window represents the highest validated 615 Sequence Number value received on this session. Records that contain 616 Sequence Numbers lower than the "left" edge of the window are 617 rejected. Packets falling within the window are checked against a 618 list of received packets within the window. An efficient means for 619 performing this check, based on the use of a bit mask, is described 620 in Section 3.4.3 of [ESP]. 622 If the received record falls within the window and is new, or if the 623 packet is to the right of the window, then the receiver proceeds to 624 MAC verification. If the MAC validation fails, the receiver MUST 625 discard the received record as invalid. The receive window is 626 updated only if the MAC verification succeeds. 628 4.1.2.7. Handling Invalid Records 630 Unlike TLS, DTLS is resilient in the face of invalid records (e.g., 631 invalid formatting, length, MAC, etc.) In general, invalid records 632 SHOULD be silently discarded, thus preserving the association, 633 however an error MAY be logged for diagnostic purposes. 634 Implementations which choose to generate an alert instead, MUST 635 generate fatal level alerts to avoid attacks where the attacker 636 repeatedly probes the implementation to see how it responds to 637 various types of error. Note that if DTLS is run over UDP, then any 638 implementation which does this will be extremely susceptible to DoS 639 attacks because UDP forgery is so easy. Thus, this practice is NOT 640 RECOMMENDED for such transports. 642 If DTLS is being carried over a transport which is resistant to 643 forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts 644 because an attacker will have difficulty forging a datagram which 645 will not be rejected by the transport layer. 647 4.2. The DTLS Handshake Protocol 649 DTLS uses all of the same handshake messages and flows as TLS, with 650 three principal changes: 652 1. A stateless cookie exchange has been added to prevent denial of 653 service attacks. 655 2. Modifications to the handshake header to handle message loss, 656 reordering, and DTLS message fragmentation (in order to avoid IP 657 fragmentation). 659 3. Retransmission timers to handle message loss. 661 With these exceptions, the DTLS message formats, flows, and logic are 662 the same as those of TLS 1.2. 664 4.2.1. Denial of Service Countermeasures 666 Datagram security protocols are extremely susceptible to a variety of 667 denial of service (DoS) attacks. Two attacks are of particular 668 concern: 670 1. An attacker can consume excessive resources on the server by 671 transmitting a series of handshake initiation requests, causing 672 the server to allocate state and potentially to perform expensive 673 cryptographic operations. 675 2. An attacker can use the server as an amplifier by sending 676 connection initiation messages with a forged source of the victim. 677 The server then sends its next message (in DTLS, a Certificate 678 message, which can be quite large) to the victim machine, thus 679 flooding it. 681 In order to counter both of these attacks, DTLS borrows the stateless 682 cookie technique used by Photuris [PHOTURIS] and IKE [IKEv2]. When 683 the client sends its ClientHello message to the server, the server 684 MAY respond with a HelloVerifyRequest message. This message contains 685 a stateless cookie generated using the technique of [PHOTURIS]. The 686 client MUST retransmit the ClientHello with the cookie added. The 687 server then verifies the cookie and proceeds with the handshake only 688 if it is valid. This mechanism forces the attacker/client to be able 689 to receive the cookie, which makes DoS attacks with spoofed IP 690 addresses difficult. This mechanism does not provide any defense 691 against DoS attacks mounted from valid IP addresses. 693 The exchange is shown below: 695 Client Server 696 ------ ------ 697 ClientHello ------> 699 <----- HelloVerifyRequest 700 (contains cookie) 702 ClientHello ------> 703 (with cookie) 705 [Rest of handshake] 707 DTLS therefore modifies the ClientHello message to add the cookie 708 value. 710 struct { 711 ProtocolVersion client_version; 712 Random random; 713 SessionID session_id; 714 opaque cookie<0..2^8-1>; // New field 715 CipherSuite cipher_suites<2..2^16-1>; 716 CompressionMethod compression_methods<1..2^8-1>; 717 } ClientHello; 719 When sending the first ClientHello, the client does not have a cookie 720 yet; in this case, the Cookie field is left empty (zero length). 722 The definition of HelloVerifyRequest is as follows: 724 struct { 725 ProtocolVersion server_version; 726 opaque cookie<0..2^8-1>; 727 } HelloVerifyRequest; 729 The HelloVerifyRequest message type is hello_verify_request(3). 731 The server_version field has the same syntax as in TLS. However, in 732 order to avoid the requirement to do version negotiation in the 733 initial handshake, DTLS 1.2 serverimplementations SHOULD use DTLS 734 version 1.0 regardless of the version of TLS which is expected to be 735 negotiated. DTLS 1.2 and 1.0 clients MUST use the version solely to 736 indicate packet formatting (which is the same in both DTLS 1.2 and 737 1.0) and not as part of version negotiation. In particular, DTLS 1.2 738 clients MUST NOT assume that because the server uses version 1.0 in 739 the HelloVerifyRequest that the server is not DTLS 1.2 or that it 740 will eventually negotiate DTLS 1.0 rather than DTLS 1.2. 742 When responding to a HelloVerifyRequest the client MUST use the same 743 parameter values (version, random, session_id, cipher_suites, 744 compression_method) as it did in the original ClientHello. The 745 server SHOULD use those values to generate its cookie and verify that 746 they are correct upon cookie receipt. The server MUST use the same 747 version number in the HelloVerifyRequest that it would use when 748 sending a ServerHello. Upon receipt of the ServerHello, the client 749 MUST verify that the server version values match. In order to avoid 750 sequence number duplication in case of multiple HelloVerifyRequests, 751 the server MUST use the record sequence number in the ClientHello as 752 the record sequence number in the HelloVerifyRequest. 754 Note: this specification increases the cookie size limit to 255 bytes 755 for greater future flexibility. The limit remains 32 for previous 756 versions of DTLS. 758 The DTLS server SHOULD generate cookies in such a way that they can 759 be verified without retaining any per-client state on the server. 760 One technique is to have a randomly generated secret and generate 761 cookies as: Cookie = HMAC(Secret, Client-IP, Client-Parameters) 763 When the second ClientHello is received, the server can verify that 764 the Cookie is valid and that the client can receive packets at the 765 given IP address. In order to avoid sequence number duplication in 766 case of multiple cookie exchanges, the server MUST use the record 767 sequence number in the ClientHello as the record sequence number in 768 its initial ServerHello. Subsequent ServerHellos will only be sent 769 after the server has created state and MUST increment normally. 771 One potential attack on this scheme is for the attacker to collect a 772 number of cookies from different addresses and then reuse them to 773 attack the server. The server can defend against this attack by 774 changing the Secret value frequently, thus invalidating those 775 cookies. If the server wishes that legitimate clients be able to 776 handshake through the transition (e.g., they received a cookie with 777 Secret 1 and then sent the second ClientHello after the server has 778 changed to Secret 2), the server can have a limited window during 779 which it accepts both secrets. [IKEv2] suggests adding a version 780 number to cookies to detect this case. An alternative approach is 781 simply to try verifying with both secrets. 783 DTLS servers SHOULD perform a cookie exchange whenever a new 784 handshake is being performed. If the server is being operated in an 785 environment where amplification is not a problem, the server MAY be 786 configured not to perform a cookie exchange. The default SHOULD be 787 that the exchange is performed, however. In addition, the server MAY 788 choose not to do a cookie exchange when a session is resumed. 789 Clients MUST be prepared to do a cookie exchange with every 790 handshake. 792 If HelloVerifyRequest is used, the initial ClientHello and 793 HelloVerifyRequest are not included in the calculation of the 794 handshake_messages (for the CertificateVerify message) and 795 verify_data (for the Finished message). 797 If a server receives a ClientHello with an invalid cookie, it SHOULD 798 treat it the same as a ClientHello with no cookie. This avoids 799 race/deadlock conditions if the client somehow gets a bad cookie 800 (e.g., because the server changes its cookie signing key). 802 Note to implementors: this may results in clients receiving multiple 803 HelloVerifyRequest messages with different cookies. Clients SHOULD 804 handle this by sending a new ClientHello with a cookie in response to 805 the new HelloVerifyRequest. 807 4.2.2. Handshake Message Format 809 In order to support message loss, reordering, and message 810 fragmentation, DTLS modifies the TLS 1.2 handshake header: 812 struct { 813 HandshakeType msg_type; 814 uint24 length; 815 uint16 message_seq; // New field 816 uint24 fragment_offset; // New field 817 uint24 fragment_length; // New field 818 select (HandshakeType) { 819 case hello_request: HelloRequest; 820 case client_hello: ClientHello; 821 case hello_verify_request: HelloVerifyRequest; // New type 822 case server_hello: ServerHello; 823 case certificate:Certificate; 824 case server_key_exchange: ServerKeyExchange; 825 case certificate_request: CertificateRequest; 826 case server_hello_done:ServerHelloDone; 827 case certificate_verify: CertificateVerify; 828 case client_key_exchange: ClientKeyExchange; 829 case finished: Finished; 830 } body; 831 } Handshake; 833 The first message each side transmits in each handshake always has 834 message_seq = 0. Whenever each new message is generated, the 835 message_seq value is incremented by one. Note that in the case of a 836 rehandshake, this implies that the HelloRequest will have message_seq 837 = 0 and the ServerHello will have message_seq = 1. When a message is 838 retransmitted, the same message_seq value is used. For example: 840 Client Server 841 ------ ------ 842 ClientHello (seq=0) ------> 844 X<-- HelloVerifyRequest (seq=0) 845 (lost) 847 [Timer Expires] 849 ClientHello (seq=0) ------> 850 (retransmit) 852 <------ HelloVerifyRequest (seq=0) 854 ClientHello (seq=1) ------> 855 (with cookie) 857 <------ ServerHello (seq=1) 858 <------ Certificate (seq=2) 859 <------ ServerHelloDone (seq=3) 861 [Rest of handshake] 863 Note, however, that from the perspective of the DTLS record layer, 864 the retransmission is a new record. This record will have a new 865 DTLSPlaintext.sequence_number value. 867 DTLS implementations maintain (at least notionally) a 868 next_receive_seq counter. This counter is initially set to zero. 869 When a message is received, if its sequence number matches 870 next_receive_seq, next_receive_seq is incremented and the message is 871 processed. If the sequence number is less than next_receive_seq, the 872 message MUST be discarded. If the sequence number is greater than 873 next_receive_seq, the implementation SHOULD queue the message but MAY 874 discard it. (This is a simple space/bandwidth tradeoff). 876 4.2.3. Handshake Message Fragmentation and Reassembly 878 As noted in Section 4.1.1, each DTLS message MUST fit within a single 879 transport layer datagram. However, handshake messages are 880 potentially bigger than the maximum record size. Therefore, DTLS 881 provides a mechanism for fragmenting a handshake message over a 882 number of records, each of which can be transmitted separately, thus 883 avoiding IP fragmentation. 885 When transmitting the handshake message, the sender divides the 886 message into a series of N contiguous data ranges. These ranges MUST 887 NOT be larger than the maximum handshake fragment size and MUST 888 jointly contain the entire handshake message. The ranges SHOULD NOT 889 overlap. The sender then creates N handshake messages, all with the 890 same message_seq value as the original handshake message. Each new 891 message is labelled with the fragment_offset (the number of bytes 892 contained in previous fragments) and the fragment_length (the length 893 of this fragment). The length field in all messages is the same as 894 the length field of the original message. An unfragmented message is 895 a degenerate case with fragment_offset=0 and fragment_length=length. 897 When a DTLS implementation receives a handshake message fragment, it 898 MUST buffer it until it has the entire handshake message. DTLS 899 implementations MUST be able to handle overlapping fragment ranges. 900 This allows senders to retransmit handshake messages with smaller 901 fragment sizes if the PMTU estimate changes. 903 Note that as with TLS, multiple handshake messages may be placed in 904 the same DTLS record, provided that there is room and that they are 905 part of the same flight. Thus, there are two acceptable ways to pack 906 two DTLS messages into the same datagram: in the same record or in 907 separate records. 909 4.2.4. Timeout and Retransmission 910 DTLS messages are grouped into a series of message flights, according 911 to the diagrams below. Although each flight of messages may consist 912 of a number of messages, they should be viewed as monolithic for the 913 purpose of timeout and retransmission. 915 Client Server 916 ------ ------ 918 ClientHello --------> Flight 1 920 <------- HelloVerifyRequest Flight 2 922 ClientHello --------> Flight 3 924 ServerHello \ 925 Certificate* \ 926 ServerKeyExchange* Flight 4 927 CertificateRequest* / 928 <-------- ServerHelloDone / 930 Certificate* \ 931 ClientKeyExchange \ 932 CertificateVerify* Flight 5 933 [ChangeCipherSpec] / 934 Finished --------> / 936 [ChangeCipherSpec] \ Flight 6 937 <-------- Finished / 939 Figure 1. Message flights for full handshake 941 Client Server 942 ------ ------ 944 ClientHello --------> Flight 1 946 ServerHello \ 947 [ChangeCipherSpec] Flight 2 948 <-------- Finished / 950 [ChangeCipherSpec] \Flight 3 951 Finished --------> / 953 Figure 2. Message flights for session-resuming handshake 954 (no cookie exchange) 956 DTLS uses a simple timeout and retransmission scheme with the 957 following state machine. Because DTLS clients send the first message 958 (ClientHello), they start in the PREPARING state. DTLS servers start 959 in the WAITING state, but with empty buffers and no retransmit timer. 961 +-----------+ 962 | PREPARING | 963 +---> | | <--------------------+ 964 | | | | 965 | +-----------+ | 966 | | | 967 | | | 968 | | Buffer next flight | 969 | | | 970 | \|/ | 971 | +-----------+ | 972 | | | | 973 | | SENDING |<------------------+ | 974 | | | | | Send 975 | +-----------+ | | HelloRequest 976 Receive | | | | 977 next | | Send flight | | or 978 flight | +--------+ | | 979 | | | Set retransmit timer | | Receive 980 | | \|/ | | HelloRequest 981 | | +-----------+ | | Send 982 | | | | | | ClientHello 983 +--)--| WAITING |-------------------+ | 984 | | | | Timer expires | | 985 | | +-----------+ | | 986 | | | | | 987 | | | | | 988 | | +------------------------+ | 989 | | Read retransmit | 990 Receive | | | 991 last | | | 992 flight | | | 993 | | | 994 \|/\|/ | 995 | 996 +-----------+ | 997 | | | 998 | FINISHED | -------------------------------+ 999 | | 1000 +-----------+ 1001 | /|\ 1002 | | 1003 | | 1004 +---+ 1006 Read retransmit 1007 Retransmit last flight 1008 Figure 3. DTLS timeout and retransmission state machine 1010 The state machine has three basic states. 1012 In the PREPARING state the implementation does whatever computations 1013 are necessary to prepare the next flight of messages. It then 1014 buffers them up for transmission (emptying the buffer first) and 1015 enters the SENDING state. 1017 In the SENDING state, the implementation transmits the buffered 1018 flight of messages. Once the messages have been sent, the 1019 implementation then enters the FINISHED state if this is the last 1020 flight in the handshake. Or, if the implementation expects to 1021 receive more messages, it sets a retransmit timer and then enters the 1022 WAITING state. 1024 There are three ways to exit the WAITING state: 1026 1. The retransmit timer expires: the implementation transitions to 1027 the SENDING state, where it retransmits the flight, resets the 1028 retransmit timer, and returns to the WAITING state. 1030 2. The implementation reads a retransmitted flight from the peer: 1031 the implementation transitions to the SENDING state, where it 1032 retransmits the flight, resets the retransmit timer, and returns 1033 to the WAITING state. The rationale here is that the receipt of a 1034 duplicate message is the likely result of timer expiry on the peer 1035 and therefore suggests that part of one's previous flight was 1036 lost. 1038 3. The implementation receives the next flight of messages: if 1039 this is the final flight of messages, the implementation 1040 transitions to FINISHED. If the implementation needs to send a 1041 new flight, it transitions to the PREPARING state. Partial reads 1042 (whether partial messages or only some of the messages in the 1043 flight) do not cause state transitions or timer resets. 1045 Because DTLS clients send the first message (ClientHello), they start 1046 in the PREPARING state. DTLS servers start in the WAITING state, but 1047 with empty buffers and no retransmit timer. 1049 When the server desires a rehandshake, it transitions from the 1050 FINISHED state to the PREPARING state to transmit the HelloRequest. 1051 When the client receives a HelloRequest it transitions from FINISHED 1052 to PREPARING to transmit the ClientHello. 1054 In addition, for at least twice the default MSL defined for [TCP], 1055 when in the FINISHED state, the node which transmits the last flight 1056 (the server in an ordinary handshake or the client in a resumed 1057 handshake) MUST respond to a retransmit of the peer's last flight 1058 with a retransmit of the last flight. This avoids deadlock conditions 1059 if the last flight gets lost. This requirement applies to DTLS 1.0 as 1060 well, and though not explicit in [DTLS1] but was always required for 1061 the state machine to function correctly. To see why this is 1062 necessary, consider what happens in an ordinary handshake if the 1063 server's Finished is lost: the server believes the handshake is 1064 complete but it actually is not. As the client is waiting for the 1065 Finished, the client's retransmit timer will fire and it will 1066 retransmit the client Finished, causing the server to respond with 1067 its own Finished, completing the handshake. The same logic applies 1068 on the server side for the resumed handshake. 1070 Note that because of packet loss it is possible for one side to be 1071 sending application data even though the other side has not received 1072 the first side's Finished. Implementations MUST either discard or 1073 buffer all application data packets for the new epoch until they have 1074 received the Finished for that epoch. Implementations MAY treat 1075 receipt of application data with a new epoch prior to receipt of the 1076 corresponding Finished as evidence of reordering or packet loss and 1077 retransmit their final flight immediately, shortcutting the 1078 retransmission timer. 1080 4.2.4.1. Timer Values 1082 Though timer values are the choice of the implementation, mishandling 1083 of the timer can lead to serious congestion problems; for example, if 1084 many instances of a DTLS time out early and retransmit too quickly on 1085 a congested link. Implementations SHOULD use an initial timer value 1086 of 1 second (the minimum defined in RFC 2988 [RFC2988]) and double 1087 the value at each retransmission, up to no less than the RFC 2988 1088 maximum of 60 seconds. Note that we recommend a 1-second timer 1089 rather than the 3-second RFC 2988 default in order to improve latency 1090 for time-sensitive applications. Because DTLS only uses 1091 retransmission for handshake and not dataflow, the effect on 1092 congestion should be minimal. 1094 Implementations SHOULD retain the current timer value until a 1095 transmission without loss occurs, at which time the value may be 1096 reset to the initial value. After a long period of idleness, no less 1097 than 10 times the current timer value, implementations may reset the 1098 timer to the initial value. One situation where this might occur is 1099 when a rehandshake is used after substantial data transfer. 1101 4.2.5. ChangeCipherSpec 1103 As with TLS, the ChangeCipherSpec message is not technically a 1104 handshake message but MUST be treated as part of the same flight as 1105 the associated Finished message for the purposes of timeout and 1106 retransmission. This creates a potential ambiguity because the order 1107 of the ChangeCipherSpec cannot be established unambiguously with 1108 respect to the handshake messages in case of message loss. 1110 This is not a problem with any current TLS mode because the expected 1111 set of handshake messages which occur the ChangeCipherSpec is 1112 predictable from the rest of the handshake state. However, future 1113 modes MUST take care to avoid creating ambiguity. 1115 4.2.6. CertificateVerify and Finished Messages 1117 CertificateVerify and Finished messages have the same format as in 1118 TLS. Hash calculations include entire handshake messages, including 1119 DTLS specific fields: message_seq, fragment_offset and 1120 fragment_length. However, in order to remove sensitivity to 1121 handshake message fragmentation, the Finished MAC MUST be computed as 1122 if each handshake message had been sent as a single fragment. Note 1123 that in cases where the cookie exchange is used, the initial 1124 ClientHello and HelloVerifyRequest MUST NOT be included in the 1125 CertificateVerify or Finished MAC computations. 1127 4.2.7. Alert Messages 1129 Note that Alert messages are not retransmitted at all, even when they 1130 occur in the context of a handshake. However, a DTLS implementation 1131 SHOULD generate a new alert message if the offending record is 1132 received again (e.g., as a retransmitted handshake message). 1133 Implementations SHOULD detect when a peer is persistently sending bad 1134 messages and terminate the local connection state after such 1135 misbehavior is detected. 1137 4.2.8. Establishing New Associations With Existing Parameters 1139 If a DTLS client-server pair are configured in such a way that 1140 repeated connections happen on the same host/port quartet, then it is 1141 possible that a client will silently abandon one connection and then 1142 initiate another with the same parameters (e.g., after a reboot). 1143 This will appear to the server as a new handshake with epoch=0. In 1144 cases where a server believes it has an existing association on a 1145 given host/port quartet and it receives an epoch=0 ClientHello, it 1146 SHOULD proceed with a new handshake but MUST NOT destroy the existing 1147 association until the client has demonstrated reachability either by 1148 completing a cookie exchange or by completing a complete handshake 1149 including delivering a verifiable Finished message. After a correct 1150 Finished is received, the server MUST abandon the previous 1151 association to avoid confusion between two valid associations with 1152 overlapping epochs. The reachability requirement prevents off- 1153 path/blind attackers from destroying associations merely by sending 1154 forged ClientHellos. 1156 4.3. Summary of new syntax 1158 This section includes specifications for the data structures that 1159 have changed between TLS 1.2 and DTLS 1.2. See [TLS12] for the 1160 definition of this syntax. 1162 4.3.1. Record Layer 1164 struct { 1165 ContentType type; 1166 ProtocolVersion version; 1167 uint16 epoch; // New field 1168 uint48 sequence_number; // New field 1169 uint16 length; 1170 opaque fragment[DTLSPlaintext.length]; 1171 } DTLSPlaintext; 1173 struct { 1174 ContentType type; 1175 ProtocolVersion version; 1176 uint16 epoch; // New field 1177 uint48 sequence_number; // New field 1178 uint16 length; 1179 opaque fragment[DTLSCompressed.length]; 1180 } DTLSCompressed; 1182 struct { 1183 ContentType type; 1184 ProtocolVersion version; 1185 uint16 epoch; // New field 1186 uint48 sequence_number; // New field 1187 uint16 length; 1188 select (CipherSpec.cipher_type) { 1189 case block: GenericBlockCipher; 1190 case aead: GenericAEADCipher; // New field 1191 } fragment; 1192 } DTLSCiphertext; 1194 4.3.2. Handshake Protocol 1196 enum { 1197 hello_request(0), client_hello(1), server_hello(2), 1198 hello_verify_request(3), // New field 1199 certificate(11), server_key_exchange (12), 1200 certificate_request(13), server_hello_done(14), 1201 certificate_verify(15), client_key_exchange(16), 1202 finished(20), (255) 1203 } HandshakeType; 1205 struct { 1206 HandshakeType msg_type; 1207 uint24 length; 1208 uint16 message_seq; // New field 1209 uint24 fragment_offset; // New field 1210 uint24 fragment_length; // New field 1211 select (HandshakeType) { 1212 case hello_request: HelloRequest; 1213 case client_hello: ClientHello; 1214 case server_hello: ServerHello; 1215 case hello_verify_request: HelloVerifyRequest; // New field 1216 case certificate:Certificate; 1217 case server_key_exchange: ServerKeyExchange; 1218 case certificate_request: CertificateRequest; 1219 case server_hello_done:ServerHelloDone; 1220 case certificate_verify: CertificateVerify; 1221 case client_key_exchange: ClientKeyExchange; 1222 case finished: Finished; 1223 } body; 1224 } Handshake; 1226 struct { 1227 ProtocolVersion client_version; 1228 Random random; 1229 SessionID session_id; 1230 opaque cookie<0..2^8-1>; // New field 1231 CipherSuite cipher_suites<2..2^16-1>; 1232 CompressionMethod compression_methods<1..2^8-1>; 1233 } ClientHello; 1235 struct { 1236 ProtocolVersion server_version; 1237 opaque cookie<0..2^8-1>; 1238 } HelloVerifyRequest; 1240 5. Security Considerations 1242 This document describes a variant of TLS 1.2 and therefore most of 1243 the security considerations are the same as those of TLS 1.2 [TLS12], 1244 described in Appendices D, E, and F. 1246 The primary additional security consideration raised by DTLS is that 1247 of denial of service. DTLS includes a cookie exchange designed to 1248 protect against denial of service. However, implementations which do 1249 not use this cookie exchange are still vulnerable to DoS. In 1250 particular, DTLS servers which do not use the cookie exchange may be 1251 used as attack amplifiers even if they themselves are not 1252 experiencing DoS. Therefore, DTLS servers SHOULD use the cookie 1253 exchange unless there is good reason to believe that amplification is 1254 not a threat in their environment. Clients MUST be prepared to do a 1255 cookie exchange with every handshake. 1257 Unlike TLS implementations DTLS implementations SHOULD NOT respond to 1258 invalid records by terminating the connection. See Section 4.1.2.7 1259 for details on this. 1261 6. Acknowledgements 1263 The authors would like to thank Dan Boneh, Eu-Jin Goh, Russ Housley, 1264 Constantine Sapuntzakis, and Hovav Shacham for discussions and 1265 comments on the design of DTLS. Thanks to the anonymous NDSS 1266 reviewers of our original NDSS paper on DTLS [DTLS] for their 1267 comments. Also, thanks to Steve Kent for feedback that helped 1268 clarify many points. The section on PMTU was cribbed from the DCCP 1269 specification [DCCP]. Pasi Eronen provided a detailed review of this 1270 specification. Peter Saint-Andre provided the changes list in Section 1271 8. elpful comments on the document were also received from Mark 1272 Allman, Jari Arkko, Mohamed Badra, Michael D'Errico, Adrian Farrell, 1273 Joel Halpern, Ted Hardie, Charlia Kaufman, Pekka Savola, Allison 1274 Mankin, Nikos Mavrogiannopoulos, Alexey Melnikov, Robin Seggelman, 1275 Michael Tuexen, Juho Vaha-Herttua, and Florian Weimer. 1277 7. IANA Considerations 1279 This document uses the same identifier space as TLS [TLS12], so no 1280 new IANA registries are required. When new identifiers are assigned 1281 for TLS, authors MUST specify whether they are suitable for DTLS. 1282 IANA [should modify/has modified] all TLS parameter registries to add 1283 a DTLS-OK flag, indicating whether the specification may be used with 1284 DTLS. 1286 This document defines a new handshake message, hello_verify_request, 1287 whose value has been allocated from the TLS HandshakeType registry 1288 defined in [TLS12]. The value "3" has been assigned by the IANA. 1290 8. Changes Since DTLS 1.0 1292 This document reflects the following changes since DTLS 1.0 [DTLS1]. 1294 - Updated to match TLS 1.2 [TLS12]. 1296 - Addition of AEAD Ciphers in Section 4.1.2.3 (tracking changes in 1297 TLS 1.2. 1299 - Clarifications regarding sequence numbers and epochs in Section 4.1 1300 and a clear procedure for dealing with state loss in Section 4.2.8. 1302 - Clarifications and more detailed rules regarding Path MTU issues in 1303 Section 4.1.1.1. Clarification of the fragmentation text throughout. 1305 - Clarifications regarding handling of invalid records in Section 4.1.2.7. 1307 - A new paragraph describing handling of invalid cookies at the end of 1308 Section 4.2.1. 1310 - Some new text describing how to avoid handshake deadlock conditions 1311 at the end of Section 4.2.4. 1313 - Some new text about CertificateVerify messages in Section 4.2.6. 1315 - A prohibition on epoch wrapping in Section 4.1. 1317 - Clarification of the IANA requirements and the explicit requirement 1318 for a new IANA registration flag for each parameter. 1320 - Added a record sequence number mirroring technique for handling 1321 repeated ClientHello messages. 1323 - Recommend a fixed version number for HelloVerifyRequest. 1325 - Numerous editorial changes. 1327 9. References 1329 9.1. Normative References 1331 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1332 November 1990. 1334 [RFC1885] Conta, A., and S. Deering, "Internet Control Message 1335 Protocol (ICMPv6) for the Internet Protocol Version 6 1336 (IPv6) Specification", RFC 1885, December 1995. 1338 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1339 Internet Protocol", RFC 4301, December 2005. 1341 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 1342 Timer", RFC 2988, November 2000. 1344 [RFC4821] Mathis, M., and J. Heffner, "Packetization Layer Path MTU 1345 Discovery", RFC 4821, March 2007. 1347 [RSAGCM] Salowey, J., Choudhury, A., and D. McGrew, "AES-GCM Cipher 1348 Suites for TLS", RFC 5288, August 2008. 1350 [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 1351 793, September 1981. 1353 [TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security 1354 (TLS) Protocol Version 1.2", RFC 5246, May 2008. 1356 9.2. Informative References 1358 [DCCP] Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram 1359 Congestion Control Protocol", Work in Progress, 10 March 1360 2005. 1362 [DCCPDTLS] T. Phelan, "Datagram Transport Layer Security (DTLS) over 1363 the Datagram Congestion Control Protocol (DCCP)", RFC 1364 5238, May 2008. 1366 [DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation 1367 of Datagram TLS", Proceedings of ISOC NDSS 2004, February 1368 2004. 1370 [DTLS1] Rescorla, E., and N. Modadugu, "Datagram Transport Layer 1371 Security", RFC 4347, April 2006. 1373 [ECCGCM] E. Rescorla, "TLS Elliptic Curve Cipher Suites with 1374 SHA-256/384 and AES Galois Counter Mode", RFC 5289, August 1375 2008. 1377 [ESP] S. Kent "IP Encapsulating Security Payload (ESP)", RFC 1378 4303, December 2005. 1380 [IKEv2] C. Kaufman (ed), "Internet Key Exchange (IKEv2) Protocol", 1381 RFC 4306, December 2005. 1383 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1384 4rev1", RFC 3501, March 2003. 1386 [PHOTURIS] Karn, P. and W. Simpson, "Photuris: Session-Key Management 1387 Protocol", RFC 2522, March 1999. 1389 [POP] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1390 STD 53, RFC 1939, May 1996. 1392 [REQ] Bradner, S., "Key words for use in RFCs to Indicate 1393 Requirement Levels", BCP 14, RFC 2119, March 1997. 1395 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1396 A., Peterson, J., Sparks, R., Handley, M., and E. 1397 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1398 June 2002. 1400 [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1401 RFC 2246, January 1999. 1403 [TLS11] Dierks, T. and E. Rescorla, "The Transport Layer Security 1404 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1406 [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", 1407 RFC 5406, October 2003. 1409 Authors' Addresses 1411 Eric Rescorla 1412 RTFM, Inc. 1413 2064 Edgewood Drive 1414 Palo Alto, CA 94303 1416 EMail: ekr@rtfm.com 1418 Nagendra Modadugu 1419 Computer Science Department 1420 Stanford University 1421 353 Serra Mall 1422 Stanford, CA 94305 1424 EMail: nagendra@cs.stanford.edu