idnits 2.17.00 (12 Aug 2021) /tmp/idnits23478/draft-rescorla-dtls-03.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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 948. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 922. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 929. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 935. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == 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 8 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 274: '... implementations MUST NOT allow the sa...' RFC 2119 keyword, line 281: '...Each DTLS record MUST fit within a sin...' RFC 2119 keyword, line 282: '... IP fragmentation [MOGUL], DTLS implementations SHOULD determine the...' RFC 2119 keyword, line 284: '... SHOULD provide a way for applicatio...' RFC 2119 keyword, line 287: '... the MTU, the DTLS implementation MUST...' (36 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: This document uses the same identifier space as TLS [TLS11], so no IANA registries are required beyond those for TLS. Identifiers MAY NOT be assigned for DTLS that conflict with TLS. When new identifiers are assigned for TLS, authors MUST specify whether they are suitable for DTLS. -- 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 282, but not defined == Missing Reference: 'RFC 1191' is mentioned on line 312, but not defined == Missing Reference: 'RFC 2402' is mentioned on line 363, but not defined ** Obsolete undefined reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) == Missing Reference: 'RFC 2401' is mentioned on line 388, but not defined ** Obsolete undefined reference: RFC 2401 (Obsoleted by RFC 4301) == Missing Reference: 'ChangeCipherSpec' is mentioned on line 625, but not defined == Unused Reference: 'RFC1191' is defined on line 842, but no explicit reference was found in the text == Unused Reference: 'AH' is defined on line 859, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 2521 (ref. 'PHOTURIS') -- Possible downref: Non-RFC (?) normative reference: ref. 'REQ' ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** 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 (==), 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 February 2004 (Expires August 2005) 7 Datagram Transport Layer Security 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than a "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Copyright Notice 33 Copyright (C) The Internet Society (1999-2004). All Rights Reserved. 35 Abstract 37 This document specifies Version 1.0 of the Datagram Transport Layer 38 Security (DTLS) protocol. The DTLS protocol provides communications 39 privacy for datagram protocols. The protocol allows client/server 40 applications to communicate in a way that is designed to prevent 41 eavesdropping, tampering, or message forgery. The DTLS protocol is 42 based on the TLS protocol and provides equivalent security 43 guarantees. Datagram semantics of the underlying transport are 44 preserved by the DTLS protocol. 46 Contents 48 1. Introduction 50 TLS [TLS] is the most widely deployed protocol for securing network 51 traffic. It is widely used for protecting Web traffic and for e-mail 52 protocols such as IMAP [IMAP] and POP [POP]. The primary advantage of 53 TLS is that it provides a transparent connection-oriented channel. 54 Thus, it is easy to secure an application protocol by inserting TLS 55 between the application layer and the transport layer. However, TLS 56 must run over a reliable transport channel--typically TCP [TCP]. It 57 therefore cannot be used to secure unreliable datagram traffic. 59 However, over the past few years an increasing number of application 60 layer protocols have been designed which UDP transport. In particular 61 such protocols as the Session Initiation Protocol (SIP) [SIP], and 62 electronic gaming protocols are increasingly popular. (Note that SIP 63 can run over both TCP and UDP, but that there are situations in which 64 UDP is preferable). Currently, designers of these applications are 65 faced with a number of unsatisfactory choices. First, they can use 66 IPsec [RFC2401]. However, for a number of reasons detailed in 67 [WHYIPSEC], this is only suitable for some applications. Second, they 68 can design a custom application layer security protocol. SIP, for 69 instance, uses a subsert of S/MIME to secure its traffic. 70 Unfortunately, while application layer security protocols generally 71 provide superior security properties (e.g., end-to-end security in 72 the case of S/MIME) it typically require a large amount of effort to 73 design--by contrast to the relatively small amount of effort required 74 to run the protocol over TLS. 76 In many cases, the most desirable way to secure client/server 77 applications would be to use TLS; however the requirement for 78 datagram semantics automatically prohibits use of TLS. Thus, a 79 datagram-compatible variant of TLS would be very desirable. This memo 80 describes such a protocol: Datagram Transport Layer Security (DTLS). 81 DTLS is deliberately designed to be as similar to to TLS as possible, 82 both to minimize new security invention and to maximize the amount of 83 code and infrastructure reuse. 85 1.1. Requirements Terminology 87 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 88 "MAY" that appear in this document are to be interpreted as described 89 in RFC 2119 [REQ]. 91 2. Usage Model 93 The DTLS protocol is designed to secure data between communicating 94 applications. It is designed to run in application space, without 95 requiring any kernel modifications. While the design of the DTLS 96 protocol does not preclude its use in securing arbitrary datagram 97 traffic, it is primarily expected to secure communication based on 98 datagram sockets. 100 Datagram transport does not require or provide reliable or in-order 101 delivery of data. The DTLS protocol preserves this property for 102 payload data. Applications such as media streaming, Internet 103 telephony and online gaming use datagram transport for communication 104 due to the delay-sensitive nature of transported data. The behavior 105 of such applications is unchanged when the DTLS protocol is used to 106 secure communication, since the DTLS protocol does not compensate for 107 lost or re-ordered data traffic. 109 3. Overview of DTLS 111 The basic design philosophy of DTLS is to construct "TLS over 112 datagram". The reason that TLS cannot be used directly in datagram 113 environments is simply that packets may be lost or reordered. TLS has 114 no internal facilities to handle this kind of unreliability and 115 therefore TLS implementations break when rehosted on datagram 116 transport. The purpose of DTLS is to make only the minimal changes to 117 TLS required to fix this problem. To the greatest extent possible, 118 DTLS is identical to TLS. Whenever we need to invent new mechanisms, 119 we attempt to do so in such a way that it preserves the style of TLS. 121 Unreliability creates problems for TLS at two levels: 123 1. TLS's traffic encryption layer does not allow independent 124 decryption of individual records. If record N is not received, 125 then record N+1 cannot be decrypted. 127 2. The TLS handshake layer assumes that handshake messages are 128 delivered reliably and breaks if those messages are lost. 130 The rest of this section describes the approach that DTLS uses to 131 solve these problems. 133 3.1. Loss-insensitive messaging 135 In TLS's traffic encryption layer (called the TLS Record Layer), 136 records are not independent. There are two kinds of inter-record 137 dependency: 139 1. Cryptographic context (CBC state, stream cipher key stream) is 140 chained between records. 142 2. Anti-replay and message reordering protection are provided by a 143 MAC which includes a sequence number, but the sequence numbers are 144 implicit in the records. 146 The fix for both of these problems is straightforward and well-known 147 from IPsec ESP [ESP]: add explicit state to the records. TLS 1.1 148 [TLS11] is already adding explicit CBC state to TLS records. DTLS 149 borrows that mechanism and adds explicit sequence numbers. 151 3.2. Providing Reliability for Handshake 153 The TLS handshake is a lockstep cryptographic handshake. Messages 154 must be transmitted and received in a defined order and any other 155 order is an error. Clearly, this is incompatible with reordering and 156 message loss. In addition, TLS handshake messages are potentially 157 larger than any given datagram, thus creating the problem of 158 fragmentation. DTLS must provide fixes for both these problems. 160 3.2.1. Packet Loss 162 DTLS uses a simple retransmission timer to handle packet loss. The 163 following figure demonstrates the basic concept using the first phase 164 of the DTLS handshake: 166 Client Server 167 ------ ------ 168 ClientHello ------> 170 X<-- HelloVerifyRequest 171 (lost) 173 [Timer Expires] 174 ClientHello ------> 175 (retransmit) 177 Once the client has transmitted the ClientHello message, it expects 178 to see a HelloVerifyRequest from the server. However, if the server's 179 message is lost the client knows that either the ClientHello or the 180 HelloVerifyRequest has been lost and retransmits. When the server 181 receives the retransmission, it knows to retransmit. The server also 182 maintains a retransmission timer and retransmits when that timer 183 expires. 185 3.2.2. Reordering 187 In DTLS, each handshake message is assigned a specific sequence 188 number within that handshake. When a peer receives a handshake 189 message, it can quickly determine whether that message is the next 190 message it expects. If it is, then it processes it. If not, it queues 191 it up for future handling once all previous messages have been 192 received. 194 3.2.3. Message Size 196 TLS and DTLS handshake messages can be quite large (in theory up to 197 2^24-1 bytes, in practice many kilobytes). By contrast, UDP datagrams 198 are often limited to <1500 bytes. In order to compensate for this 199 limitation, each DTLS handshake message may be fragmented over 200 several DTLS records. Each DTLS handshake message contains both a 201 fragment offset and a fragment length. Thus, a recipient in 202 possession of all bytes of a handshake message can reassemble the 203 original unfragmented message. 205 3.3. Replay Detection 207 DTLS optionally supports record replay detection. The technique used 208 is the same as in IPsec AH/ESP, by maintaining a bitmap window of 209 received records. Records that are too old to fit in the window and 210 records that have been previously received are silently discarded. 211 The replay detection feature is optional, since packet duplication is 212 not always malicious, but can also occur due to routing errors. 213 Applications may conceivably detect duplicate packets and accordingly 214 modify their data transmission strategy. 216 4. Differences from TLS 218 As mentioned in Section 3., DTLS is intentionally very similar to 219 TLS. Therefore, instead of presenting DTLS as a new protocol, we 220 instead present it as a series of deltas from TLS 1.1 [TLS11]. Where 221 we do not explicitly call out differences, DTLS is the same as TLS. 223 4.1. Record Layer 225 The DTLS record layer is extremely similar to that of TLS 1.1. The 226 only change is the inclusion of an explicit sequence number in the 227 record. This sequence number allows the recipient to correctly verify 228 the TLS MAC. The DTLS record format is shown below: 230 struct { 231 ContentType type; 232 ProtocolVersion version; 233 uint16 epoch; // New field 234 uint48 sequence_number; // New field 235 uint16 length; 236 opaque fragment[DTLSPlaintext.length]; 237 } DTLSPlaintext; 239 type 240 Equivalent to the type field in a TLS 1.1 record. 242 version 243 The version of the protocol being employed. This document 244 describes DTLS Version 1.0, which uses the version { 254, 255 245 }. The version value of 254.255 is the 1's complement of DTLS 246 Version 1.0. This maximal spacing between TLS and DTLS version 247 numbers ensures that records from the two protocols can be 248 easily distinguished. 250 epoch 251 A counter value that is incremented on every cipher state 252 change. 254 sequence_number 255 The sequence number for this record. 257 length 258 Identical to the length field in a TLS 1.1 record. As in TLS 259 1.1, the length should not exceed 2^14. 261 fragment 262 Identical to the fragment field of a TLS 1.1 record. 264 DTLS uses an explicit rather than implicit sequence number, carried 265 in the sequence_number field of the record. As with TLS, the sequence 266 number is set to zero after each ChangeCipherSpec message is sent. 268 If several handshakes are performed in close succession, there might 269 be multiple records on the wire with the same sequence number but 270 from different cipher states. The epoch field allows recipients to 271 distinguish such packets. The epoch number is initially zero and is 272 incremented each time the ChangeCipherSpec messages is sent. In order 273 to ensure that any given sequence/epoch pair is unique, 274 implementations MUST NOT allow the same epoch value to be reused 275 within two times the maximum segment lifetime. In practice, TLS 276 implementations rehandshake rarely and we therefore do not expect 277 this to be a problem. 279 4.1.1. Transport Layer Mapping 281 Each DTLS record MUST fit within a single datagram. In order to avoid 282 IP fragmentation [MOGUL], DTLS implementations SHOULD determine the 283 MTU and send records smaller than the MTU. DTLS implementations 284 SHOULD provide a way for applications to determine the value of the 285 MTU (optimally the maximum application datagram size, which is the 286 PMTU minus the DTLS per-record overhead). If the application attempts 287 to send a record larger than the MTU, the DTLS implementation MUST 288 either generate an error or fragment the packet. 290 Multiple DTLS records may be placed in a single datagram. They are 291 simply encoded consecutively. The DTLS record framing is sufficient 292 to determine the boundaries. Note, however, that the first byte of 293 the datagram payload must be the beginning of a record. Records may 294 not span datagrams. 296 4.1.1.1. PMTU Discovery 298 The PMTU SHOULD be initialized from the interface MTU that will be 299 used to send packets. 301 To perform PMTU discovery, the DTLS sender sets the IP Don't Fragment 302 (DF) bit. As specified in [RFC 1191], when a router receives a packet 303 with DF set that is larger than the next link's MTU, it sends an ICMP 304 Destination Unreachable message to the source of the datagram with 305 the Code indicating "fragmentation needed and DF set" (also known as 306 a "Datagram Too Big" message). When a DTLS implementation receives a 307 Datagram Too Big message, it decreases its PMTU to the Next-Hop MTU 308 value given in the ICMP message. If the MTU given in the message is 309 zero, the sender chooses a value for PMTU using the algorithm 310 described in Section 7 of [RFC 1191]. If the MTU given in the message 311 is greater than the current PMTU, the Datagram Too Big message is 312 ignored, as described in [RFC 1191]. 314 A DTLS implementation may allow the application to occasionally 315 request that PMTU discovery be performed again. This will reset the 316 PMTU to the outgoing interface's MTU. Such requests SHOULD be rate 317 limited, to one per two seconds, for example. 319 Because some firewalls and routers screen out ICMP messages, it is 320 difficult to distinguish packet loss from a large PMTU estimate. In 321 order to allow connections under these circumstances, DTLS 322 implementations MAY choose to back off their PMTU estimate during the 323 retransmit backoff described in Section 4.2.4.. For instance, if a 324 large packet is being sent, after 3 retransmits a sender might choose 325 to fragment the packet. 327 4.1.2. Record payload protection 329 Like TLS, DTLS transmits data as a series of protected records. The 330 rest of this section describes the details of that format. 332 4.1.2.1. MAC 334 The DTLS MAC is the same as that of TLS 1.1. However, rather than 335 using TLS's implicit sequence number, the sequence number used to 336 compute the MAC is the 64-bit value formed by concatenating the epoch 337 and the sequence number in the order they appear on the wire. Note 338 that the DTLS epoch + sequence number is the same length as the TLS 339 sequence number. 341 4.1.2.2. Null or standard stream cipher 343 The DTLS NULL cipher is performed exactly as the TLS 1.1 NULL cipher. 345 The only stream cipher described in TLS 1.1 is RC4, which cannot be 346 randomly accessed. RC4 MUST NOT be used with DTLS. 348 4.1.2.3. Block Cipher 350 DTLS block cipher encryption and decryption are performed exactly as 351 with TLS 1.1. 353 4.1.2.4. New Cipher Suites 355 Upon registration, new TLS cipher suites MUST indicate whether they 356 are suitable for DTLS usage and what, if any, adaptations must be 357 made. 359 4.1.2.5. Anti-Replay 361 DTLS records contain a sequence number to provide replay protection. 362 Sequence number verification SHOULD be performed using the following 363 sliding, window procedure, borrowed from Section 3.4.3 of [RFC 2402] 365 The receiver packet counter for this session MUST be initialized to 366 zero when the session is established. For each received record, the 367 receiver MUST verify that the record contains a Sequence Number that 368 does not duplicate the Sequence Number of any other record received 369 during the life of this session. This SHOULD be the first check 370 applied to a packet after it has been matched to a session, to speed 371 rejection of duplicate records. 373 Duplicates are rejected through the use of a sliding receive window. 374 (How the window is implemented is a local matter, but the following 375 text describes the functionality that the implementation must 376 exhibit.) A minimum window size of 32 MUST be supported; but a window 377 size of 64 is preferred and SHOULD be employed as the default. 378 Another window size (larger than the minimum) MAY be chosen by the 379 receiver. (The receiver does not notify the sender of the window 380 size.) 382 The "right" edge of the window represents the highest, validated 383 Sequence Number value received on this session. Records that contain 384 Sequence Numbers lower than the "left" edge of the window are 385 rejected. Packets falling within the window are checked against a 386 list of received packets within the window. An efficient means for 387 performing this check, based on the use of a bit mask, is described 388 in Appendix C of [RFC 2401]. 390 If the received record falls within the window and is new, or if the 391 packet is to the right of the window, then the receiver proceeds to 392 MAC verification. If the MAC validation fails, the receiver MUST 393 discard the received record as invalid. The receive window is updated 394 only if the MAC verification succeeds. 396 4.2. The DTLS Handshake Protocol 398 DTLS uses all of the same handshake messages and flows as TLS, with 399 three principal changes: 401 1. A stateless cookie exchange has been added to prevent denial of 402 service attacks. 404 2. Modifications to the handshake header to handle message loss, 405 reordering and fragmentation. 407 3. Retransmission timers to handle message loss. 409 With these exceptions, the DTLS message formats, flows, and logic are 410 the same as those of TLS 1.1. 412 4.2.1. Denial of Service Countermeasures 414 Datagram security protocols are extremely susceptible to a variety of 415 denial of service (DoS) attacks. Two attacks are of particular 416 concern: 418 1. An attacker can consume excessive resources on the server by 419 transmitting a series of handshake initiation requests, causing 420 the server to allocate state and potentially perform expensive 421 cryptographic operations. 423 2. An attacker can use the server as an amplifier by sending 424 connection initiation messages with a forged source of the victim. 425 The server then sends its next message (in DTLS, a Certificate 426 message, which can be quite large) to the victim machine, thus 427 flooding it. 429 In order to prevent both of these attacks, DTLS borrows the stateless 430 cookie technique used by Photuris [PHOTURIS] and IKEv2 [IKE]. When 431 the client sends its ClientHello message to the server, the server 432 MAY respond with a HelloVerifyRequest message. This message contains 433 a stateless cookie generated using the technique of [PHOTURIS]. The 434 client MUST retransmit the ClientHello with the cookie added. The 435 server then verifies the cookie and proceeds with the handshake only 436 if it is valid. 438 The exchange is shown below: 440 Client Server 441 ------ ------ 442 ClientHello ------> 444 <----- HelloVerifyRequest 445 (contains cookie) 447 ClientHello ------> 448 (with cookie) 450 [Rest of handshake] 452 DTLS therefore modifies the ClientHello message to add the cookie 453 value. 455 struct { 456 ProtocolVersion client_version; 457 Random random; 458 SessionID session_id; 459 Cookie cookie<0..32>; // New field 460 CipherSuite cipher_suites<2..2^16-1>; 461 CompressionMethod compression_methods<1..2^8-1>; 462 } ClientHello; 464 If the client does not have a cookie for a given server, it should 465 use a zero-length cookie. 467 The definition of HelloVerifyRequest is as follows: 469 struct { 470 Cookie cookie<0..32>; 471 } HelloVerifyRequest; 473 The HelloVerifyRequest message type is hello_verify_request(3). 475 When responding to a HelloVerifyRequest the client MUST use the same 476 parameter values (version, random, session_id, cipher_suites, 477 compression_method) as in the original ClientHello. The server SHOULD 478 use those values to generate its cookie and verify that they are 479 correct upon cookie receipt. 481 Although DTLS servers are not required to do a cookie exchange, they 482 SHOULD do so whenever a new handshake is performed in order to avoid 483 being used as amplifiers. If the server is being operated in an 484 environment where amplification is not a problem, the server MAY 485 choose not to perform a cookie exchange. In addition, the server MAY 486 choose not do to a cookie exchange when a session is resumed. Clients 487 MUST be prepared to do a cookie exchange with every handshake. 489 4.2.2. Handshake Message Format 491 In order to support message loss, reordering, and fragmentation DTLS 492 modifies the TLS 1.1 handshake header: 494 struct { 495 HandshakeType msg_type; 496 uint24 length; 497 uint16 message_seq; // New field 498 uint24 fragment_offset; // New field 499 uint24 fragment_length; // New field 500 select (HandshakeType) { 501 case hello_request: HelloRequest; 502 case client_hello: ClientHello; 503 case hello_verify_request: HelloVerifyRequest; // New type 504 case server_hello: ServerHello; 505 case certificate:Certificate; 506 case server_key_exchange: ServerKeyExchange; 507 case certificate_request: CertificateRequest; 508 case server_hello_done:ServerHelloDone; 509 case certificate_verify: CertificateVerify; 510 case client_key_exchange: ClientKeyExchange; 511 case finished:Finished; 512 } body; 513 } Handshake; 515 The first message each side transmits in each handshake always has 516 message_seq = 0. Whenever each new message is generated, the 517 message_seq value is incremented by one. When a message is 518 retransmitted, the same message_seq value is used. For example. 520 Client Server 521 ------ ------ 522 ClientHello (seq=0) ------> 524 X<-- HelloVerifyRequest (seq=0) 525 (lost) 527 [Timer Expires] 529 ClientHello (seq=0) ------> 530 (retransmit) 532 <------ HelloVerifyRequest (seq=0) 534 ClientHello (seq=1) ------> 535 (with cookie) 537 <------ ServerHello (seq=1) 538 <------ Certificate (seq=2) 539 <------ ServerHelloDone (seq=3) 541 [Rest of handshake] 543 DTLS implementations maintain (at least notionally) a 544 next_receive_seq counter. This counter is initially set to zero. When 545 a message is received, if its sequence number matches 546 next_receive_seq, next_receive_seq is incremented and the message is 547 processed. If the sequence number is less than next_receive_seq the 548 message MUST be discarded. If the sequence number is greater than 549 next_receive_seq, the implementation SHOULD queue the message but MAY 550 discard it. (This is a simple space/bandwidth tradeoff). 552 4.2.3. Message Fragmentation and Reassembly 554 As noted in Section 4.1.1., each DTLS message MUST fit within a 555 single transport layer datagram. However, handshake messages are 556 potentially bigger than the maximum record size. Therefore DTLS 557 provides a mechanism for fragmenting a handshake message over a 558 number of records. 560 When transmitting the handshake message, the sender divides the 561 message into a series of N contiguous data ranges. These range MUST 562 NOT be larger than the maximum handshake fragment size and MUST 563 jointly contain the entire handshake message. The ranges SHOULD NOT 564 overlap. The sender then creates N handshake messages, all with the 565 same message_seq value as the original handshake message. Each new 566 message is labelled with the fragment_offset (the number of bytes 567 contained in previous fragments) and the fragment_length (the length 568 of this fragment). The length field in all messages is the same as 569 the length field of the original message. An unfragmented message is 570 a degenerate case with fragment_offset=0 and fragment_length=length. 572 When a DTLS implementation receives a handshake message fragment, it 573 MUST buffer it until it has the entire handshake message. DTLS 574 implementations MUST be able to handle overlapping fragment ranges. 575 This allows senders to retransmit handshake messages with smaller 576 fragment sizes during path MTU discovery. 578 Note that as with TLS, multiple handshake messages may be placed in 579 the same DTLS record, provided that there is room and that they are 580 part of the same flight. Thus, there are two acceptable ways to pack 581 two DTLS messages into the same datagram: in the same record or in 582 separate records. 584 4.2.4. Timeout and Retransmission 586 DTLS messages are grouped into a series of message flights, according 587 the diagrams below. Although each flight of messages may consist of a 588 number of messages, they should be viewed as monolithic for the 589 purpose of timeout and retransmission. 591 Client Server 592 ------ ------ 594 ClientHello --------> Flight 1 596 <------- HelloVerifyRequest Flight 2 598 ClientHello --------> Flight 3 600 ServerHello \ 601 Certificate* \ 602 ServerKeyExchange* Flight 4 603 CertificateRequest* / 604 <-------- ServerHelloDone / 606 Certificate* \ 607 ClientKeyExchange \ 608 CertificateVerify* Flight 5 609 [ChangeCipherSpec] / 610 Finished --------> / 612 [ChangeCipherSpec] \ Flight 6 613 <-------- Finished / 614 Figure 1: Message flights for full handshake 616 Client Server 617 ------ ------ 619 ClientHello --------> Flight 1 621 ServerHello \ 622 [ChangeCipherSpec] Flight 2 623 <-------- Finished / 625 [ChangeCipherSpec] \Flight 3 626 Finished --------> / 627 Figure 2: Message flights for session resuming handshake (no cookie exchange) 629 DTLS uses a simple timeout and retransmission scheme with the 630 following state machine. Because DTLS clients send the first message 631 (ClientHello) they start in the PREPARING state. DTLS servers start 632 in the WAITING state, but with empty buffers and no retransmit timer. 634 +-----------+ 635 | PREPARING | 636 +---> | | 637 | | | 638 | +-----------+ 639 | | 640 | | 641 | | Buffer next flight 642 | | 643 | \|/ 644 | +-----------+ 645 | | | 646 | | SENDING |<------------------+ 647 | | | | 648 | +-----------+ | 649 Receive | | | 650 next | | Send flight | 651 flight | +--------+ | 652 | | | Set retransmit timer | 653 | | \|/ | 654 | | +-----------+ | 655 | | | | | 656 +--)--| WAITING |-------------------+ 657 | | | | Timer expires | 658 | | +-----------+ | 659 | | | | 660 | | | | 661 | | +------------------------+ 662 | | Read retransmit 663 Receive | | 664 last | | 665 flight | | 666 | | 667 \|/\|/ 669 +-----------+ 670 | | 671 | FINISHED | 672 | | 673 +-----------+ 675 Figure 3: DTLS timeout and retransmission state machine 677 The state machine has three basic states. 679 In the PREPARING state the implementation does whatever computations 680 are necessary to prepare the next flight of messages. It then buffers 681 them up for transmission (emptying the buffer first) and enters the 682 SENDING state. 684 In the SENDING state, the implementation transmits the buffered 685 flight of messages. Once the messages have been sent, the 686 implementation then enters the FINISHED state if this is the last 687 flight in the handshake, or, if the implementation expects to receive 688 more messages, sets a retransmit timer and then enters the WAITING 689 state. 691 There are three ways to exit the WAITING state: 693 1. The retransmit timer expires: the implementation transitions to 694 the SENDING state, where it retransmits the flight, resets the 695 retransmit timer, and returns to the WAITING state. 697 2. The implementation reads a retransmitted flight from the peer: 698 the implementation transitions to the SENDING state, where it 699 retransmits the flight, resets the retransmit timer, and returns 700 to the WAITING state. The rationale here is that the receipt of a 701 duplicate message is the likely result of timer expiry on the peer 702 and therefore suggests that part of one's previous flight was 703 lost. 705 3. The implementation receives the next flight of messages: if 706 this is the final flight of messages the implementation 707 transitions to FINISHED. If the implementation needs to send a new 708 flight, it transitions to the PREPARING state. Partial reads 709 (whether partial messages or only some of the messages in the 710 flight) do not cause state transitions or timer resets. 712 4.2.4.1. Timer Values 714 Timer value choices are a local matter. We RECOMMEND that 715 implementations use an initial timer value of 500 ms and double the 716 value at each retransmission, up to twice the TCP Maximum Segment 717 Lifetime. [TCP] Implementations SHOULD start the timer value at the 718 initial value with each new flight of messages. 720 4.2.5. ChangeCipherSpec 722 As with TLS, the ChangeCipherSpec message is not technically a 723 handshake message but MUST be treated as part of the same flight as 724 the associated Finished message for the purposes of timeout and 725 retransmission. 727 4.2.6. Finished messages 729 Finished messages have the same format as in TLS. However, in order 730 to remove sensitivity to fragmentation, the Finished MAC MUST be 731 computed as if each handshake message had been sent as a single 732 fragment. Note that in cases where the cookie exchange is used, the 733 initial ClientHello and HelloVerifyRequest MUST BE included in the 734 Finished MAC. 736 A.1Summary of new syntax 738 This section includes specifications for the data structures that 739 have changed between TLS 1.1 and DTLS. 741 4.2. Record Layer 742 struct { 743 ContentType type; 744 ProtocolVersion version; 745 uint16 epoch; // New field 746 uint48 sequence_number; // New field 747 uint16 length; 748 opaque fragment[DTLSPlaintext.length]; 749 } DTLSPlaintext; 751 struct { 752 ContentType type; 753 ProtocolVersion version; 754 uint16 epoch; // New field 755 uint48 sequence_number; // New field 756 uint16 length; 757 opaque fragment[DTLSCompressed.length]; 758 } DTLSCompressed; 760 struct { 761 ContentType type; 762 ProtocolVersion version; 763 uint16 epoch; // New field 764 uint48 sequence_number; // New field 765 uint16 length; 766 select (CipherSpec.cipher_type) { 767 case block: GenericBlockCipher; 768 } fragment; 769 } DTLSCiphertext; 770 4.3. Handshake Protocol 772 enum { 773 hello_request(0), client_hello(1), server_hello(2), 774 hello_verify_request(3), // New field 775 certificate(11), server_key_exchange (12), 776 certificate_request(13), server_hello_done(14), 777 certificate_verify(15), client_key_exchange(16), 778 finished(20), (255) 779 } HandshakeType; 781 struct { 782 HandshakeType msg_type; 783 uint24 length; 784 uint16 message_seq; // New field 785 uint24 fragment_offset; // New field 786 uint24 fragment_length; // New field 787 select (HandshakeType) { 788 case hello_request: HelloRequest; 789 case client_hello: ClientHello; 790 case server_hello: ServerHello; 791 case hello_verify_request: HelloVerifyRequest; // New field 792 case certificate:Certificate; 793 case server_key_exchange: ServerKeyExchange; 794 case certificate_request: CertificateRequest; 795 case server_hello_done:ServerHelloDone; 796 case certificate_verify: CertificateVerify; 797 case client_key_exchange: ClientKeyExchange; 798 case finished:Finished; 799 } body; 800 } Handshake; 802 struct { 803 Cookie cookie; 804 } HelloVerifyRequest; 806 5. Security Considerations 808 This document describes a variant of TLS 1.1 and therefore most of 809 the security considerations are the same as those of TLS 1.1 [TLS11], 810 described in Appendices D, E, and F. 812 The primary additional security consideration raised by DTLS is that 813 of denial of service. DTLS includes a cookie exchange designed to 814 protect against denial of service. However, implementations which do 815 not use this cookie exchange are still vulnerable to DoS. In 816 particular, DTLS servers which do not use the cookie exchange may be 817 used as attack amplifiers even if they themselves are not 818 experiencing DoS. Therefore DTLS servers SHOULD use the cookie 819 exchange unless there is good reason to believe that amplification is 820 not a threat in their environment. 822 6. IANA Considerations 824 This document uses the same identifier space as TLS [TLS11], so no 825 IANA registries are required beyond those for TLS. Identifiers MAY 826 NOT be assigned for DTLS that conflict with TLS. When new identifiers 827 are assigned for TLS, authors MUST specify whether they are suitable 828 for DTLS. 830 References 832 Normative References 834 [PHOTURIS] Karn, P., Simpson, W., "Photuris: Session-Key Management 835 Protocol", RFC 2521, March 1999. 837 [REQ] Bradner, S., "Key words for use in RFCs to Indicate 838 Requirement Levels", BCP 14, RFC 2119, March 1997. 840 [REQ] 842 [RFC1191] Mogul, J. C., Deering, S.E., "Path MTU Discovery", 843 RFC 1191, November 1990. 845 [RFC2401] Kent, S., Atkinson, R., "Security Architecture for the 846 Internet Protocol", RFC2401, November 1998. 848 [TCP] Postel, J., "Transmission Control Protocol", 849 RFC 793, September 1981. 851 [TLS] Dierks, T., and Allen, C., "The TLS Protocol Version 1.0", 852 RFC 2246, January 1999. 854 [TLS11] Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1", 855 draft-ietf-tls-rfc2246-bis-05.txt, July 2003. 857 Informative References 859 [AH] Kent, S., and Atkinson, R., "IP Authentication Header", 860 RFC 2402, November 1998. 862 [DCCP] Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram 863 Congestion Control Protocol", draft-ietf-dccp-spec-05.txt, 864 October 2003 866 [DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation 867 of Datagram TLS", in Proceedings of ISOC NDSS 2004, 868 February 2004. 870 [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security 871 Payload (ESP)", RFC 2406, November 1998. 873 [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", 874 RFC 2409, November 1998. 876 [IMAP] Crispin, M., "Internet Message Access Protocol - Version 877 4rev1", RFC 3501, March 2003. 879 [POP] Myers, J., and Rose, M., "Post Office Protocol - 880 Version 3", RFC 1939, May 1996. 882 [SIP] Rosenberg, J., Schulzrinne, Camarillo, G., Johnston, A., 883 Peterson, J., Sparks, R., Handley, M., Schooler, E., 884 "SIP: Session Initiation Protocol", RFC 3261, 885 June 2002. 887 [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", 888 draft-bellovin-useipsec-02.txt, October 2003 890 Authors' Address 892 Eric Rescorla 893 RTFM, Inc. 894 2064 Edgewood Drive 895 Palo Alto, CA 94303 897 Nagendra Modadugu 898 Computer Science Department 899 353 Serra Mall 900 Stanford University 901 Stanford, CA 94305 903 Acknowledgements 905 The authors would like to thank Dan Boneh, Eu-Jin Goh, Russ Housley, 906 Constantine Sapuntzakis, and Hovav Shacham for discussions and 907 comments on the design of DTLS. Thanks to the anonymous NDSS 908 reviewers of our original NDSS paper on DTLS [DTLS] for their 909 comments. Also, thanks to Steve Kent for feedback that helped clarify 910 many points. The section on PMTU was cribbed from the DCCP 911 specification [DCCP]. 913 Full Copyright Statement 915 The IETF takes no position regarding the validity or scope of any 916 Intellectual Property Rights or other rights that might be claimed to 917 pertain to the implementation or use of the technology described in 918 this document or the extent to which any license under such rights 919 might or might not be available; nor does it represent that it has 920 made any independent effort to identify any such rights. Information 921 on the procedures with respect to rights in RFC documents can be 922 found in BCP 78 and BCP 79. 924 Copies of IPR disclosures made to the IETF Secretariat and any 925 assurances of licenses to be made available, or the result of an 926 attempt made to obtain a general license or permission for the use of 927 such proprietary rights by implementers or users of this 928 specification can be obtained from the IETF on-line IPR repository at 929 http://www.ietf.org/ipr. 931 The IETF invites any interested party to bring to its attention any 932 copyrights, patents or patent applications, or other proprietary 933 rights that may cover technology that may be required to implement 934 this standard. Please address the information to the IETF at ietf- 935 ipr@ietf.org. 937 Copyright Notice 938 Copyright (C) The Internet Society (2003). This document is subject 939 to the rights, licenses and restrictions contained in BCP 78, and 940 except as set forth therein, the authors retain all their rights. 942 This document and the information contained herein are provided on an 943 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 944 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 945 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 946 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 947 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 948 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.