idnits 2.17.1 draft-rescorla-dtls-05.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 1164. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1138. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1145. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1151. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1156), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 34. ** 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 12 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 456, but not defined ** Obsolete undefined reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) == Missing Reference: 'RFC 2401' is mentioned on line 483, but not defined ** Obsolete undefined reference: RFC 2401 (Obsoleted by RFC 4301) == Missing Reference: 'ChangeCipherSpec' is mentioned on line 769, but not defined == Unused Reference: 'AESCACHE' is defined on line 1051, but no explicit reference was found in the text == Unused Reference: 'AH' is defined on line 1054, but no explicit reference was found in the text == Unused Reference: 'DNS' is defined on line 1061, but no explicit reference was found in the text == Unused Reference: 'DTLS' is defined on line 1122, but no explicit reference was found in the text == Unused Reference: 'SCTP' is defined on line 1088, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) == Outdated reference: A later version (-13) exists of draft-ietf-tls-rfc2246-bis-05 ** 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: A later version (-13) exists of draft-ietf-dccp-spec-11 -- 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) -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. 'SCTP') (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) == Outdated reference: A later version (-10) exists of draft-bellovin-useipsec-02 Summary: 13 errors (**), 0 flaws (~~), 15 warnings (==), 13 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 June 2004 (Expires December 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 (2005). 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 9 63 4.1.2 Record payload protection 9 64 4.1.2.1 MAC 10 65 4.1.2.2 Null or standard stream cipher 10 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 12 71 4.2.2 Handshake Message Format 14 72 4.2.3 Message Fragmentation and Reassembly 16 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 21 79 4.3 Handshake Protocol 21 80 5 Security Considerations 22 81 6 IANA Considerations 23 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 use 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 subset 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 requires 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 in [TLS11]. 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. They 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 Some transports, such as DCCP [DCCP] provide their own 355 sequence numbers. When carried over those transports, both the 356 DTLS and the transport sequence numbers will be present. 357 Although this introduces a small amount of inefficiency, the 358 transport layer and DTLS sequence numbers serve different 359 purposes and therefore for conceptual simplicity it is 360 superior to use both sequence numbers. In the future, 361 extensions to DTLS may be specified that allow the use of only 362 one set of sequence numbers for deployment in constrained 363 environments. 364 Some transports, such as DCCP, provide congestion control 365 for traffic carried over them. If the congestion window is 366 sufficiently narrow, DTLS handshake retransmissions may be 367 held rather than transmitted immediately, potentially leading 368 to timeouts and spurious retransmission. When DTLS is used 369 over such transports, care should be taken not to overrun the 370 likely congestion window. In the future, a DTLS-DCCP mapping 371 may be specificied to provide optimal behavior for this 372 interaction. 374 4.1.1.1. PMTU Discovery 376 In general, DTLS's philosophy is to avoid dealing with PMTU 377 issues. The general strategy is to start with a conservative 378 MTU and then update it if events during the handshake or 379 actual application data transport phase require it. 381 The PMTU SHOULD be initialized from the interface MTU that 382 will be used to send packets. If the DTLS implementation 383 receives an RFC 1191 [RFC1191] ICMP Destination Unreachable 384 message with the "fragmentation needed and DF set" Code 385 (otherwise known as Datagram Too Big) it should decrease its 386 PMTU estimate to that given in the ICMP message. A DTLS 387 implementation SHOULD allow the application to occasionally 388 reset its PMTU estimate. The DTLS implementation SHOULD also 389 allow applications to control the status of the DF bit. These 390 controls allow the application to perform PMTU discovery. RFC 391 1981 [RFC1981] procedures SHOULD be followed for IPv6. 393 One special case is the DTLS handshake system. Handshake 394 messages should be set with DF set. Because some firewalls and 395 routers screen out ICMP messages, it is difficult for the 396 handshake layer to distinguish packet loss from an overlarge 397 PMTU estimate. In order to allow connections under these 398 circumstances, DTLS implementations SHOULD back off handshake 399 packet size during the retransmit backoff described in Section 400 4.2.4.. For instance, if a large packet is being sent, after 3 401 retransmits the handshake layer might choose to fragment the 402 handshake message on retransmission. In general, choice of a 403 conservative initial MTU will avoid this problem. 405 4.1.2. Record payload protection 407 Like TLS, DTLS transmits data as a series of protected 408 records. The rest of this section describes the details of 409 that format. 411 4.1.2.1. MAC 413 The DTLS MAC is the same as that of TLS 1.1. However, rather 414 than using TLS's implicit sequence number, the sequence number 415 used to compute the MAC is the 64-bit value formed by 416 concatenating the epoch and the sequence number in the order 417 they appear on the wire. Note that the DTLS epoch + sequence 418 number is the same length as the TLS sequence number. 420 Note that one important difference between DTLS and TLS MAC 421 handling is that in TLS MAC errors must result in connection 422 termination. In DTLS, the receiving implementation MAY simply 423 discard the offending record and continue with the connection. 424 This change is possible because DTLS records are not dependent 425 on each other the way that TLS records are. 426 In general, DTLS implementations SHOULD silently discard 427 data with bad MACs. If a DTLS implementation chooses to 428 generate an alert when it receives a message with an invalid 429 MAC, it MUST generate bad_record_mac alert with level fatal 430 and terminate its connection state. 432 4.1.2.2. Null or standard stream cipher 434 The DTLS NULL cipher is performed exactly as the TLS 1.1 NULL 435 cipher. 437 The only stream cipher described in TLS 1.1 is RC4, which 438 cannot be randomly accessed. RC4 MUST NOT be used with DTLS. 440 4.1.2.3. Block Cipher 442 DTLS block cipher encryption and decryption are performed 443 exactly as with TLS 1.1. 445 4.1.2.4. New Cipher Suites 447 Upon registration, new TLS cipher suites MUST indicate whether 448 they are suitable for DTLS usage and what, if any, adaptations 449 must be made. 451 4.1.2.5. Anti-Replay 453 DTLS records contain a sequence number to provide replay 454 protection. Sequence number verification SHOULD be performed 455 using the following sliding window procedure, borrowed from 456 Section 3.4.3 of [RFC 2402]. 458 The receiver packet counter for this session MUST be 459 initialized to zero when the session is established. For each 460 received record, the receiver MUST verify that the record 461 contains a Sequence Number that does not duplicate the 462 Sequence Number of any other record received during the life 463 of this session. This SHOULD be the first check applied to a 464 packet after it has been matched to a session, to speed 465 rejection of duplicate records. 467 Duplicates are rejected through the use of a sliding receive 468 window. (How the window is implemented is a local matter, but 469 the following text describes the functionality that the 470 implementation must exhibit.) A minimum window size of 32 MUST 471 be supported; but a window size of 64 is preferred and SHOULD 472 be employed as the default. Another window size (larger than 473 the minimum) MAY be chosen by the receiver. (The receiver does 474 not notify the sender of the window size.) 476 The "right" edge of the window represents the highest, 477 validated Sequence Number value received on this session. 478 Records that contain Sequence Numbers lower than the "left" 479 edge of the window are rejected. Packets falling within the 480 window are checked against a list of received packets within 481 the window. An efficient means for performing this check, 482 based on the use of a bit mask, is described in Appendix C of 483 [RFC 2401]. 485 If the received record falls within the window and is new, or 486 if the packet is to the right of the window, then the receiver 487 proceeds to MAC verification. If the MAC validation fails, the 488 receiver MUST discard the received record as invalid. The 489 receive window is updated only if the MAC verification 490 succeeds. 492 4.2. The DTLS Handshake Protocol 494 DTLS uses all of the same handshake messages and flows as TLS, 495 with three principal changes: 497 1. A stateless cookie exchange has been added to prevent 498 denial of service attacks. 500 2. Modifications to the handshake header to handle message 501 loss, reordering and fragmentation. 503 3. Retransmission timers to handle message loss. 505 With these exceptions, the DTLS message formats, flows, and 506 logic are the same as those of TLS 1.1. 508 4.2.1. Denial of Service Countermeasures 510 Datagram security protocols are extremely susceptible to a 511 variety of denial of service (DoS) attacks. Two attacks are of 512 particular concern: 514 1. An attacker can consume excessive resources on the 515 server by transmitting a series of handshake initiation 516 requests, causing the server to allocate state and 517 potentially perform expensive cryptographic operations. 519 2. An attacker can use the server as an amplifier by 520 sending connection initiation messages with a forged source 521 of the victim. The server then sends its next message (in 522 DTLS, a Certificate message, which can be quite large) to 523 the victim machine, thus flooding it. 525 In order to counter both of these attacks, DTLS borrows the 526 stateless cookie technique used by Photuris [PHOTURIS] and IKE 527 [IKE]. When the client sends its ClientHello message to the 528 server, the server MAY respond with a HelloVerifyRequest 529 message. This message contains a stateless cookie generated 530 using the technique of [PHOTURIS]. The client MUST retransmit 531 the ClientHello with the cookie added. The server then 532 verifies the cookie and proceeds with the handshake only if it 533 is valid. This mechanism forces the attacker/client to be able 534 to receive the cookie, which makes DoS attacks with spoofed IP 535 addresses difficult. This mechanism does not provide any 536 defense against DoS attacks mounted from valid IP addresses. 538 The exchange is shown below: 540 Client Server 541 ------ ------ 542 ClientHello ------> 544 <----- HelloVerifyRequest 545 (contains cookie) 547 ClientHello ------> 548 (with cookie) 550 [Rest of handshake] 551 DTLS therefore modifies the ClientHello message to add the 552 cookie value. 554 struct { 555 ProtocolVersion client_version; 556 Random random; 557 SessionID session_id; 558 opaque cookie<0..32>; // New field 559 CipherSuite cipher_suites<2..2^16-1>; 560 CompressionMethod compression_methods<1..2^8-1>; 561 } ClientHello; 563 When sending the first ClientHello, the client does not have a 564 cookie yet; in this case, the Cookie field is left empty (zero 565 length). 567 The definition of HelloVerifyRequest is as follows: 569 struct { 570 ProtocolVersion server_version; 571 opaque cookie<0..32>; 572 } HelloVerifyRequest; 574 The HelloVerifyRequest message type is 575 hello_verify_request(3). 577 The server_version field is defined as in TLS. 579 When responding to a HelloVerifyRequest the client MUST use 580 the same parameter values (version, random, session_id, 581 cipher_suites, compression_method) as in the original 582 ClientHello. The server SHOULD use those values to generate 583 its cookie and verify that they are correct upon cookie 584 receipt. The server MUST use the same version number in the 585 HelloVerifyRequest that it would use when sending a 586 ServerHello. Upon receipt of the ServerHello, the client MUST 587 verify that the server version values match. 589 The DTLS server SHOULD generate cookies in such a way that 590 they can be verified without retaining any per-client state on 591 the server. One technique is to have a randomly generated 592 secret and generate cookies as: 593 Cookie = HMAC(Secret, Client-IP, Client-Parameters) 595 When the second ClientHello is received, the server can verify 596 that the Cookie is valid and that the client can receive 597 packets at the given IP address. 598 One potential attack on this scheme is for the attacker to 599 collect a number of cookies from different addresses and then 600 reuse them to attack the server. The server can defend against 601 this attack by changing the Secret value frequently, thus 602 invalidating those cookies. If the server wishes legitimate 603 clients to be able to handshake through the transition (e.g., 604 they received a cookie with Secret 1 and then sent the second 605 ClientHello after the server has changed to Secret 2), the 606 server can have a limited window during which it accepts both 607 secrets. [IKEv2] suggests adding a version number to cookies 608 to detect this case. An alternative approach is simply to try 609 verifying with both secrets. 611 DTLS servers SHOULD perform a cookie exchange whenever a new 612 handshake is being performed. If the server is being operated 613 in an environment where amplification is not a problem, the 614 server MAY be configured to not to perform a cookie exchange. 615 The default SHOULD be that the exchange is performed, however. 616 In addition, the server MAY choose not do to a cookie exchange 617 when a session is resumed. Clients MUST be prepared to do a 618 cookie exchange with every handshake. 620 If HelloVerifyRequest is used, the initial ClientHello and 621 HelloVerifyRequest are not included in the calculation of the 622 verify_data for the Finished message. 624 4.2.2. Handshake Message Format 626 In order to support message loss, reordering, and 627 fragmentation DTLS modifies the TLS 1.1 handshake header: 629 struct { 630 HandshakeType msg_type; 631 uint24 length; 632 uint16 message_seq; // New field 633 uint24 fragment_offset; // New field 634 uint24 fragment_length; // New field 635 select (HandshakeType) { 636 case hello_request: HelloRequest; 637 case client_hello: ClientHello; 638 case hello_verify_request: HelloVerifyRequest; // New type 639 case server_hello: ServerHello; 640 case certificate:Certificate; 641 case server_key_exchange: ServerKeyExchange; 642 case certificate_request: CertificateRequest; 643 case server_hello_done:ServerHelloDone; 644 case certificate_verify: CertificateVerify; 645 case client_key_exchange: ClientKeyExchange; 646 case finished:Finished; 647 } body; 648 } Handshake; 650 The first message each side transmits in each handshake always 651 has message_seq = 0. Whenever each new message is generated, 652 the message_seq value is incremented by one. When a message is 653 retransmitted, the same message_seq value is used. For 654 example. 656 Client Server 657 ------ ------ 658 ClientHello (seq=0) ------> 660 X<-- HelloVerifyRequest (seq=0) 661 (lost) 663 [Timer Expires] 665 ClientHello (seq=0) ------> 666 (retransmit) 668 <------ HelloVerifyRequest (seq=0) 670 ClientHello (seq=1) ------> 671 (with cookie) 673 <------ ServerHello (seq=1) 674 <------ Certificate (seq=2) 675 <------ ServerHelloDone (seq=3) 677 [Rest of handshake] 679 Note, however, that from the perspective of the DTLS record 680 layer, the retransmission is a new record. This record will 681 have a new DTLSPlaintext.sequence_number value. 683 DTLS implementations maintain (at least notionally) a 684 next_receive_seq counter. This counter is initially set to 685 zero. When a message is received, if its sequence number 686 matches next_receive_seq, next_receive_seq is incremented and 687 the message is processed. If the sequence number is less than 688 next_receive_seq the message MUST be discarded. If the 689 sequence number is greater than next_receive_seq, the 690 implementation SHOULD queue the message but MAY discard it. 691 (This is a simple space/bandwidth tradeoff). 693 4.2.3. Message Fragmentation and Reassembly 695 As noted in Section 4.1.1., each DTLS message MUST fit within 696 a single transport layer datagram. However, handshake messages 697 are potentially bigger than the maximum record size. Therefore 698 DTLS provides a mechanism for fragmenting a handshake message 699 over a number of records. 701 When transmitting the handshake message, the sender divides 702 the message into a series of N contiguous data ranges. These 703 range MUST NOT be larger than the maximum handshake fragment 704 size and MUST jointly contain the entire handshake message. 705 The ranges SHOULD NOT overlap. The sender then creates N 706 handshake messages, all with the same message_seq value as the 707 original handshake message. Each new message is labelled with 708 the fragment_offset (the number of bytes contained in previous 709 fragments) and the fragment_length (the length of this 710 fragment). The length field in all messages is the same as the 711 length field of the original message. An unfragmented message 712 is a degenerate case with fragment_offset=0 and 713 fragment_length=length. 715 When a DTLS implementation receives a handshake message 716 fragment, it MUST buffer it until it has the entire handshake 717 message. DTLS implementations MUST be able to handle 718 overlapping fragment ranges. This allows senders to retransmit 719 handshake messages with smaller fragment sizes during path MTU 720 discovery. 722 Note that as with TLS, multiple handshake messages may be 723 placed in the same DTLS record, provided that there is room 724 and that they are part of the same flight. Thus, there are two 725 acceptable ways to pack two DTLS messages into the same 726 datagram: in the same record or in separate records. 728 4.2.4. Timeout and Retransmission 730 DTLS messages are grouped into a series of message flights, 731 according the diagrams below. Although each flight of messages 732 may consist of a number of messages, they should be viewed as 733 monolithic for the purpose of timeout and retransmission. 735 Client Server 736 ------ ------ 738 ClientHello --------> Flight 1 740 <------- HelloVerifyRequest Flight 2 742 ClientHello --------> Flight 3 744 ServerHello \ 745 Certificate* \ 746 ServerKeyExchange* Flight 4 747 CertificateRequest* / 748 <-------- ServerHelloDone / 750 Certificate* \ 751 ClientKeyExchange \ 752 CertificateVerify* Flight 5 753 [ChangeCipherSpec] / 754 Finished --------> / 756 [ChangeCipherSpec] \ Flight 6 757 <-------- Finished / 758 Figure 1: Message flights for full handshake 760 Client Server 761 ------ ------ 763 ClientHello --------> Flight 1 765 ServerHello \ 766 [ChangeCipherSpec] Flight 2 767 <-------- Finished / 769 [ChangeCipherSpec] \Flight 3 770 Finished --------> / 771 Figure 2: Message flights for session resuming handshake (no 772 cookie exchange) 774 DTLS uses a simple timeout and retransmission scheme with the 775 following state machine. Because DTLS clients send the first 776 message (ClientHello) they start in the PREPARING state. DTLS 777 servers start in the WAITING state, but with empty buffers and 778 no retransmit timer. 780 +-----------+ 781 | PREPARING | 782 +---> | | <--------------------+ 783 | | | | 784 | +-----------+ | 785 | | | 786 | | | 787 | | Buffer next flight | 788 | | | 789 | \|/ | 790 | +-----------+ | 791 | | | | 792 | | SENDING |<------------------+ | 793 | | | | | Send 794 | +-----------+ | | HelloRequest 795 Receive | | | | 796 next | | Send flight | | or 797 flight | +--------+ | | 798 | | | Set retransmit timer | | Receive 799 | | \|/ | | HelloRequest 800 | | +-----------+ | | Send 801 | | | | | | ClientHello 802 +--)--| WAITING |-------------------+ | 803 | | | | Timer expires | | 804 | | +-----------+ | | 805 | | | | | 806 | | | | | 807 | | +------------------------+ | 808 | | Read retransmit | 809 Receive | | | 810 last | | | 811 flight | | | 812 | | | 813 \|/\|/ | 814 | 815 +-----------+ | 816 | | | 817 | FINISHED | -------------------------------+ 818 | | 819 +-----------+ 821 Figure 3: DTLS timeout and retransmission state machine 823 The state machine has three basic states. 825 In the PREPARING state the implementation does whatever 826 computations are necessary to prepare the next flight of 827 messages. It then buffers them up for transmission (emptying 828 the buffer first) and enters the SENDING state. 830 In the SENDING state, the implementation transmits the 831 buffered flight of messages. Once the messages have been sent, 832 the implementation then enters the FINISHED state if this is 833 the last flight in the handshake, or, if the implementation 834 expects to receive more messages, sets a retransmit timer and 835 then enters the WAITING state. 837 There are three ways to exit the WAITING state: 839 1. The retransmit timer expires: the implementation 840 transitions to the SENDING state, where it retransmits the 841 flight, resets the retransmit timer, and returns to the 842 WAITING state. 844 2. The implementation reads a retransmitted flight from the 845 peer: the implementation transitions to the SENDING state, 846 where it retransmits the flight, resets the retransmit 847 timer, and returns to the WAITING state. The rationale here 848 is that the receipt of a duplicate message is the likely 849 result of timer expiry on the peer and therefore suggests 850 that part of one's previous flight was lost. 852 3. The implementation receives the next flight of messages: 853 if this is the final flight of messages the implementation 854 transitions to FINISHED. If the implementation needs to 855 send a new flight, it transitions to the PREPARING state. 856 Partial reads (whether partial messages or only some of the 857 messages in the flight) do not cause state transitions or 858 timer resets. 860 Because DTLS clients send the first message (ClientHello) they 861 start in the PREPARING state. DTLS servers start in the 862 WAITING state, but with empty buffers and no retransmit timer. 864 When the server desires a rehandshake, it transitions from the 865 FINISHED state to the PREPARING state to transmit the 866 HelloRequest. When the client receives a HelloRequest it 867 transitions from FINISHED to PREPARING to transmit the 868 ClientHello. 870 4.2.4.1. Timer Values 872 Though timer value choices are the choice of the 873 implementation, mishandling of the timer can lead to serious 874 congestion problems, for example if many instances of a DTLS 875 time out early and retransmit too quickly on a congested link. 876 Implementations SHOULD use an initial timer value of 1 second 877 (the minimum defined in RFC 2988 [RFC2988]) and double the 878 value at each retransmission, up to no less than the the RFC 879 2988 maximum of 60 seconds. Note that we recommend a 1 second 880 timer rather than the 3 second RFC 2988 default in order to 881 improve latency for time-sensitive applications. Because DTLS 882 only uses retransmission for handshake and not dataflow, the 883 effect on congestion should be minimal. 884 Implementations SHOULD retain the current timer value until 885 a transmission without loss occurs, at which time the value 886 may be reset to the initial value. After a long period of 887 idleness, no less than 10 times the current timer value, 888 implementations may reset the timer to the initial value. One 889 situation where this might occur is when a rehandshake is used 890 after substantial data transfer. 892 4.2.5. ChangeCipherSpec 894 As with TLS, the ChangeCipherSpec message is not technically a 895 handshake message but MUST be treated as part of the same 896 flight as the associated Finished message for the purposes of 897 timeout and retransmission. 899 4.2.6. Finished messages 901 Finished messages have the same format as in TLS. However, in 902 order to remove sensitivity to fragmentation, the Finished MAC 903 MUST be computed as if each handshake message had been sent as 904 a single fragment. Note that in cases where the cookie 905 exchange is used, the initial ClientHello and 906 HelloVerifyRequest MUST NOT included in the Finished MAC. 908 4.2.7. Alert Messages 910 Note that Alert messages are not retransmitted at all, even 911 when they occur in the context of a handshake. However, a DTLS 912 implementation SHOULD generate a new alert message if the 913 offending record is received again (e.g., as a retransmitted 914 handshake message). Implementations SHOULD detect when a peer 915 is persistently sending bad messages and terminate the local 916 connection state after such misbehavior is detected. 918 A.1Summary of new syntax 919 This section includes specifications for the data structures 920 that have changed between TLS 1.1 and DTLS. 922 4.2. Record Layer 923 struct { 924 ContentType type; 925 ProtocolVersion version; 926 uint16 epoch; // New field 927 uint48 sequence_number; // New field 928 uint16 length; 929 opaque fragment[DTLSPlaintext.length]; 930 } DTLSPlaintext; 932 struct { 933 ContentType type; 934 ProtocolVersion version; 935 uint16 epoch; // New field 936 uint48 sequence_number; // New field 937 uint16 length; 938 opaque fragment[DTLSCompressed.length]; 939 } DTLSCompressed; 941 struct { 942 ContentType type; 943 ProtocolVersion version; 944 uint16 epoch; // New field 945 uint48 sequence_number; // New field 946 uint16 length; 947 select (CipherSpec.cipher_type) { 948 case block: GenericBlockCipher; 949 } fragment; 950 } DTLSCiphertext; 952 4.3. Handshake Protocol 954 enum { 955 hello_request(0), client_hello(1), server_hello(2), 956 hello_verify_request(3), // New field 957 certificate(11), server_key_exchange (12), 958 certificate_request(13), server_hello_done(14), 959 certificate_verify(15), client_key_exchange(16), 960 finished(20), (255) 961 } HandshakeType; 963 struct { 964 HandshakeType msg_type; 965 uint24 length; 966 uint16 message_seq; // New field 967 uint24 fragment_offset; // New field 968 uint24 fragment_length; // New field 969 select (HandshakeType) { 970 case hello_request: HelloRequest; 971 case client_hello: ClientHello; 972 case server_hello: ServerHello; 973 case hello_verify_request: HelloVerifyRequest; // New field 974 case certificate:Certificate; 975 case server_key_exchange: ServerKeyExchange; 976 case certificate_request: CertificateRequest; 977 case server_hello_done:ServerHelloDone; 978 case certificate_verify: CertificateVerify; 979 case client_key_exchange: ClientKeyExchange; 980 case finished:Finished; 981 } body; 982 } Handshake; 984 struct { 985 ProtocolVersion client_version; 986 Random random; 987 SessionID session_id; 988 opaque cookie<0..32>; // New field 989 CipherSuite cipher_suites<2..2^16-1>; 990 CompressionMethod compression_methods<1..2^8-1>; 991 } ClientHello; 993 struct { 994 opaque cookie<0..32>; 995 } HelloVerifyRequest; 997 5. Security Considerations 999 This document describes a variant of TLS 1.1 and therefore 1000 most of the security considerations are the same as those of 1001 TLS 1.1 [TLS11], described in Appendices D, E, and F. 1003 The primary additional security consideration raised by DTLS 1004 is that of denial of service. DTLS includes a cookie exchange 1005 designed to protect against denial of service. However, 1006 implementations which do not use this cookie exchange are 1007 still vulnerable to DoS. In particular, DTLS servers which do 1008 not use the cookie exchange may be used as attack amplifiers 1009 even if they themselves are not experiencing DoS. Therefore 1010 DTLS servers SHOULD use the cookie exchange unless there is 1011 good reason to believe that amplification is not a threat in 1012 their environment. Clients MUST be prepared to do a cookie 1013 exchange with every handshake. 1015 6. IANA Considerations 1017 This document uses the same identifier space as TLS [TLS11], 1018 so no new IANA registries are required. When new identifiers 1019 are assigned for TLS, authors MUST specify whether they are 1020 suitable for DTLS. 1022 This document defines a new handshake message, 1023 hello_verify_request, whose value is to be allocated from the 1024 TLS HandshakeType registry defined in [TLS11]. The value "3" 1025 is suggested. 1027 References 1029 Normative References 1031 [RFC1191] Mogul, J. C., Deering, S.E., "Path MTU Discovery", 1032 RFC 1191, November 1990. 1034 [RFC1981] J. McCann, S. Deering, J. Mogul, "Path MTU Discovery 1035 for IP version 6", RFC1981, August 1996. 1037 [RFC2401] Kent, S., Atkinson, R., "Security Architecture for the 1038 Internet Protocol", RFC2401, November 1998. 1040 [RFC2988] Paxson, V., Allman, M., "Computing TCP's Retransmission 1041 Timer", RFC 2988, November 2000. 1043 [TCP] Postel, J., "Transmission Control Protocol", 1044 RFC 793, September 1981. 1046 [TLS11] Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1", 1047 draft-ietf-tls-rfc2246-bis-05.txt, July 2003. 1049 Informative References 1051 [AESCACHE] Bernstein, D.J., "Cache-timing attacks on AES" 1052 http://cr.yp.to/antiforgery/cachetiming-20050414.pdf. 1054 [AH] Kent, S., and Atkinson, R., "IP Authentication Header", 1055 RFC 2402, November 1998. 1057 [DCCP] Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram 1058 Congestion Control Protocol", draft-ietf-dccp-spec-11.txt, 1059 10 March 2005 1061 [DNS] Mockapetris, P.V., "Domain names - implementation and 1062 specification", RFC 1035, November 1987. 1064 [DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation 1065 of Datagram TLS", Proceedings of ISOC NDSS 2004, February 2004. 1067 [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security 1068 Payload (ESP)", RFC 2406, November 1998. 1070 [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", 1071 RFC 2409, November 1998. 1073 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1074 draft-ietf-ipsec-ikev2-17.txt, September 2004. 1076 [IMAP] Crispin, M., "Internet Message Access Protocol - Version 1077 4rev1", RFC 3501, March 2003. 1079 [PHOTURIS] Karn, P., Simpson, W., "Photuris: Session-Key Management 1080 Protocol", RFC 2521, March 1999. 1082 [POP] Myers, J., and Rose, M., "Post Office Protocol - 1083 Version 3", RFC 1939, May 1996. 1085 [REQ] Bradner, S., "Key words for use in RFCs to Indicate 1086 Requirement Levels", BCP 14, RFC 2119, March 1997. 1088 [SCTP] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, 1089 T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson, 1090 Stream Control Transmission Protocol", RFC 2960, 1091 October 2000. 1093 [SIP] Rosenberg, J., Schulzrinne, Camarillo, G., Johnston, A., 1094 Peterson, J., Sparks, R., Handley, M., Schooler, E., 1095 "SIP: Session Initiation Protocol", RFC 3261, 1096 June 2002. 1098 [TLS] Dierks, T., and Allen, C., "The TLS Protocol Version 1.0", 1099 RFC 2246, January 1999. 1101 [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", 1102 draft-bellovin-useipsec-02.txt, October 2003 1104 Authors' Address 1105 Eric Rescorla 1106 RTFM, Inc. 1107 2064 Edgewood Drive 1108 Palo Alto, CA 94303 1110 Nagendra Modadugu 1111 Computer Science Department 1112 353 Serra Mall 1113 Stanford University 1114 Stanford, CA 94305 1116 Acknowledgements 1118 The authors would like to thank Dan Boneh, Eu-Jin Goh, Russ 1119 Housley, Constantine Sapuntzakis, and Hovav Shacham for 1120 discussions and comments on the design of DTLS. Thanks to the 1121 anonymous NDSS reviewers of our original NDSS paper on DTLS 1122 [DTLS] for their comments. Also, thanks to Steve Kent for 1123 feedback that helped clarify many points. The section on PMTU 1124 was cribbed from the DCCP specification [DCCP]. Pasi Eronen 1125 provided a detailed review of this specification. Helpful 1126 comments on the document were also received from Mark Allman, 1127 Jari Arkko, Joel Halpern, Ted Hardie and Allison Mankin. 1129 Full Copyright Statement 1131 The IETF takes no position regarding the validity or scope of any 1132 Intellectual Property Rights or other rights that might be claimed to 1133 pertain to the implementation or use of the technology described in 1134 this document or the extent to which any license under such rights 1135 might or might not be available; nor does it represent that it has 1136 made any independent effort to identify any such rights. Information 1137 on the procedures with respect to rights in RFC documents can be 1138 found in BCP 78 and BCP 79. 1140 Copies of IPR disclosures made to the IETF Secretariat and any 1141 assurances of licenses to be made available, or the result of an 1142 attempt made to obtain a general license or permission for the use of 1143 such proprietary rights by implementers or users of this 1144 specification can be obtained from the IETF on-line IPR repository at 1145 http://www.ietf.org/ipr. 1147 The IETF invites any interested party to bring to its attention any 1148 copyrights, patents or patent applications, or other proprietary 1149 rights that may cover technology that may be required to implement 1150 this standard. Please address the information to the IETF at ietf- 1151 ipr@ietf.org. 1153 Copyright Notice 1154 Copyright (C) The Internet Society (2003). This document is subject 1155 to the rights, licenses and restrictions contained in BCP 78, and 1156 except as set forth therein, the authors retain all their rights. 1158 This document and the information contained herein are provided on an 1159 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1160 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1161 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1162 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1163 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1164 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.