idnits 2.17.00 (12 Aug 2021) /tmp/idnits20605/draft-rescorla-dtls-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1096. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1070. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1077. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1083. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'MOGUL' is mentioned on line 333, but not defined == Missing Reference: 'RFC 2402' is mentioned on line 431, but not defined ** Obsolete undefined reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) == Missing Reference: 'RFC 2401' is mentioned on line 458, but not defined ** Obsolete undefined reference: RFC 2401 (Obsoleted by RFC 4301) == Missing Reference: 'ChangeCipherSpec' is mentioned on line 737, but not defined == Unused Reference: 'AH' is defined on line 992, but no explicit reference was found in the text == Unused Reference: 'DNS' is defined on line 999, but no explicit reference was found in the text == Unused Reference: 'DTLS' is defined on line 1056, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) == Outdated reference: draft-ietf-tls-rfc2246-bis has been published as RFC 4346 ** Downref: Normative reference to an Historic draft: draft-ietf-tls-rfc2246-bis (ref. 'TLS11') -- Obsolete informational reference (is this intentional?): RFC 2402 (ref. 'AH') (Obsoleted by RFC 4302, RFC 4305) == Outdated reference: draft-ietf-dccp-spec has been published as RFC 4340 -- Obsolete informational reference (is this intentional?): RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) == Outdated reference: draft-ietf-ipsec-ikev2 has been published as RFC 4306 -- 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) == Outdated reference: draft-bellovin-useipsec has been published as RFC 5406 Summary: 9 errors (**), 0 flaws (~~), 14 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 E. Rescorla 2 RTFM, Inc. 3 N. Modadugu 4 INTERNET-DRAFT Stanford University 5 April 2004 (Expires October 2005) 7 Datagram Transport Layer Security 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Copyright Notice 34 Copyright (C) The Internet Society (1999-2004). All Rights Reserved. 36 Abstract 38 This document specifies Version 1.0 of the Datagram Transport 39 Layer Security (DTLS) protocol. The DTLS protocol provides 40 communications privacy for datagram protocols. The protocol 41 allows client/server applications to communicate in a way that 42 is designed to prevent eavesdropping, tampering, or message 43 forgery. The DTLS protocol is based on the TLS protocol and 44 provides equivalent security guarantees. Datagram semantics of 45 the underlying transport are preserved by the DTLS protocol. 47 Contents 49 1 Introduction 3 50 1.1 Requirements Terminology 3 51 2 Usage Model 4 52 3 Overview of DTLS 4 53 3.1 Loss-insensitive messaging 4 54 3.2 Providing Reliability for Handshake 5 55 3.2.1 Packet Loss 5 56 3.2.2 Reordering 6 57 3.2.3 Message Size 6 58 3.3 Replay Detection 6 59 4 Differences from TLS 6 60 4.1 Record Layer 7 61 4.1.1 Transport Layer Mapping 8 62 4.1.1.1 PMTU Discovery 8 63 4.1.2 Record payload protection 9 64 4.1.2.1 MAC 9 65 4.1.2.2 Null or standard stream cipher 9 66 4.1.2.3 Block Cipher 10 67 4.1.2.4 New Cipher Suites 10 68 4.1.2.5 Anti-Replay 10 69 4.2 The DTLS Handshake Protocol 11 70 4.2.1 Denial of Service Countermeasures 11 71 4.2.2 Handshake Message Format 13 72 4.2.3 Message Fragmentation and Reassembly 15 73 4.2.4 Timeout and Retransmission 16 74 4.2.4.1 Timer Values 19 75 4.2.5 ChangeCipherSpec 20 76 4.2.6 Finished messages 20 77 4.2.7 Alert Messages 20 78 4.2 Record Layer 20 79 4.3 Handshake Protocol 21 80 5 Security Considerations 22 81 6 IANA Considerations 22 82 1. Introduction 84 TLS [TLS] is the most widely deployed protocol for securing 85 network traffic. It is widely used for protecting Web traffic 86 and for e-mail protocols such as IMAP [IMAP] and POP [POP]. 87 The primary advantage of TLS is that it provides a transparent 88 connection-oriented channel. Thus, it is easy to secure an 89 application protocol by inserting TLS between the application 90 layer and the transport layer. However, TLS must run over a 91 reliable transport channel--typically TCP [TCP]. It therefore 92 cannot be used to secure unreliable datagram traffic. 94 However, over the past few years an increasing number of 95 application layer protocols have been designed which UDP 96 transport. In particular such protocols as the Session 97 Initiation Protocol (SIP) [SIP], and electronic gaming 98 protocols are increasingly popular. (Note that SIP can run 99 over both TCP and UDP, but that there are situations in which 100 UDP is preferable). Currently, designers of these applications 101 are faced with a number of unsatisfactory choices. First, they 102 can use IPsec [RFC2401]. However, for a number of reasons 103 detailed in [WHYIPSEC], this is only suitable for some 104 applications. Second, they can design a custom application 105 layer security protocol. SIP, for instance, uses a subsert of 106 S/MIME to secure its traffic. Unfortunately, while application 107 layer security protocols generally provide superior security 108 properties (e.g., end-to-end security in the case of S/MIME) 109 it typically require a large amount of effort to design--by 110 contrast to the relatively small amount of effort required to 111 run the protocol over TLS. 113 In many cases, the most desirable way to secure client/server 114 applications would be to use TLS; however the requirement for 115 datagram semantics automatically prohibits use of TLS. Thus, a 116 datagram-compatible variant of TLS would be very desirable. 117 This memo describes such a protocol: Datagram Transport Layer 118 Security (DTLS). DTLS is deliberately designed to be as 119 similar to to TLS as possible, both to minimize new security 120 invention and to maximize the amount of code and 121 infrastructure reuse. 123 1.1. Requirements Terminology 125 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 126 NOT" and "MAY" that appear in this document are to be 127 interpreted as described in RFC 2119 [REQ]. 129 2. Usage Model 131 The DTLS protocol is designed to secure data between 132 communicating applications. It is designed to run in 133 application space, without requiring any kernel modifications. 135 Datagram transport does not require or provide reliable or in- 136 order delivery of data. The DTLS protocol preserves this 137 property for payload data. Applications such as media 138 streaming, Internet telephony and online gaming use datagram 139 transport for communication due to the delay-sensitive nature 140 of transported data. The behavior of such applications is 141 unchanged when the DTLS protocol is used to secure 142 communication, since the DTLS protocol does not compensate for 143 lost or re-ordered data traffic. 145 3. Overview of DTLS 147 The basic design philosophy of DTLS is to construct "TLS over 148 datagram". The reason that TLS cannot be used directly in 149 datagram environments is simply that packets may be lost or 150 reordered. TLS has no internal facilities to handle this kind 151 of unreliability and therefore TLS implementations break when 152 rehosted on datagram transport. The purpose of DTLS is to make 153 only the minimal changes to TLS required to fix this problem. 154 To the greatest extent possible, DTLS is identical to TLS. 155 Whenever we need to invent new mechanisms, we attempt to do so 156 in such a way that it preserves the style of TLS. 158 Unreliability creates problems for TLS at two levels: 160 1. TLS's traffic encryption layer does not allow 161 independent decryption of individual records. If record N 162 is not received, then record N+1 cannot be decrypted. 164 2. The TLS handshake layer assumes that handshake messages 165 are delivered reliably and breaks if those messages are 166 lost. 168 The rest of this section describes the approach that DTLS uses 169 to solve these problems. 171 3.1. Loss-insensitive messaging 173 In TLS's traffic encryption layer (called the TLS Record 174 Layer), records are not independent. There are two kinds of 175 inter-record dependency: 177 1. Cryptographic context (CBC state, stream cipher key 178 stream) is chained between records. 180 2. Anti-replay and message reordering protection are 181 provided by a MAC which includes a sequence number, but the 182 sequence numbers are implicit in the records. 184 The fix for both of these problems is straightforward and 185 well-known from IPsec ESP [ESP]: add explicit state to the 186 records. TLS 1.1 [TLS11] is already adding explicit CBC state 187 to TLS records. DTLS borrows that mechanism and adds explicit 188 sequence numbers. 190 3.2. Providing Reliability for Handshake 192 The TLS handshake is a lockstep cryptographic handshake. 193 Messages must be transmitted and received in a defined order 194 and any other order is an error. Clearly, this is incompatible 195 with reordering and message loss. In addition, TLS handshake 196 messages are potentially larger than any given datagram, thus 197 creating the problem of fragmentation. DTLS must provide fixes 198 for both these problems. 200 3.2.1. Packet Loss 202 DTLS uses a simple retransmission timer to handle packet loss. 203 The following figure demonstrates the basic concept using the 204 first phase of the DTLS handshake: 206 Client Server 207 ------ ------ 208 ClientHello ------> 210 X<-- HelloVerifyRequest 211 (lost) 213 [Timer Expires] 215 ClientHello ------> 216 (retransmit) 218 Once the client has transmitted the ClientHello message, it 219 expects to see a HelloVerifyRequest from the server. However, 220 if the server's message is lost the client knows that either 221 the ClientHello or the HelloVerifyRequest has been lost and 222 retransmits. When the server receives the retransmission, it 223 knows to retransmit. The server also maintains a 224 retransmission timer and retransmits when that timer expires. 226 Note: timeout and retransmission do not apply to the 227 HelloVerifyRequest, because this requires creating state on 228 the server. 230 3.2.2. Reordering 232 In DTLS, each handshake message is assigned a specific 233 sequence number within that handshake. When a peer receives a 234 handshake message, it can quickly determine whether that 235 message is the next message it expects. If it is, then it 236 processes it. If not, it queues it up for future handling once 237 all previous messages have been received. 239 3.2.3. Message Size 241 TLS and DTLS handshake messages can be quite large (in theory 242 up to 2^24-1 bytes, in practice many kilobytes). By contrast, 243 UDP datagrams are often limited to <1500 bytes if 244 fragmentation is not desired. In order to compensate for this 245 limitation, each DTLS handshake message may be fragmented over 246 several DTLS records. Each DTLS handshake message contains 247 both a fragment offset and a fragment length. Thus, a 248 recipient in possession of all bytes of a handshake message 249 can reassemble the original unfragmented message. 251 3.3. Replay Detection 253 DTLS optionally supports record replay detection. The 254 technique used is the same as in IPsec AH/ESP, by maintaining 255 a bitmap window of received records. Records that are too old 256 to fit in the window and records that have been previously 257 received are silently discarded. The replay detection feature 258 is optional, since packet duplication is not always malicious, 259 but can also occur due to routing errors. Applications may 260 conceivably detect duplicate packets and accordingly modify 261 their data transmission strategy. 263 4. Differences from TLS 265 As mentioned in Section 3., DTLS is intentionally very similar 266 to TLS. Therefore, instead of presenting DTLS as a new 267 protocol, we instead present it as a series of deltas from TLS 268 1.1 [TLS11]. Where we do not explicitly call out differences, 269 DTLS is the same as TLS. 271 4.1. Record Layer 273 The DTLS record layer is extremely similar to that of TLS 1.1. 274 The only change is the inclusion of an explicit sequence 275 number in the record. This sequence number allows the 276 recipient to correctly verify the TLS MAC. The DTLS record 277 format is shown below: 279 struct { 280 ContentType type; 281 ProtocolVersion version; 282 uint16 epoch; // New field 283 uint48 sequence_number; // New field 284 uint16 length; 285 opaque fragment[DTLSPlaintext.length]; 286 } DTLSPlaintext; 288 type 289 Equivalent to the type field in a TLS 1.1 record. 291 version 292 The version of the protocol being employed. This document 293 describes DTLS Version 1.0, which uses the version { 254, 255 294 }. The version value of 254.255 is the 1's complement of DTLS 295 Version 1.0. This maximal spacing between TLS and DTLS version 296 numbers ensures that records from the two protocols can be 297 easily distinguished. 299 epoch 300 A counter value that is incremented on every cipher state 301 change. 303 sequence_number 304 The sequence number for this record. 306 length 307 Identical to the length field in a TLS 1.1 record. As in TLS 308 1.1, the length should not exceed 2^14. 310 fragment 311 Identical to the fragment field of a TLS 1.1 record. 313 DTLS uses an explicit rather than implicit sequence number, 314 carried in the sequence_number field of the record. As with 315 TLS, the sequence number is set to zero after each 316 ChangeCipherSpec message is sent. 318 If several handshakes are performed in close succession, there 319 might be multiple records on the wire with the same sequence 320 number but from different cipher states. The epoch field 321 allows recipients to distinguish such packets. The epoch 322 number is initially zero and is incremented each time the 323 ChangeCipherSpec messages is sent. In order to ensure that any 324 given sequence/epoch pair is unique, implementations MUST NOT 325 allow the same epoch value to be reused within two times the 326 TCP maximum segment lifetime. In practice, TLS implementations 327 rehandshake rarely and we therefore do not expect this to be a 328 problem. 330 4.1.1. Transport Layer Mapping 332 Each DTLS record MUST fit within a single datagram. In order 333 to avoid IP fragmentation [MOGUL], DTLS implementations SHOULD 334 determine the MTU and send records smaller than the MTU. DTLS 335 implementations SHOULD provide a way for applications to 336 determine the value of the PMTU (or alternately the maximum 337 application datagram size, which is the PMTU minus the DTLS 338 per-record overhead). If the application attempts to send a 339 record larger than the MTU the DTLS implementation SHOULD 340 generate an error, thus avoiding sending a packet which will 341 be fragmented. 343 Note that unlike IPsec, DTLS records do not contain any 344 association identifiers. Applications must arrange to 345 multiplex between associations. With UDP, this is presumably 346 done with host/port number. 348 Multiple DTLS records may be placed in a single datagram. hey 349 are simply encoded consecutively. The DTLS record framing is 350 sufficient to determine the boundaries. Note, however, that 351 the first byte of the datagram payload must be the beginning 352 of a record. Records may not span datagrams. 354 4.1.1.1. PMTU Discovery 356 In general, DTLS's philosophy is to avoid dealing with PMTU 357 issues. The general strategy is to start with a conservative 358 MTU and then update it if events require it, but not actively 359 probe for MTU values. PMTU discovery is left to the 360 application. 362 The PMTU SHOULD be initialized from the interface MTU that 363 will be used to send packets. If the DTLS implementation 364 receives an RFC 1191 [RFC1191] ICMP Destination Unreachable 365 message with the "fragmentation needed and DF set" Code 366 (otherwise known as Datagram Too Big) it should decrease its 367 PMTU estimate to that given in the ICMP message. A DTLS 368 implementation SHOULD allow the application to occasionally 369 reset its PMTU estimate. The DTLS implementation SHOULD also 370 allow applications to control the status of the DF bit. These 371 controls allow the application to perform PMTU discovery. 373 One special case is the DTLS handshake system. Handshake 374 messages should be set with DF set. Because some firewalls and 375 routers screen out ICMP messages, it is difficult for the 376 handshake layer to distinguish packet loss from an overlarge 377 PMTU estimate. In order to allow connections under these 378 circumstances, DTLS implementations SHOULD back off handshake 379 packet size during the retransmit backoff described in Section 380 4.2.4.. For instance, if a large packet is being sent, after 3 381 retransmits the handshake layer might choose to fragment the 382 handshake message on retransmission. In general, choice of a 383 conservative initial MTU will avoid this problem. 385 4.1.2. Record payload protection 387 Like TLS, DTLS transmits data as a series of protected 388 records. The rest of this section describes the details of 389 that format. 391 4.1.2.1. MAC 393 The DTLS MAC is the same as that of TLS 1.1. However, rather 394 than using TLS's implicit sequence number, the sequence number 395 used to compute the MAC is the 64-bit value formed by 396 concatenating the epoch and the sequence number in the order 397 they appear on the wire. Note that the DTLS epoch + sequence 398 number is the same length as the TLS sequence number. 400 Note that one important difference between DTLS and TLS MAC 401 handling is that in TLS MAC errors must result in connection 402 termination. In DTLS, the receiving implementation MAY simply 403 discard the offending record and continue with the connection. 404 This change is possible because DTLS records are not dependent 405 on each other the way that TLS records are. 407 4.1.2.2. Null or standard stream cipher 409 The DTLS NULL cipher is performed exactly as the TLS 1.1 NULL 410 cipher. 412 The only stream cipher described in TLS 1.1 is RC4, which 413 cannot be randomly accessed. RC4 MUST NOT be used with DTLS. 415 4.1.2.3. Block Cipher 417 DTLS block cipher encryption and decryption are performed 418 exactly as with TLS 1.1. 420 4.1.2.4. New Cipher Suites 422 Upon registration, new TLS cipher suites MUST indicate whether 423 they are suitable for DTLS usage and what, if any, adaptations 424 must be made. 426 4.1.2.5. Anti-Replay 428 DTLS records contain a sequence number to provide replay 429 protection. Sequence number verification SHOULD be performed 430 using the following sliding, window procedure, borrowed from 431 Section 3.4.3 of [RFC 2402] 433 The receiver packet counter for this session MUST be 434 initialized to zero when the session is established. For each 435 received record, the receiver MUST verify that the record 436 contains a Sequence Number that does not duplicate the 437 Sequence Number of any other record received during the life 438 of this session. This SHOULD be the first check applied to a 439 packet after it has been matched to a session, to speed 440 rejection of duplicate records. 442 Duplicates are rejected through the use of a sliding receive 443 window. (How the window is implemented is a local matter, but 444 the following text describes the functionality that the 445 implementation must exhibit.) A minimum window size of 32 MUST 446 be supported; but a window size of 64 is preferred and SHOULD 447 be employed as the default. Another window size (larger than 448 the minimum) MAY be chosen by the receiver. (The receiver does 449 not notify the sender of the window size.) 451 The "right" edge of the window represents the highest, 452 validated Sequence Number value received on this session. 453 Records that contain Sequence Numbers lower than the "left" 454 edge of the window are rejected. Packets falling within the 455 window are checked against a list of received packets within 456 the window. An efficient means for performing this check, 457 based on the use of a bit mask, is described in Appendix C of 458 [RFC 2401]. 460 If the received record falls within the window and is new, or 461 if the packet is to the right of the window, then the receiver 462 proceeds to MAC verification. If the MAC validation fails, the 463 receiver MUST discard the received record as invalid. The 464 receive window is updated only if the MAC verification 465 succeeds. 467 4.2. The DTLS Handshake Protocol 469 DTLS uses all of the same handshake messages and flows as TLS, 470 with three principal changes: 472 1. A stateless cookie exchange has been added to prevent 473 denial of service attacks. 475 2. Modifications to the handshake header to handle message 476 loss, reordering and fragmentation. 478 3. Retransmission timers to handle message loss. 480 With these exceptions, the DTLS message formats, flows, and 481 logic are the same as those of TLS 1.1. 483 4.2.1. Denial of Service Countermeasures 485 Datagram security protocols are extremely susceptible to a 486 variety of denial of service (DoS) attacks. Two attacks are of 487 particular concern: 489 1. An attacker can consume excessive resources on the 490 server by transmitting a series of handshake initiation 491 requests, causing the server to allocate state and 492 potentially perform expensive cryptographic operations. 494 2. An attacker can use the server as an amplifier by 495 sending connection initiation messages with a forged source 496 of the victim. The server then sends its next message (in 497 DTLS, a Certificate message, which can be quite large) to 498 the victim machine, thus flooding it. 500 In order to counter both of these attacks, DTLS borrows the 501 stateless cookie technique used by Photuris [PHOTURIS] and IKE 502 [IKE]. When the client sends its ClientHello message to the 503 server, the server MAY respond with a HelloVerifyRequest 504 message. This message contains a stateless cookie generated 505 using the technique of [PHOTURIS]. The client MUST retransmit 506 the ClientHello with the cookie added. The server then 507 verifies the cookie and proceeds with the handshake only if it 508 is valid. This mechanism forces the attacker/client to be able 509 to receive the cookie, which makes DoS attacks with spoofed IP 510 addresses difficult. This mechanism does not provide any 511 defense against DoS attacks mounted from valid IP addresses. 513 The exchange is shown below: 515 Client Server 516 ------ ------ 517 ClientHello ------> 519 <----- HelloVerifyRequest 520 (contains cookie) 522 ClientHello ------> 523 (with cookie) 525 [Rest of handshake] 527 DTLS therefore modifies the ClientHello message to add the 528 cookie value. 530 struct { 531 ProtocolVersion client_version; 532 Random random; 533 SessionID session_id; 534 opaque cookie<0..32>; // New field 535 CipherSuite cipher_suites<2..2^16-1>; 536 CompressionMethod compression_methods<1..2^8-1>; 537 } ClientHello; 539 When sending the first ClientHello, the client does not have a 540 cookie yet; in this case, the Cookie field is left empty (zero 541 length). 543 The definition of HelloVerifyRequest is as follows: 545 struct { 546 Cookie cookie<0..32>; 547 } HelloVerifyRequest; 549 The HelloVerifyRequest message type is 550 hello_verify_request(3). 552 When responding to a HelloVerifyRequest the client MUST use 553 the same parameter values (version, random, session_id, 554 cipher_suites, compression_method) as in the original 555 ClientHello. The server SHOULD use those values to generate 556 its cookie and verify that they are correct upon cookie 557 receipt. The DTLS server SHOULD generate cookies in such a way 558 that they can be verified without retaining any per-client 559 state on the server. One technique is to have a randomly 560 generated secret and generate cookies as: 561 Cookie = HMAC(Secret, Client-IP, Client-Parameters) 563 When the second ClientHello is received, the server can verify 564 that the Cookie is valid and that the client can receive 565 packets at the given IP address. 566 One potential attack on this scheme is for the attacker to 567 collect a number of cookies from different addresses and then 568 reuse them to attack the server. The server can defend against 569 this attack by changing the Secret value frequently, thus 570 invalidating those cookies. If the server wishes legitimate 571 clients to be able to handshake through the transition (e.g., 572 they received a cookie with Secret 1 and then sent the second 573 ClientHello after the server has changed to Secret 2), the 574 server can have a limited window during which it accepts both 575 secrets. [IKEv2] suggests adding a version number to cookies 576 to detect this case. An alternative approach is simply to try 577 verifying with both secrets. 579 Although DTLS servers are not required to do a cookie 580 exchange, they SHOULD do so whenever a new handshake is 581 performed in order to avoid being used as amplifiers. If the 582 server is being operated in an environment where amplification 583 is not a problem, the server MAY choose not to perform a 584 cookie exchange. In addition, the server MAY choose not do to 585 a cookie exchange when a session is resumed. Clients MUST be 586 prepared to do a cookie exchange with every handshake. 588 If HelloVerifyRequest is used, the initial ClientHello and 589 HelloVerifyRequest are not included in the calculation of the 590 verify_data for the Finished message. 592 4.2.2. Handshake Message Format 594 In order to support message loss, reordering, and 595 fragmentation DTLS modifies the TLS 1.1 handshake header: 597 struct { 598 HandshakeType msg_type; 599 uint24 length; 600 uint16 message_seq; // New field 601 uint24 fragment_offset; // New field 602 uint24 fragment_length; // New field 603 select (HandshakeType) { 604 case hello_request: HelloRequest; 605 case client_hello: ClientHello; 606 case hello_verify_request: HelloVerifyRequest; // New type 607 case server_hello: ServerHello; 608 case certificate:Certificate; 609 case server_key_exchange: ServerKeyExchange; 610 case certificate_request: CertificateRequest; 611 case server_hello_done:ServerHelloDone; 612 case certificate_verify: CertificateVerify; 613 case client_key_exchange: ClientKeyExchange; 614 case finished:Finished; 615 } body; 616 } Handshake; 618 The first message each side transmits in each handshake always 619 has message_seq = 0. Whenever each new message is generated, 620 the message_seq value is incremented by one. When a message is 621 retransmitted, the same message_seq value is used. For 622 example. 624 Client Server 625 ------ ------ 626 ClientHello (seq=0) ------> 628 X<-- HelloVerifyRequest (seq=0) 629 (lost) 631 [Timer Expires] 633 ClientHello (seq=0) ------> 634 (retransmit) 636 <------ HelloVerifyRequest (seq=0) 638 ClientHello (seq=1) ------> 639 (with cookie) 641 <------ ServerHello (seq=1) 642 <------ Certificate (seq=2) 643 <------ ServerHelloDone (seq=3) 645 [Rest of handshake] 647 Note, however, that from the perspective of the DTLS record 648 layer, the retransmission is a new record. This record will 649 have a new DTLSPlaintext.sequence_number value. 651 DTLS implementations maintain (at least notionally) a 652 next_receive_seq counter. This counter is initially set to 653 zero. When a message is received, if its sequence number 654 matches next_receive_seq, next_receive_seq is incremented and 655 the message is processed. If the sequence number is less than 656 next_receive_seq the message MUST be discarded. If the 657 sequence number is greater than next_receive_seq, the 658 implementation SHOULD queue the message but MAY discard it. 659 (This is a simple space/bandwidth tradeoff). 661 4.2.3. Message Fragmentation and Reassembly 663 As noted in Section 4.1.1., each DTLS message MUST fit within 664 a single transport layer datagram. However, handshake messages 665 are potentially bigger than the maximum record size. Therefore 666 DTLS provides a mechanism for fragmenting a handshake message 667 over a number of records. 669 When transmitting the handshake message, the sender divides 670 the message into a series of N contiguous data ranges. These 671 range MUST NOT be larger than the maximum handshake fragment 672 size and MUST jointly contain the entire handshake message. 673 The ranges SHOULD NOT overlap. The sender then creates N 674 handshake messages, all with the same message_seq value as the 675 original handshake message. Each new message is labelled with 676 the fragment_offset (the number of bytes contained in previous 677 fragments) and the fragment_length (the length of this 678 fragment). The length field in all messages is the same as the 679 length field of the original message. An unfragmented message 680 is a degenerate case with fragment_offset=0 and 681 fragment_length=length. 683 When a DTLS implementation receives a handshake message 684 fragment, it MUST buffer it until it has the entire handshake 685 message. DTLS implementations MUST be able to handle 686 overlapping fragment ranges. This allows senders to retransmit 687 handshake messages with smaller fragment sizes during path MTU 688 discovery. 690 Note that as with TLS, multiple handshake messages may be 691 placed in the same DTLS record, provided that there is room 692 and that they are part of the same flight. Thus, there are two 693 acceptable ways to pack two DTLS messages into the same 694 datagram: in the same record or in separate records. 696 4.2.4. Timeout and Retransmission 698 DTLS messages are grouped into a series of message flights, 699 according the diagrams below. Although each flight of messages 700 may consist of a number of messages, they should be viewed as 701 monolithic for the purpose of timeout and retransmission. 703 Client Server 704 ------ ------ 706 ClientHello --------> Flight 1 708 <------- HelloVerifyRequest Flight 2 710 ClientHello --------> Flight 3 712 ServerHello \ 713 Certificate* \ 714 ServerKeyExchange* Flight 4 715 CertificateRequest* / 716 <-------- ServerHelloDone / 718 Certificate* \ 719 ClientKeyExchange \ 720 CertificateVerify* Flight 5 721 [ChangeCipherSpec] / 722 Finished --------> / 724 [ChangeCipherSpec] \ Flight 6 725 <-------- Finished / 726 Figure 1: Message flights for full handshake 728 Client Server 729 ------ ------ 731 ClientHello --------> Flight 1 733 ServerHello \ 734 [ChangeCipherSpec] Flight 2 735 <-------- Finished / 737 [ChangeCipherSpec] \Flight 3 738 Finished --------> / 739 Figure 2: Message flights for session resuming handshake (no 740 cookie exchange) 741 DTLS uses a simple timeout and retransmission scheme with the 742 following state machine. Because DTLS clients send the first 743 message (ClientHello) they start in the PREPARING state. DTLS 744 servers start in the WAITING state, but with empty buffers and 745 no retransmit timer. 747 +-----------+ 748 | PREPARING | 749 +---> | | 750 | | | 751 | +-----------+ 752 | | 753 | | 754 | | Buffer next flight 755 | | 756 | \|/ 757 | +-----------+ 758 | | | 759 | | SENDING |<------------------+ 760 | | | | 761 | +-----------+ | 762 Receive | | | 763 next | | Send flight | 764 flight | +--------+ | 765 | | | Set retransmit timer | 766 | | \|/ | 767 | | +-----------+ | 768 | | | | | 769 +--)--| WAITING |-------------------+ 770 | | | | Timer expires | 771 | | +-----------+ | 772 | | | | 773 | | | | 774 | | +------------------------+ 775 | | Read retransmit 776 Receive | | 777 last | | 778 flight | | 779 | | 780 \|/\|/ 782 +-----------+ 783 | | 784 | FINISHED | 785 | | 786 +-----------+ 788 Figure 3: DTLS timeout and retransmission state machine 790 The state machine has three basic states. 792 In the PREPARING state the implementation does whatever 793 computations are necessary to prepare the next flight of 794 messages. It then buffers them up for transmission (emptying 795 the buffer first) and enters the SENDING state. 797 In the SENDING state, the implementation transmits the 798 buffered flight of messages. Once the messages have been sent, 799 the implementation then enters the FINISHED state if this is 800 the last flight in the handshake, or, if the implementation 801 expects to receive more messages, sets a retransmit timer and 802 then enters the WAITING state. 804 There are three ways to exit the WAITING state: 806 1. The retransmit timer expires: the implementation 807 transitions to the SENDING state, where it retransmits the 808 flight, resets the retransmit timer, and returns to the 809 WAITING state. 811 2. The implementation reads a retransmitted flight from the 812 peer: the implementation transitions to the SENDING state, 813 where it retransmits the flight, resets the retransmit 814 timer, and returns to the WAITING state. The rationale here 815 is that the receipt of a duplicate message is the likely 816 result of timer expiry on the peer and therefore suggests 817 that part of one's previous flight was lost. 819 3. The implementation receives the next flight of messages: 820 if this is the final flight of messages the implementation 821 transitions to FINISHED. If the implementation needs to 822 send a new flight, it transitions to the PREPARING state. 823 Partial reads (whether partial messages or only some of the 824 messages in the flight) do not cause state transitions or 825 timer resets. 827 Because DTLS clients send the first message (ClientHello) they 828 start in the PREPARING state. DTLS servers start in the 829 WAITING state, but with empty buffers and no retransmit timer. 831 4.2.4.1. Timer Values 833 Timer value choices are a local matter. Implementations SHOULD 834 use an initial timer value of 500 ms and double the value at 835 each retransmission, up to twice the TCP maximum segment 836 lifetime [TCP] (if the recommendations in [TCP] are followed, 837 this will be 240 seconds). Implementations SHOULD start the 838 timer value at the initial value with each new flight of 839 messages. 841 4.2.5. ChangeCipherSpec 843 As with TLS, the ChangeCipherSpec message is not technically a 844 handshake message but MUST be treated as part of the same 845 flight as the associated Finished message for the purposes of 846 timeout and retransmission. 848 4.2.6. Finished messages 850 Finished messages have the same format as in TLS. However, in 851 order to remove sensitivity to fragmentation, the Finished MAC 852 MUST be computed as if each handshake message had been sent as 853 a single fragment. Note that in cases where the cookie 854 exchange is used, the initial ClientHello and 855 HelloVerifyRequest MUST BE included in the Finished MAC. 857 4.2.7. Alert Messages 859 Note that Alert messages are not retransmitted at all, even 860 when they occur in the context of a handshake. However, a DTLS 861 implementation SHOULD generate a new alert message if the 862 offending record is received again (e.g., as a retransmitted 863 handshake message). 865 A.1Summary of new syntax 867 This section includes specifications for the data structures 868 that have changed between TLS 1.1 and DTLS. 870 4.2. Record Layer 871 struct { 872 ContentType type; 873 ProtocolVersion version; 874 uint16 epoch; // New field 875 uint48 sequence_number; // New field 876 uint16 length; 877 opaque fragment[DTLSPlaintext.length]; 878 } DTLSPlaintext; 880 struct { 881 ContentType type; 882 ProtocolVersion version; 883 uint16 epoch; // New field 884 uint48 sequence_number; // New field 885 uint16 length; 886 opaque fragment[DTLSCompressed.length]; 887 } DTLSCompressed; 889 struct { 890 ContentType type; 891 ProtocolVersion version; 892 uint16 epoch; // New field 893 uint48 sequence_number; // New field 894 uint16 length; 895 select (CipherSpec.cipher_type) { 896 case block: GenericBlockCipher; 897 } fragment; 898 } DTLSCiphertext; 900 4.3. Handshake Protocol 902 enum { 903 hello_request(0), client_hello(1), server_hello(2), 904 hello_verify_request(3), // New field 905 certificate(11), server_key_exchange (12), 906 certificate_request(13), server_hello_done(14), 907 certificate_verify(15), client_key_exchange(16), 908 finished(20), (255) 909 } HandshakeType; 911 struct { 912 HandshakeType msg_type; 913 uint24 length; 914 uint16 message_seq; // New field 915 uint24 fragment_offset; // New field 916 uint24 fragment_length; // New field 917 select (HandshakeType) { 918 case hello_request: HelloRequest; 919 case client_hello: ClientHello; 920 case server_hello: ServerHello; 921 case hello_verify_request: HelloVerifyRequest; // New field 922 case certificate:Certificate; 923 case server_key_exchange: ServerKeyExchange; 924 case certificate_request: CertificateRequest; 925 case server_hello_done:ServerHelloDone; 926 case certificate_verify: CertificateVerify; 927 case client_key_exchange: ClientKeyExchange; 928 case finished:Finished; 929 } body; 930 } Handshake; 932 struct { 933 ProtocolVersion client_version; 934 Random random; 935 SessionID session_id; 936 opaque cookie<0..32>; // New field 937 CipherSuite cipher_suites<2..2^16-1>; 938 CompressionMethod compression_methods<1..2^8-1>; 939 } ClientHello; 941 struct { 942 Cookie cookie<0..32>; 943 } HelloVerifyRequest; 945 5. Security Considerations 947 This document describes a variant of TLS 1.1 and therefore 948 most of the security considerations are the same as those of 949 TLS 1.1 [TLS11], described in Appendices D, E, and F. 951 The primary additional security consideration raised by DTLS 952 is that of denial of service. DTLS includes a cookie exchange 953 designed to protect against denial of service. However, 954 implementations which do not use this cookie exchange are 955 still vulnerable to DoS. In particular, DTLS servers which do 956 not use the cookie exchange may be used as attack amplifiers 957 even if they themselves are not experiencing DoS. Therefore 958 DTLS servers SHOULD use the cookie exchange unless there is 959 good reason to believe that amplification is not a threat in 960 their environment. 962 6. IANA Considerations 964 This document uses the same identifier space as TLS [TLS11], 965 so no new IANA registries are required. When new identifiers 966 are assigned for TLS, authors MUST specify whether they are 967 suitable for DTLS. 969 This document defines a new handshake message, 970 hello_verify_request, whose value is to be allocated from the 971 TLS HandshakeType registry defined in [TLS11]. The value "3" 972 is suggested. 974 References 976 Normative References 978 [RFC1191] Mogul, J. C., Deering, S.E., "Path MTU Discovery", 979 RFC 1191, November 1990. 981 [RFC2401] Kent, S., Atkinson, R., "Security Architecture for the 982 Internet Protocol", RFC2401, November 1998. 984 [TCP] Postel, J., "Transmission Control Protocol", 985 RFC 793, September 1981. 987 [TLS11] Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1", 988 draft-ietf-tls-rfc2246-bis-05.txt, July 2003. 990 Informative References 992 [AH] Kent, S., and Atkinson, R., "IP Authentication Header", 993 RFC 2402, November 1998. 995 [DCCP] Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram 996 Congestion Control Protocol", draft-ietf-dccp-spec-11.txt, 997 10 March 2005 999 [DNS] Mockapetris, P.V., "Domain names - implementation and 1000 specification", RFC 1035, November 1987. 1002 [DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation 1003 of Datagram TLS", Proceedings of ISOC NDSS 2004, February 2004. 1005 [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security 1006 Payload (ESP)", RFC 2406, November 1998. 1008 [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", 1009 RFC 2409, November 1998. 1011 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1012 draft-ietf-ipsec-ikev2-17.txt, September 2004. 1014 [IMAP] Crispin, M., "Internet Message Access Protocol - Version 1015 4rev1", RFC 3501, March 2003. 1017 [PHOTURIS] Karn, P., Simpson, W., "Photuris: Session-Key Management 1018 Protocol", RFC 2521, March 1999. 1020 [POP] Myers, J., and Rose, M., "Post Office Protocol - 1021 Version 3", RFC 1939, May 1996. 1023 [REQ] Bradner, S., "Key words for use in RFCs to Indicate 1024 Requirement Levels", BCP 14, RFC 2119, March 1997. 1026 [SIP] Rosenberg, J., Schulzrinne, Camarillo, G., Johnston, A., 1027 Peterson, J., Sparks, R., Handley, M., Schooler, E., 1028 "SIP: Session Initiation Protocol", RFC 3261, 1029 June 2002. 1031 [TLS] Dierks, T., and Allen, C., "The TLS Protocol Version 1.0", 1032 RFC 2246, January 1999. 1034 [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", 1035 draft-bellovin-useipsec-02.txt, October 2003 1037 Authors' Address 1039 Eric Rescorla 1040 RTFM, Inc. 1041 2064 Edgewood Drive 1042 Palo Alto, CA 94303 1044 Nagendra Modadugu 1045 Computer Science Department 1046 353 Serra Mall 1047 Stanford University 1048 Stanford, CA 94305 1050 Acknowledgements 1052 The authors would like to thank Dan Boneh, Eu-Jin Goh, Russ 1053 Housley, Constantine Sapuntzakis, and Hovav Shacham for 1054 discussions and comments on the design of DTLS. Thanks to the 1055 anonymous NDSS reviewers of our original NDSS paper on DTLS 1056 [DTLS] for their comments. Also, thanks to Steve Kent for 1057 feedback that helped clarify many points. The section on PMTU 1058 was cribbed from the DCCP specification [DCCP]. Pasi Eronen 1059 provided a detailed review of this specification. 1061 Full Copyright Statement 1063 The IETF takes no position regarding the validity or scope of any 1064 Intellectual Property Rights or other rights that might be claimed to 1065 pertain to the implementation or use of the technology described in 1066 this document or the extent to which any license under such rights 1067 might or might not be available; nor does it represent that it has 1068 made any independent effort to identify any such rights. Information 1069 on the procedures with respect to rights in RFC documents can be 1070 found in BCP 78 and BCP 79. 1072 Copies of IPR disclosures made to the IETF Secretariat and any 1073 assurances of licenses to be made available, or the result of an 1074 attempt made to obtain a general license or permission for the use of 1075 such proprietary rights by implementers or users of this 1076 specification can be obtained from the IETF on-line IPR repository at 1077 http://www.ietf.org/ipr. 1079 The IETF invites any interested party to bring to its attention any 1080 copyrights, patents or patent applications, or other proprietary 1081 rights that may cover technology that may be required to implement 1082 this standard. Please address the information to the IETF at ietf- 1083 ipr@ietf.org. 1085 Copyright Notice 1086 Copyright (C) The Internet Society (2003). This document is subject 1087 to the rights, licenses and restrictions contained in BCP 78, and 1088 except as set forth therein, the authors retain all their rights. 1090 This document and the information contained herein are provided on an 1091 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1092 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1093 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1094 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1095 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1096 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.