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