idnits 2.17.00 (12 Aug 2021) /tmp/idnits24915/draft-rescorla-dtls-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 13 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 253: '... tions MUST NOT allow the same epoch...' RFC 2119 keyword, line 260: '...Each DTLS record MUST fit within a sin...' RFC 2119 keyword, line 261: '... IP fragmentation [MOGUL], DTLS implementations SHOULD determine the...' RFC 2119 keyword, line 263: '... SHOULD provide a way for applicatio...' RFC 2119 keyword, line 266: '... the MTU, the DTLS implementation MUST...' (31 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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: 'REF' is mentioned on line 47, but not defined == Missing Reference: 'MOGUL' is mentioned on line 261, but not defined == Missing Reference: 'RFC 1191' is mentioned on line 285, but not defined == Missing Reference: 'RFC 2402' is mentioned on line 328, but not defined ** Obsolete undefined reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) == Missing Reference: 'RFC 2401' is mentioned on line 353, but not defined ** Obsolete undefined reference: RFC 2401 (Obsoleted by RFC 4301) == Missing Reference: 'ChangeCipherSpec' is mentioned on line 581, but not defined == Unused Reference: 'RFC1191' is defined on line 782, but no explicit reference was found in the text == Unused Reference: 'AH' is defined on line 793, but no explicit reference was found in the text == Unused Reference: 'TCP' is defined on line 821, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 2521 (ref. 'PHOTURIS') ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) == 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) -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) == Outdated reference: draft-bellovin-useipsec has been published as RFC 5406 Summary: 15 errors (**), 0 flaws (~~), 13 warnings (==), 6 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 January 2004 (Expires July 2004) 7 Datagram Transport Layer Security 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference mate- 20 rial or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 This document specifies Version 1.0 of the Datagram Transport Layer 31 Security (DTLS) protocol. The DTLS protocol provides communications 32 privacy for datagram protocols. The protocol allows client/server 33 applications to communicate in a way that is designed to prevent 34 eavesdropping, tampering, or message forgery. The DTLS protocol is 35 based on the TLS protocol and provides equivalent privacy guarantees. 36 Datagram semantics of the underlying transport are preserved by the 37 DTLS protocol. 39 1. Introduction 41 TLS [TLS] is the most widely deployed protocol for securing network 42 traffic. It is widely used for protecting Web traffic and for e-mail 43 protocols such as IMAP [IMAP] and POP [POP]. The primary advantage of 44 TLS is that it provides a transparent channel. Thus, it is easy to 45 secure an application protocol by inserting TLS between the applica- 46 tion layer and the network layer. However, TLS must run over a reli- 47 able transport channel--typically TCP [REF]. It therefore cannot be 48 used to secure unreliable datagram traffic. 50 However, over the past few years an increasing number of application 51 layer protocols have been designed using UDP transport. In particular 52 such protocols as the Session Initiation Protocol (SIP) [SIP], and 53 electronic gaming protocols are increasingly popular. Currently, 54 designers these applications are faced with a number of unsatisfac- 55 tory choices. First, they can use IPsec. However, for a number of 56 reasons detailed in [WHYIPSEC], this is only suitable for some appli- 57 cations. Second, they can design a custom application layer security 58 protocol. SIP, for instance, uses a variant of S/MIME to secure its 59 traffic. Unfortunately, application layer security protocols typi- 60 cally require a large amount of effort to design--by contrast to the 61 relatively small amount of effort required to run the protocol over 62 TLS. 64 In many cases, the most desirable way to secure client/server appli- 65 cations would be to use TLS, however the requirement for datagram 66 semantics automatically prohibits use of TLS. Thus, a datagram-com- 67 patible variant of TLS would be very desirable. This memo describes 68 such a protocol: Datagram Transport Layer Security (DTLS). DTLS is 69 deliberately designed to be as similar to to TLS as possible, both to 70 minimize new security invention and to maximize the amount of code 71 and infrastructure reuse. 73 2. Usage Model 75 The DTLS protocol is designed to secure data between communicating 76 applications. It is designed to run in application space, without 77 requiring any kernel modifications. While the design of the DTLS pro- 78 tocol does not preclude its use in securing arbitrary datagram traf- 79 fic, it is primarily expected to secure communication based on data- 80 gram sockets. 82 Datagram transport does not guarantee reliable or in-order delivery 83 of data. The DTLS protocol preserves this property for payload data. 84 Applications such as media streaming, Internet telephony and online 85 gaming use datagram transport for communication due to the delay-sen- 86 sitive nature of transported data. The behaviour of such applications 87 is unchanged when the DTLS protocol is used to secure communication, 88 since the DTLS protocol does not compensate for lost or re-ordered 89 data traffic. 91 3. Overview of DTLS 93 The basic design philosophy of DTLS is to construct "TLS over data- 94 gram". The reason that TLS cannot be used directly in datagram envi- 95 ronments is simply that packets may be lost or reordered. TLS has no 96 internal facilities to handle this kind of unreliability and there- 97 fore TLS implementations break when rehosted on datagram transport. 98 The purpose of DTLS is to make only the minimal changes to TLS 99 required to fix this problem. To the greatest extent possible, DTLS 100 is identical to TLS. Whenever we need to invent new mechanisms, we 101 attempt to do so in such a way that it preserves the style of TLS. 103 Unreliability creates problems for TLS at two levels: 105 1. TLS's traffic encryption layer does not allow independent 106 decryption of individual records. If record N is not received, 107 then record N+1 cannot be decrypted. 109 2. The TLS handshake layer assumes that handshake messages are 110 delivered reliably and breaks if those messages are lost. 112 The rest of this section describes the approach that DTLS uses to 113 solve these problems. 115 3.1. Loss-insensitive messaging 117 In TLS's traffic encryption layer (called the TLS Record Layer), 118 records are not independent. There are two kinds of inter-record 119 dependency: 121 1. Cryptographic context (CBC state, stream cipher key stream) is 122 chained between records. 124 2. Anti-replay and message reordering protection are provided by a 125 MAC which includes a sequence number, but the sequence numbers are 126 implicit in the records. 128 The fix for both of these problems is straightforward and well-known 129 from IPsec ESP [ESP]: add explicit state to the records. TLS 1.1 130 [TLS11] is already adding explicit CBC state to TLS records. DTLS 131 borrows that mechanism and adds explicit sequence numbers. 133 3.2. Providing Reliability for Handshake 135 The TLS handshake is a lockstep cryptographic handshake. Messages 136 must be transmitted and received in a defined order and any other 137 order is an error. Clearly, this is incompatible with reordering and 138 message loss. In addition, TLS handshake messages are potentially 139 larger than any given datagram, thus creating the problem of fragmen- 140 tation. DTLS must provide fixes for both these problems. 142 3.2.1. Packet Loss 144 DTLS uses a simple retransmission timer to handle packet loss. The 145 following figure demonstrates the basic concept using the first phase 146 of the DTLS handshake: 148 Client Server 149 ------ ------ 150 ClientHello ------> 152 X<-- HelloVerifyRequest 153 (lost) 155 [Timer Expires] 157 ClientHello ------> 158 (retransmit) 160 Once the client has transmitted the ClientHello message, it expects 161 to see a HelloVerifyRequest from the server. However, if the server's 162 message is lost the client knows that either the ClientHello or the 163 HelloVerifyRequest has been lost and retransmits. When the server 164 receives the retransmission, it knows to retransmit. The server also 165 maintains a retransmission timer and retransmits when that timer 166 expires. 168 3.2.2. Reordering 170 In DTLS, each handshake message is assigned a specific sequence num- 171 ber within that handshake. When a peer receives a handshake message, 172 it can quickly determine whether that message is the next message it 173 expects. If it is, then it processes it. If not, it queues it up for 174 future handling once all previous messages have been received. 176 3.3. Message Size 178 TLS and DTLS handshake messages can be quite large (in theory up to 179 2^24-1 bytes, in practice many kilobytes). By contrast, UDP datagrams 180 are often limited to <1500 bytes. In order to compensate for this 181 limitation, each DTLS handshake message may be fragmented over sev- 182 eral DTLS records. Each DTLS handshake message contains both a frag- 183 ment offset and a fragment length. Thus, a recipient in possession of 184 all bytes of a handshake message can reassemble the original unfrag- 185 mented message. 186 DTLS optionally supports record replay detection. The technique used 187 is the same as in IPsec, by maintaining a bitmap window of received 188 records. Records that are too old to fit in the window and records 189 that have been previously received are silently discarded. The replay 190 detection feature is optional, since packet duplication is not always 191 malicious, but can also occur due to routing errors. Applications may 192 conceivably detect duplicate packets and accordingly modify their 193 data transmission strategy. 195 4. Differences from TLS 197 As mentioned in Section 3., DTLS is intentionally very similar to 198 TLS. Therefore, instead of presenting DTLS as a new protocol, we 199 instead present it as a series of deltas from TLS 1.1 [TLS11]. Where 200 we do not explicitly call out differences, DTLS is the same as TLS 202 4.1. Record Layer 204 The DTLS record layer is extremely similar to that of TLS 1.1. The 205 only change is the inclusion of an explicit sequence number in the 206 record. This sequence number allows the recipient to correctly verify 207 the TLS MAC. The DTLS record format is shown below: 209 struct { 210 ContentType type; 211 ProtocolVersion version; 212 uint16 epoch; 213 uint48 sequence_number; 214 uint16 length; 215 opaque fragment[DTLSPlaintext.length]; 216 } DTLSPlaintext; 218 type 219 Equivalent to the type field in a TLS 1.1 record. 221 version 222 The version of the protocol being employed. This document 223 describes DTLS Version 1.0, which uses the version { 254, 255 224 }. The version value of 254.255 is the 1's complement of DTLS 225 Version 1.0. The maximal spacing between TLS and DTLS version 226 numbers ensures that records from the two protocols can be 227 easily distinguished. 229 epoch 230 A counter value that is incremented on every cipher state 231 change. 233 sequence_number 234 The sequence number for this record. 236 length 237 Identical to the length field in a TLS 1.1 record. As in TLS 238 1.1, the length should not exceed 2^14. 240 fragment 241 Identical to the fragment field of a TLS 1.1 record. 243 DTLS uses an explicit rather than implicit sequence number, carried 244 in the sequence_number field of the record. As with TLS, the sequence 245 number is set to zero after each ChangeCipherSpec message is sent. 247 If several handshakes are performed in close succession, there might 248 be multiple records on the wire with the same sequence number but 249 from different cipher states. The epoch field allows recipients to 250 distinguish such packets. The epoch number is initially zero and is 251 incremented each time the ChangeCipherSpec messages is sent. In order 252 to ensure that any given sequence/epoch pair is unique, implementa- 253 tions MUST NOT allow the same epoch value to be reused within two 254 times the maximum segment lifetime. In practice, TLS implementations 255 rehandshake rarely and we therefore do not expect this to be a prob- 256 lem. 258 4.1.1. Transport Layer Mapping 260 Each DTLS record MUST fit within a single datagram. In order to avoid 261 IP fragmentation [MOGUL], DTLS implementations SHOULD determine the 262 MTU and send records smaller than the MTU. DTLS implementations 263 SHOULD provide a way for applications to determine the value of the 264 MTU (optimally the maximum application datagram size, which is the 265 PMTU minus the DTLS per-record overhead). If the application attempts 266 to send a record larger than the MTU, the DTLS implementation MUST 267 either generate an error or fragment the packet. 269 4.1.1.1. PMTU Discovery 271 The PMTU SHOULD be initialized from the interface MTU that will be 272 used to send packets. 274 To perform PMTU discovery, the DTLS sender sets the IP Don't Fragment 275 (DF) bit. As specified in [RFC 1191], when a router receives a packet 276 with DF set that is larger than the next link's MTU, it sends an ICMP 277 Destination Unreachable message to the source of the datagram with 278 the Code indicating "fragmentation needed and DF set" (also known as 279 a "Datagram Too Big" message). When a DTLS implementation receives a 280 Datagram Too Big message, it decreases its PMTU to the Next-Hop MTU 281 value given in the ICMP message. If the MTU given in the message is 282 zero, the sender chooses a value for PMTU using the algorithm 283 described in Section 7 of [RFC 1191]. If the MTU given in the message 284 is greater than the current PMTU, the Datagram Too Big message is 285 ignored, as described in [RFC 1191]. (We are aware that this may 286 cause problems for DTLS endpoints behind certain firewalls.) 288 A DTLS implementation may allow the application to occasionally 289 request that PMTU discovery be performed again. This will reset the 290 PMTU to the outgoing interface's MTU. Such requests SHOULD be rate 291 limited, to one per two seconds, for example. 293 Because some firewalls and routers screen out ICMP messages, it is 294 difficult to distinguish packet loss from an overlarge PMTU estimate. 295 In order to allow connections under these circumstances, DTLS imple- 296 mentations MAY choose to back off their PMTU estimate during the 297 retransmit backoff described in Section 4.2.4.. For instance, if a 298 large packet is being sent, after 3 retransmits a sender might choose 299 to fragment the packet. 301 4.1.2. Record payload protection 303 4.1.2.1. MAC 305 The DTLS MAC is the same as that of TLS 1.1. However, rather than 306 using TLS's implicit sequence number, the sequence number used to 307 compute the MAC is the 64-bit value formed by concatenating the epoch 308 and the sequence number in the order they appear on the wire. Note 309 that the DTLS epoch + sequence number is the same length as the TLS 310 sequence number. 312 4.1.2.2. Null or standard stream cipher 314 The DTLS NULL cipher is performed exactly as the TLS 1.1 NULL cipher. 316 The only stream cipher described in TLS 1.1 is RC4, which cannot be 317 randomly accessed. RC4 MUST NOT be used with DTLS. 319 4.1.2.3. Block Cipher 321 DTLS block cipher encryption and decryption are performed exactly as 322 with TLS 1.1. 324 4.1.2.4. Anti-Replay 326 DTLS records contain a sequence number to provide replay protection. 327 Sequence number verification SHOULD be performed using the following 328 sliding, window procedure, borrowed from Section 3.4.3 of [RFC 2402] 330 The receiver packet counter for this session MUST be initialized to 331 zero when the session is established. For each received record, the 332 receiver MUST verify that the record contains a Sequence Number that 333 does not duplicate the Sequence Number of any other record received 334 during the life of this session. This SHOULD be the first check 335 applied to a packet after it has been matched to a session, to speed 336 rejection of duplicate records. 338 Duplicates are rejected through the use of a sliding receive window. 339 (How the window is implemented is a local matter, but the following 340 text describes the functionality that the implementation must 341 exhibit.) A MINIMUM window size of 32 MUST be supported; but a window 342 size of 64 is preferred and SHOULD be employed as the default. 343 Another window size (larger than the MINIMUM) MAY be chosen by the 344 receiver. (The receiver does NOT notify the sender of the window 345 size.) 347 The "right" edge of the window represents the highest, validated 348 Sequence Number value received on this session. Records that contain 349 Sequence Numbers lower than the "left" edge of the window are 350 rejected. Packets falling within the window are checked against a 351 list of received packets within the window. An efficient means for 352 performing this check, based on the use of a bit mask, is described 353 in [RFC 2401]. 355 If the received record falls within the window and is new, or if the 356 packet is to the right of the window, then the receiver proceeds to 357 MAC verification. If the MAC validation fails, the receiver MUST dis- 358 card the received record as invalid. The receive window is updated 359 only if the MAC verification succeeds. 361 4.2. The DTLS Handshake Protocol 363 DTLS uses all of the same handshake messages and flows as TLS, with 364 three principal changes: 366 1. A stateless cookie exchange to prevent denial of service 367 attacks. 369 2. Modifications to the handshake header to handle message loss, 370 reordering and fragmentation. 372 3. Retransmission timers to handle message loss. 374 With these exceptions, the DTLS message formats, flows, and logic are 375 the same as those of TLS 1.1. 377 4.2.1. Denial of Service Countermeasures 379 Datagram security protocols are extremely susceptible to a variety of 380 denial of service (DoS) attacks. Two attacks are of particular con- 381 cern: 383 1. An attacker can consume excessive resources on the server by 384 transmitting a series of handshake initiation requests, causing 385 the server to allocate state and potentially perform expensive 386 cryptographic operations. 388 2. An attacker can use the server as an amplifier by sending con- 389 nection initiation messages with a forged source of the victim. 390 The server then sends its next message (in DTLS, a Certificate 391 message, which can be quite large) to the victim machine, thus 392 flooding it. 394 In order to prevent both of these attacks, DTLS borrows the stateless 395 cookie technique used by Photuris [PHOTURIS] and IKEv2 [IKE]. When 396 the client sends its ClientHello message to the server, the server 397 MAY respond with a HelloVerifyRequest message. This message contains 398 a stateless cookie generated using the technique of [PHOTURIS]. The 399 client MUST retransmit the ClientHello with the cookie added. The 400 server then verifies the cookie and proceeds with the handshake only 401 if it is valid. 403 The exchange is shown below: 405 Client Server 406 ------ ------ 407 ClientHello ------> 409 <----- HelloVerifyRequest 410 (contains cookie) 412 ClientHello ------> 413 (with cookie) 415 [Rest of handshake here] 417 DTLS therefore modifies the ClientHello message to add the cookie 418 value. 420 struct { 421 ProtocolVersion client_version; 422 Random random; 423 SessionID session_id; 424 Cookie cookie<0..32>; // New field 425 CipherSuite cipher_suites<2..2^16-1>; 426 CompressionMethod compression_methods<1..2^8-1>; 427 } ClientHello; 429 The definition of HelloVerifyRequest is as follows: 431 struct { 432 Cookie cookie<0..32>; 433 } HelloVerifyRequest; 435 The HelloVerifyRequest message type is hello_verify_request(3). 437 When responding to a HelloVerifyRequest the client MUST use the same 438 parameter values (version, random, session_id, cipher_suites, com- 439 pression_method) as in the original ClientHello. The server SHOULD 440 use those values to generate its cookie and verify that they are cor- 441 rect. 443 Although DTLS servers are not required to do a cookie exchange, they 444 SHOULD do so whenever a new handshake is performed in order to avoid 445 being used as amplifiers. If the server is being operated in an envi- 446 ronment where amplification is not a problem, the server MAY choose 447 not to perform a cookie exchange. In addition, the server MAY choose 448 not do to a cookie exchange when a session is resumed. Clients MUST 449 be prepared to do a cookie exchange with every handshake. 451 4.2.2. Handshake Message Format 453 In order to support message loss, reordering, and fragmentation DTLS 454 modifies the TLS 1.1 handshake header: 456 struct { 457 HandshakeType msg_type; 458 uint24 length; 459 uint16 message_seq; // New field 460 uint24 fragment_offset; // New field 461 uint24 fragment_length; // New field 462 select (HandshakeType) { 463 case hello_request: HelloRequest; 464 case client_hello: ClientHello; 465 case hello_verify_request: HelloVerifyRequest; // New message type 466 case server_hello: ServerHello; 467 case certificate:Certificate; 468 case server_key_exchange: ServerKeyExchange; 469 case certificate_request: CertificateRequest; 470 case server_hello_done:ServerHelloDone; 471 case certificate_verify: CertificateVerify; 472 case client_key_exchange: ClientKeyExchange; 473 case finished:Finished; 474 } body; 475 } Handshake; 477 The first message each side transmits in each handshake always has 478 message_seq = 0. Whenever each new message is generated, the mes- 479 sage_seq value is incremented by one. When a message is retransmit- 480 ted, the same message_seq value is used. For example. 482 Client Server 483 ------ ------ 484 ClientHello (seq=0) ------> 486 X<-- HelloVerifyRequest (seq=0) 487 (lost) 489 [Timer Expires] 491 ClientHello (seq=0) ------> 492 (retransmit) 494 <------ HelloVerifyRequest (seq=0) 496 ClientHello (seq=1) ------> 497 (with cookie) 499 <------ ServerHello (seq=1) 500 <------ Certificate (seq=2) 501 <------ ServerHelloDone (seq=3) 503 [Rest of handshake] 505 DTLS implementations maintain (at least notionally) a 506 next_receive_seq counter. This counter is initially set to zero. When 507 a message is received, if its sequence number matches 508 next_receive_seq, next_receive_seq is incremented and the message is 509 processed. If the sequence number is less than next_receive_seq the 510 message MUST be discarded. If the sequence number is greater than 511 next_receive_seq, the implementation SHOULD queue the message but MAY 512 discard it. (This is a simple space/bandwidth tradeoff). 514 4.2.3. Message Fragmentation and Reassembly 516 As noted in Section 4.1.1., each DTLS message MUST fit within a sin- 517 gle transport layer datagram. However, handshake messages are poten- 518 tially bigger than the maximum record size. Therefore DTLS provides a 519 mechanism for fragmenting a handshake message over a number of 520 records. 522 When transmitting the handshake message, the sender divides the mes- 523 sage into a series of N contiguous data ranges. These range must be 524 no larger than the maximum handshake fragment size and MUST jointly 525 contain the entire handshake message. The ranges SHOULD NOT overlap. 526 The sender then creates N handshake messages, all with the same mes- 527 sage_seq value as the original handshake message. Each new message is 528 labelled with the fragment_offset (the number of bytes contained in 529 previous fragments) and the fragment_length (the length of this frag- 530 ment). The length field in all messages is the same as the length 531 field of the original message. An unfragmented message is a degener- 532 ate case with fragment_offset=0 and fragment_length=length. 534 When a DTLS implementation receives a handshake message fragment, it 535 MUST buffer it until it has the entire handshake message. DTLS imple- 536 mentations MUST be able to handle overlapping fragment ranges. This 537 allows senders to retransmit handshake messages with smaller fragment 538 sizes during path MTU discovery. 540 4.2.4. Timeout and Retransmission 542 DTLS messages are grouped into a series of message flights, according 543 the diagrams below. Although each flight of messages may consist of a 544 number of messages, they should be viewed as monolithic for the pur- 545 pose of timeout and retransmission. 547 Client Server 548 ------ ------ 550 ClientHello --------> Flight 1 552 <------- HelloVerifyRequest Flight 2 554 ClientHello --------> Flight 3 556 ServerHello \ 557 Certificate* \ 558 ServerKeyExchange* Flight 4 559 CertificateRequest* / 560 <-------- ServerHelloDone / 562 Certificate* \ 563 ClientKeyExchange \ 564 CertificateVerify* Flight 5 565 [ChangeCipherSpec] / 566 Finished --------> / 568 [ChangeCipherSpec] \ Flight 6 569 <-------- Finished / 570 Figure 1: Message flights for full handshake 572 Client Server 573 ------ ------ 575 ClientHello --------> Flight 1 577 ServerHello \ 578 [ChangeCipherSpec] Flight 2 579 <-------- Finished / 581 [ChangeCipherSpec] \Flight 3 582 Finished --------> / 583 Figure 2: Message flights for abbreviated handshake (no cookie exchange) 585 DTLS uses a simple timeout and retransmission scheme with the follow- 586 ing state machine. 588 +--------+ 589 | PREPAR | 590 +---> | -ING | 591 | | | 592 | +--------+ 593 | | 594 | | 595 | | Buffer next flight 596 | | 597 | \|/ 598 | +---------+ 599 | | | 600 | | SENDING |<--------------------+ 601 | | | | 602 | +---------+ | 603 Receive | | | 604 next | | Send flight | 605 flight | +-------+ | 606 | | | Set retransmit timer | 607 | | \|/ | 608 | | +---------+ | 609 | | | | | 610 +--)--| WAITING |---------------------+ 611 | | | | Timer expires | 612 | | +---------+ | 613 | | | | 614 | | | | 615 | | +------------------------+ 616 | | Read retransmit 617 Receive | | 618 last | | 619 flight | | 620 | | 621 \|/\|/ 623 FINISH 624 Figure 3: DTLS timeout and retransmission state machine 626 The state machine has three basic states. 628 In the PREPARING state the implementation does whatever computations 629 are necessary to prepare the next flight of messages. It then buffers 630 them up for transmission (emptying the buffer first) and enters the 631 SENDING state. 633 In the SENDING state, the implementation transmits the buffered 634 flight of messages. Once the messages have been sent, the implementa- 635 tion then enters the FINISH state if this is the last flight in the 636 handshake, or, if the implementation expects to receive more mes- 637 sages, sets a retransmit timer and then enters the WAITING state. 639 There are three ways to exit the WAITING state: 641 1. The retransmit timer expires: the implementation transitions to 642 the SENDING state, where it retransmits the flight, resets the 643 retransmit timer, and returns to the WAITING state. 645 2. The implementation reads a retransmitted flight from the peer: 646 the implementation transitions to the SENDING state, where it 647 retransmits the flight, resets the retransmit timer, and returns 648 to the WAITING state. The rationale here is that the receipt of a 649 duplicate message is the likely result of timer expiry on the peer 650 and therefore suggests that part of one's previous flight was 651 lost. 653 3. The implementation receives the next flight of messages: if 654 this is the final flight of messages the implementation transi- 655 tions to FINISHED. If the implementation needs to send a new 656 flight, it transitions to the PREPARING state. Partial reads 657 (whether partial messages or only some of the messages in the 658 flight) do not cause state transitions or timer resets. 660 Because DTLS clients send the first message (ClientHello) they start 661 in the PREPARING state. DTLS servers start in the WAITING state, but 662 with empty buffers and no retransmit timer. 664 4.2.4.1. Timer Values 666 Timer value choices are a local matter. We recommend that implementa- 667 tions use an initial timer value of 500 ms and double the value at 668 each retransmission, up to 2MSL. Implementations SHOULD start the 669 timer value at the initial value with each new flight of messages. 671 4.2.5. ChangeCipherSpec 673 As with TLS, the ChangeCipherSpec message is not technically a hand- 674 shake message but MUST be treated as part of the same flight as the 675 associated Finished message for the purposes of timeout and retrans- 676 mission. 678 4.2.6. Finished messages 680 Finished messages have the same format as in TLS. However, in order 681 to remove sensitivity to fragmentation, the Finished MAC MUST be com- 682 puted as if each handshake message had been sent as a single frag- 683 ment. Note that in cases where the cookie exchange is used, the ini- 684 tial ClientHello and HelloVerifyRequest ARE included in the Finished 685 MAC. 687 A.1Summary of new syntax 689 This section includes specifications for the data structures that 690 have changed between TLS 1.1 and DTLS. 692 4.2. Record Layer 693 struct { 694 ContentType type; 695 ProtocolVersion version; 696 uint16 epoch; // NEW 697 uint48 sequence_number; // NEW 698 uint16 length; 699 opaque fragment[DTLSPlaintext.length]; 700 } DTLSPlaintext; 702 struct { 703 ContentType type; 704 ProtocolVersion version; 705 uint16 epoch; // NEW 706 uint48 sequence_number; // NEW 707 uint16 length; 708 opaque fragment[DTLSCompressed.length]; 709 } DTLSCompressed; 711 struct { 712 ContentType type; 713 ProtocolVersion version; 714 uint16 epoch; // NEW 715 uint48 sequence_number; // NEW 716 uint16 length; 717 select (CipherSpec.cipher_type) { 718 case stream: GenericStreamCipher; 719 case block: GenericBlockCipher; 720 } fragment; 721 } DTLSCiphertext; 722 4.3. Handshake Protocol 724 enum { 725 hello_request(0), client_hello(1), server_hello(2), 726 hello_verify_request(3), // NEW 727 certificate(11), server_key_exchange (12), 728 certificate_request(13), server_hello_done(14), 729 certificate_verify(15), client_key_exchange(16), 730 finished(20), (255) 731 } HandshakeType; 733 struct { 734 HandshakeType msg_type; 735 uint24 length; 736 uint16 message_seq; // NEW 737 uint24 fragment_offset; // NEW 738 uint24 fragment_length; // NEW 739 select (HandshakeType) { 740 case hello_request: HelloRequest; 741 case client_hello: ClientHello; 742 case server_hello: ServerHello; 743 case hello_verify_request: HelloVerifyRequest; // NEW 744 case certificate:Certificate; 745 case server_key_exchange: ServerKeyExchange; 746 case certificate_request: CertificateRequest; 747 case server_hello_done:ServerHelloDone; 748 case certificate_verify: CertificateVerify; 749 case client_key_exchange: ClientKeyExchange; 750 case finished:Finished; 751 } body; 752 } Handshake; 754 struct { 755 Cookie cookie; 756 } HelloVerifyRequest; 758 5. 760 Security Considerations 762 This document describes a variant of TLS 1.1 and therefore most of 763 the security considerations are the same as TLS 1.1. 765 The primary additional security consideration raised by DTLS is that 766 of denial of service. DTLS includes a cookie exchange designed to 767 protect against denial of service. However, implementations which do 768 not use this cookie exchange are still vulnerable to DoS. In particu- 769 lar, DTLS servers which do not use the cookie exchange may be used as 770 attack amplifiers even if they themselves are not experiencing DoS. 771 Therefore DTLS servers SHOULD use the cookie exchange unless there is 772 good reason to believe that amplification is not a threat in their 773 environment. 775 References 777 Normative References 779 [PHOTURIS] Karn, P., Simpson, W., "Photuris: Session-Key Management 780 Protocol", RFC 2521, March 1999. 782 [RFC1191] Mogul, J. C., Deering, S.E., "Path MTU Discovery", 783 RFC 1191, November 1990. 785 [TLS] Dierks, T., and Allen, C., "The TLS Protocol Version 1.0", 786 RFC 2246, January 1999. 788 [TLS11] Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1", 789 draft-ietf-tls-rfc2246-bis-05.txt, July 2003. 791 Informative References 793 [AH] Kent, S., and Atkinson, R., "IP Authentication Header", 794 RFC 2402, November 1998. 796 [DCCP] Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram 797 Congestion Control Protocol", draft-ietf-dccp-spec-05.txt, 798 October 2003 800 [DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation 801 of Datagram TLS", to appear in Proceedings of ISOC NDSS 2004, 802 February 2004. 804 [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security 805 Payload (ESP)", RFC 2406, November 1998. 807 [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", 808 RFC 2409, November 1998. 810 [IMAP] Crispin, M., "Internet Message Access Protocol - Version 811 4rev1", RFC 3501, March 2003. 813 [POP] Myers, J., and Rose, M., "Post Office Protocol - 814 Version 3", RFC 1939, May 1996. 816 [SIP] Rosenberg, J., Schulzrinne, Camarillo, G., Johnston, A., 817 Peterson, J., Sparks, R., Handley, M., Schooler, E., 818 "SIP: Session Initiation Protocol", RFC 3261, 819 June 2002. 821 [TCP] Postel, J., "Transmission Control Protocol", 822 RFC 793, September 1981. 824 [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", 825 draft-bellovin-useipsec-02.txt, October 2003 827 Authors' Address 829 Eric Rescorla 830 RTFM, Inc. 831 2064 Edgewood Drive 832 Palo Alto, CA 94303 834 Nagendra Modadugu 835 Gates Computer Science 836 Stanford University 837 Stanford, CA 94305 839 Acknowledgements 841 The authors would like to thank Dan Boneh, Eu-Jin Goh, Constantine 842 Sapuntzakis, and Hovav Shacham for discussions and comments on the 843 design of DTLS. Thanks to the anonymous NDSS reviewers of our origi- 844 nal NDSS paper on DTLS [DTLS] for their comments. Also, thanks to 845 Steve Kent for feedback that helped clarify many points. The section 846 on PMTU was cribbed from the DCCP specification [DCCP].