diff options
Diffstat (limited to 'doc/rfc/rfc4347.txt')
| -rw-r--r-- | doc/rfc/rfc4347.txt | 1403 |
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc4347.txt b/doc/rfc/rfc4347.txt new file mode 100644 index 0000000..7231bb7 --- /dev/null +++ b/doc/rfc/rfc4347.txt @@ -0,0 +1,1403 @@ + + + + + + +Network Working Group E. Rescorla +Request for Comments: 4347 RTFM, Inc. +Category: Standards Track N. Modadugu + Stanford University + April 2006 + + + Datagram Transport Layer Security + + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document specifies Version 1.0 of the Datagram Transport Layer + Security (DTLS) protocol. The DTLS protocol provides communications + privacy for datagram protocols. The protocol allows client/server + applications to communicate in a way that is designed to prevent + eavesdropping, tampering, or message forgery. The DTLS protocol is + based on the Transport Layer Security (TLS) protocol and provides + equivalent security guarantees. Datagram semantics of the underlying + transport are preserved by the DTLS protocol. + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Requirements Terminology ...................................3 + 2. Usage Model .....................................................3 + 3. Overview of DTLS ................................................4 + 3.1. Loss-Insensitive Messaging .................................4 + 3.2. Providing Reliability for Handshake ........................4 + 3.2.1. Packet Loss .........................................5 + 3.2.2. Reordering ..........................................5 + 3.2.3. Message Size ........................................5 + 3.3. Replay Detection ...........................................6 + 4. Differences from TLS ............................................6 + 4.1. Record Layer ...............................................6 + 4.1.1. Transport Layer Mapping .............................7 + + + +Rescorla & Modadugu Standards Track [Page 1] + +RFC 4347 Datagram Transport Layer Security April 2006 + + + 4.1.1.1. PMTU Discovery .............................8 + 4.1.2. Record Payload Protection ...........................9 + 4.1.2.1. MAC ........................................9 + 4.1.2.2. Null or Standard Stream Cipher .............9 + 4.1.2.3. Block Cipher ..............................10 + 4.1.2.4. New Cipher Suites .........................10 + 4.1.2.5. Anti-replay ...............................10 + 4.2. The DTLS Handshake Protocol ...............................11 + 4.2.1. Denial of Service Countermeasures ..................11 + 4.2.2. Handshake Message Format ...........................13 + 4.2.3. Message Fragmentation and Reassembly ...............15 + 4.2.4. Timeout and Retransmission .........................15 + 4.2.4.1. Timer Values ..............................18 + 4.2.5. ChangeCipherSpec ...................................19 + 4.2.6. Finished Messages ..................................19 + 4.2.7. Alert Messages .....................................19 + 4.3. Summary of new syntax .....................................19 + 4.3.1. Record Layer .......................................20 + 4.3.2. Handshake Protocol .................................20 + 5. Security Considerations ........................................21 + 6. Acknowledgements ...............................................22 + 7. IANA Considerations ............................................22 + 8. References .....................................................22 + 8.1. Normative References ......................................22 + 8.2. Informative References ....................................23 + +1. Introduction + + TLS [TLS] is the most widely deployed protocol for securing network + traffic. It is widely used for protecting Web traffic and for e-mail + protocols such as IMAP [IMAP] and POP [POP]. The primary advantage + of TLS is that it provides a transparent connection-oriented channel. + Thus, it is easy to secure an application protocol by inserting TLS + between the application layer and the transport layer. However, TLS + must run over a reliable transport channel -- typically TCP [TCP]. + It therefore cannot be used to secure unreliable datagram traffic. + + However, over the past few years an increasing number of application + layer protocols have been designed that use UDP transport. In + particular protocols such as the Session Initiation Protocol (SIP) + [SIP] and electronic gaming protocols are increasingly popular. + (Note that SIP can run over both TCP and UDP, but that there are + situations in which UDP is preferable). Currently, designers of + these applications are faced with a number of unsatisfactory choices. + First, they can use IPsec [RFC2401]. However, for a number of + reasons detailed in [WHYIPSEC], this is only suitable for some + applications. Second, they can design a custom application layer + security protocol. SIP, for instance, uses a subset of S/MIME to + + + +Rescorla & Modadugu Standards Track [Page 2] + +RFC 4347 Datagram Transport Layer Security April 2006 + + + secure its traffic. Unfortunately, although application layer + security protocols generally provide superior security properties + (e.g., end-to-end security in the case of S/MIME), they typically + requires a large amount of effort to design -- in contrast to the + relatively small amount of effort required to run the protocol over + TLS. + + In many cases, the most desirable way to secure client/server + applications would be to use TLS; however, the requirement for + datagram semantics automatically prohibits use of TLS. Thus, a + datagram-compatible variant of TLS would be very desirable. This + memo describes such a protocol: Datagram Transport Layer Security + (DTLS). DTLS is deliberately designed to be as similar to TLS as + possible, both to minimize new security invention and to maximize the + amount of code and infrastructure reuse. + +1.1. Requirements Terminology + + In this document, the keywords "MUST", "MUST NOT", "REQUIRED", + "SHOULD", "SHOULD NOT", and "MAY" are to be interpreted as described + in RFC 2119 [REQ]. + +2. Usage Model + + The DTLS protocol is designed to secure data between communicating + applications. It is designed to run in application space, without + requiring any kernel modifications. + + Datagram transport does not require or provide reliable or in-order + delivery of data. The DTLS protocol preserves this property for + payload data. Applications such as media streaming, Internet + telephony, and online gaming use datagram transport for communication + due to the delay-sensitive nature of transported data. The behavior + of such applications is unchanged when the DTLS protocol is used to + secure communication, since the DTLS protocol does not compensate for + lost or re-ordered data traffic. + + + + + + + + + + + + + + + +Rescorla & Modadugu Standards Track [Page 3] + +RFC 4347 Datagram Transport Layer Security April 2006 + + +3. Overview of DTLS + + The basic design philosophy of DTLS is to construct "TLS over + datagram". The reason that TLS cannot be used directly in datagram + environments is simply that packets may be lost or reordered. TLS + has no internal facilities to handle this kind of unreliability, and + therefore TLS implementations break when rehosted on datagram + transport. The purpose of DTLS is to make only the minimal changes + to TLS required to fix this problem. To the greatest extent + possible, DTLS is identical to TLS. Whenever we need to invent new + mechanisms, we attempt to do so in such a way that preserves the + style of TLS. + + Unreliability creates problems for TLS at two levels: + + 1. TLS's traffic encryption layer does not allow independent + decryption of individual records. If record N is not received, + then record N+1 cannot be decrypted. + + 2. The TLS handshake layer assumes that handshake messages are + delivered reliably and breaks if those messages are lost. + + The rest of this section describes the approach that DTLS uses to + solve these problems. + +3.1. Loss-Insensitive Messaging + + In TLS's traffic encryption layer (called the TLS Record Layer), + records are not independent. There are two kinds of inter-record + dependency: + + 1. Cryptographic context (CBC state, stream cipher key stream) is + chained between records. + + 2. Anti-replay and message reordering protection are provided by a + MAC that includes a sequence number, but the sequence numbers are + implicit in the records. + + The fix for both of these problems is straightforward and well known + from IPsec ESP [ESP]: add explicit state to the records. TLS 1.1 + [TLS11] is already adding explicit CBC state to TLS records. DTLS + borrows that mechanism and adds explicit sequence numbers. + +3.2. Providing Reliability for Handshake + + The TLS handshake is a lockstep cryptographic handshake. Messages + must be transmitted and received in a defined order, and any other + order is an error. Clearly, this is incompatible with reordering and + + + +Rescorla & Modadugu Standards Track [Page 4] + +RFC 4347 Datagram Transport Layer Security April 2006 + + + message loss. In addition, TLS handshake messages are potentially + larger than any given datagram, thus creating the problem of + fragmentation. DTLS must provide fixes for both of these problems. + +3.2.1. Packet Loss + + DTLS uses a simple retransmission timer to handle packet loss. The + following figure demonstrates the basic concept, using the first + phase of the DTLS handshake: + + Client Server + ------ ------ + ClientHello ------> + + X<-- HelloVerifyRequest + (lost) + + [Timer Expires] + + ClientHello ------> + (retransmit) + + Once the client has transmitted the ClientHello message, it expects + to see a HelloVerifyRequest from the server. However, if the + server's message is lost the client knows that either the ClientHello + or the HelloVerifyRequest has been lost and retransmits. When the + server receives the retransmission, it knows to retransmit. The + server also maintains a retransmission timer and retransmits when + that timer expires. + + Note: timeout and retransmission do not apply to the + HelloVerifyRequest, because this requires creating state on the + server. + +3.2.2. Reordering + + In DTLS, each handshake message is assigned a specific sequence + number within that handshake. When a peer receives a handshake + message, it can quickly determine whether that message is the next + message it expects. If it is, then it processes it. If not, it + queues it up for future handling once all previous messages have been + received. + +3.2.3. Message Size + + TLS and DTLS handshake messages can be quite large (in theory up to + 2^24-1 bytes, in practice many kilobytes). By contrast, UDP + datagrams are often limited to <1500 bytes if fragmentation is not + + + +Rescorla & Modadugu Standards Track [Page 5] + +RFC 4347 Datagram Transport Layer Security April 2006 + + + desired. In order to compensate for this limitation, each DTLS + handshake message may be fragmented over several DTLS records. Each + DTLS handshake message contains both a fragment offset and a fragment + length. Thus, a recipient in possession of all bytes of a handshake + message can reassemble the original unfragmented message. + +3.3. Replay Detection + + DTLS optionally supports record replay detection. The technique used + is the same as in IPsec AH/ESP, by maintaining a bitmap window of + received records. Records that are too old to fit in the window and + records that have previously been received are silently discarded. + The replay detection feature is optional, since packet duplication is + not always malicious, but can also occur due to routing errors. + Applications may conceivably detect duplicate packets and accordingly + modify their data transmission strategy. + +4. Differences from TLS + + As mentioned in Section 3, DTLS is intentionally very similar to TLS. + Therefore, instead of presenting DTLS as a new protocol, we present + it as a series of deltas from TLS 1.1 [TLS11]. Where we do not + explicitly call out differences, DTLS is the same as in [TLS11]. + +4.1. Record Layer + + The DTLS record layer is extremely similar to that of TLS 1.1. The + only change is the inclusion of an explicit sequence number in the + record. This sequence number allows the recipient to correctly + verify the TLS MAC. The DTLS record format is shown below: + + struct { + ContentType type; + ProtocolVersion version; + uint16 epoch; // New field + uint48 sequence_number; // New field + uint16 length; + opaque fragment[DTLSPlaintext.length]; + } DTLSPlaintext; + + type + Equivalent to the type field in a TLS 1.1 record. + + version + The version of the protocol being employed. This document + describes DTLS Version 1.0, which uses the version { 254, 255 + }. The version value of 254.255 is the 1's complement of DTLS + Version 1.0. This maximal spacing between TLS and DTLS version + + + +Rescorla & Modadugu Standards Track [Page 6] + +RFC 4347 Datagram Transport Layer Security April 2006 + + + numbers ensures that records from the two protocols can be + easily distinguished. It should be noted that future on-the-wire + version numbers of DTLS are decreasing in value (while the true + version number is increasing in value.) + + epoch + A counter value that is incremented on every cipher state + change. + + sequence_number + The sequence number for this record. + + length + Identical to the length field in a TLS 1.1 record. As in TLS + 1.1, the length should not exceed 2^14. + + fragment + Identical to the fragment field of a TLS 1.1 record. + + DTLS uses an explicit sequence number, rather than an implicit one, + carried in the sequence_number field of the record. As with TLS, the + sequence number is set to zero after each ChangeCipherSpec message is + sent. + + If several handshakes are performed in close succession, there might + be multiple records on the wire with the same sequence number but + from different cipher states. The epoch field allows recipients to + distinguish such packets. The epoch number is initially zero and is + incremented each time the ChangeCipherSpec messages is sent. In + order to ensure that any given sequence/epoch pair is unique, + implementations MUST NOT allow the same epoch value to be reused + within two times the TCP maximum segment lifetime. In practice, TLS + implementations rarely rehandshake and we therefore do not expect + this to be a problem. + +4.1.1. Transport Layer Mapping + + Each DTLS record MUST fit within a single datagram. In order to + avoid IP fragmentation [MOGUL], DTLS implementations SHOULD determine + the MTU and send records smaller than the MTU. DTLS implementations + SHOULD provide a way for applications to determine the value of the + PMTU (or, alternately, the maximum application datagram size, which + is the PMTU minus the DTLS per-record overhead). If the application + attempts to send a record larger than the MTU, the DTLS + implementation SHOULD generate an error, thus avoiding sending a + packet which will be fragmented. + + + + + +Rescorla & Modadugu Standards Track [Page 7] + +RFC 4347 Datagram Transport Layer Security April 2006 + + + Note that unlike IPsec, DTLS records do not contain any association + identifiers. Applications must arrange to multiplex between + associations. With UDP, this is presumably done with host/port + number. + + Multiple DTLS records may be placed in a single datagram. They are + simply encoded consecutively. The DTLS record framing is sufficient + to determine the boundaries. Note, however, that the first byte of + the datagram payload must be the beginning of a record. Records may + not span datagrams. + + Some transports, such as DCCP [DCCP] provide their own sequence + numbers. When carried over those transports, both the DTLS and the + transport sequence numbers will be present. Although this introduces + a small amount of inefficiency, the transport layer and DTLS sequence + numbers serve different purposes, and therefore for conceptual + simplicity it is superior to use both sequence numbers. In the + future, extensions to DTLS may be specified that allow the use of + only one set of sequence numbers for deployment in constrained + environments. + + Some transports, such as DCCP, provide congestion control for traffic + carried over them. If the congestion window is sufficiently narrow, + DTLS handshake retransmissions may be held rather than transmitted + immediately, potentially leading to timeouts and spurious + retransmission. When DTLS is used over such transports, care should + be taken not to overrun the likely congestion window. In the future, + a DTLS-DCCP mapping may be specified to provide optimal behavior for + this interaction. + +4.1.1.1. PMTU Discovery + + In general, DTLS's philosophy is to avoid dealing with PMTU issues. + The general strategy is to start with a conservative MTU and then + update it if events during the handshake or actual application data + transport phase require it. + + The PMTU SHOULD be initialized from the interface MTU that will be + used to send packets. If the DTLS implementation receives an RFC + 1191 [RFC1191] ICMP Destination Unreachable message with the + "fragmentation needed and DF set" Code (otherwise known as Datagram + Too Big), it should decrease its PMTU estimate to that given in the + ICMP message. A DTLS implementation SHOULD allow the application to + occasionally reset its PMTU estimate. The DTLS implementation SHOULD + also allow applications to control the status of the DF bit. These + controls allow the application to perform PMTU discovery. RFC 1981 + [RFC1981] procedures SHOULD be followed for IPv6. + + + + +Rescorla & Modadugu Standards Track [Page 8] + +RFC 4347 Datagram Transport Layer Security April 2006 + + + One special case is the DTLS handshake system. Handshake messages + should be set with DF set. Because some firewalls and routers screen + out ICMP messages, it is difficult for the handshake layer to + distinguish packet loss from an overlarge PMTU estimate. In order to + allow connections under these circumstances, DTLS implementations + SHOULD back off handshake packet size during the retransmit backoff + described in Section 4.2.4. For instance, if a large packet is being + sent, after 3 retransmits the handshake layer might choose to + fragment the handshake message on retransmission. In general, choice + of a conservative initial MTU will avoid this problem. + +4.1.2. Record Payload Protection + + Like TLS, DTLS transmits data as a series of protected records. The + rest of this section describes the details of that format. + +4.1.2.1. MAC + + The DTLS MAC is the same as that of TLS 1.1. However, rather than + using TLS's implicit sequence number, the sequence number used to + compute the MAC is the 64-bit value formed by concatenating the epoch + and the sequence number in the order they appear on the wire. Note + that the DTLS epoch + sequence number is the same length as the TLS + sequence number. + + TLS MAC calculation is parameterized on the protocol version number, + which, in the case of DTLS, is the on-the-wire version, i.e., {254, + 255 } for DTLS 1.0. + + Note that one important difference between DTLS and TLS MAC handling + is that in TLS MAC errors must result in connection termination. In + DTLS, the receiving implementation MAY simply discard the offending + record and continue with the connection. This change is possible + because DTLS records are not dependent on each other in the way that + TLS records are. + + In general, DTLS implementations SHOULD silently discard data with + bad MACs. If a DTLS implementation chooses to generate an alert when + it receives a message with an invalid MAC, it MUST generate + bad_record_mac alert with level fatal and terminate its connection + state. + +4.1.2.2. Null or Standard Stream Cipher + + The DTLS NULL cipher is performed exactly as the TLS 1.1 NULL cipher. + + The only stream cipher described in TLS 1.1 is RC4, which cannot be + randomly accessed. RC4 MUST NOT be used with DTLS. + + + +Rescorla & Modadugu Standards Track [Page 9] + +RFC 4347 Datagram Transport Layer Security April 2006 + + +4.1.2.3. Block Cipher + + DTLS block cipher encryption and decryption are performed exactly as + with TLS 1.1. + +4.1.2.4. New Cipher Suites + + Upon registration, new TLS cipher suites MUST indicate whether they + are suitable for DTLS usage and what, if any, adaptations must be + made. + +4.1.2.5. Anti-replay + + DTLS records contain a sequence number to provide replay protection. + Sequence number verification SHOULD be performed using the following + sliding window procedure, borrowed from Section 3.4.3 of [RFC 2402]. + + The receiver packet counter for this session MUST be initialized to + zero when the session is established. For each received record, the + receiver MUST verify that the record contains a Sequence Number that + does not duplicate the Sequence Number of any other record received + during the life of this session. This SHOULD be the first check + applied to a packet after it has been matched to a session, to speed + rejection of duplicate records. + + Duplicates are rejected through the use of a sliding receive window. + (How the window is implemented is a local matter, but the following + text describes the functionality that the implementation must + exhibit.) A minimum window size of 32 MUST be supported, but a + window size of 64 is preferred and SHOULD be employed as the default. + Another window size (larger than the minimum) MAY be chosen by the + receiver. (The receiver does not notify the sender of the window + size.) + + The "right" edge of the window represents the highest validated + Sequence Number value received on this session. Records that contain + Sequence Numbers lower than the "left" edge of the window are + rejected. Packets falling within the window are checked against a + list of received packets within the window. An efficient means for + performing this check, based on the use of a bit mask, is described + in Appendix C of [RFC 2401]. + + If the received record falls within the window and is new, or if the + packet is to the right of the window, then the receiver proceeds to + MAC verification. If the MAC validation fails, the receiver MUST + discard the received record as invalid. The receive window is + updated only if the MAC verification succeeds. + + + + +Rescorla & Modadugu Standards Track [Page 10] + +RFC 4347 Datagram Transport Layer Security April 2006 + + +4.2. The DTLS Handshake Protocol + + DTLS uses all of the same handshake messages and flows as TLS, with + three principal changes: + + 1. A stateless cookie exchange has been added to prevent denial of + service attacks. + + 2. Modifications to the handshake header to handle message loss, + reordering, and fragmentation. + + 3. Retransmission timers to handle message loss. + + With these exceptions, the DTLS message formats, flows, and logic are + the same as those of TLS 1.1. + +4.2.1. Denial of Service Countermeasures + + Datagram security protocols are extremely susceptible to a variety of + denial of service (DoS) attacks. Two attacks are of particular + concern: + + 1. An attacker can consume excessive resources on the server by + transmitting a series of handshake initiation requests, causing + the server to allocate state and potentially to perform expensive + cryptographic operations. + + 2. An attacker can use the server as an amplifier by sending + connection initiation messages with a forged source of the victim. + The server then sends its next message (in DTLS, a Certificate + message, which can be quite large) to the victim machine, thus + flooding it. + + In order to counter both of these attacks, DTLS borrows the stateless + cookie technique used by Photuris [PHOTURIS] and IKE [IKE]. When the + client sends its ClientHello message to the server, the server MAY + respond with a HelloVerifyRequest message. This message contains a + stateless cookie generated using the technique of [PHOTURIS]. The + client MUST retransmit the ClientHello with the cookie added. The + server then verifies the cookie and proceeds with the handshake only + if it is valid. This mechanism forces the attacker/client to be able + to receive the cookie, which makes DoS attacks with spoofed IP + addresses difficult. This mechanism does not provide any defense + against DoS attacks mounted from valid IP addresses. + + + + + + + +Rescorla & Modadugu Standards Track [Page 11] + +RFC 4347 Datagram Transport Layer Security April 2006 + + + The exchange is shown below: + + Client Server + ------ ------ + ClientHello ------> + + <----- HelloVerifyRequest + (contains cookie) + + ClientHello ------> + (with cookie) + + [Rest of handshake] + + DTLS therefore modifies the ClientHello message to add the cookie + value. + + struct { + ProtocolVersion client_version; + Random random; + SessionID session_id; + opaque cookie<0..32>; // New field + CipherSuite cipher_suites<2..2^16-1>; + CompressionMethod compression_methods<1..2^8-1>; + } ClientHello; + + When sending the first ClientHello, the client does not have a cookie + yet; in this case, the Cookie field is left empty (zero length). + + The definition of HelloVerifyRequest is as follows: + + struct { + ProtocolVersion server_version; + opaque cookie<0..32>; + } HelloVerifyRequest; + + The HelloVerifyRequest message type is hello_verify_request(3). + + The server_version field is defined as in TLS. + + When responding to a HelloVerifyRequest the client MUST use the same + parameter values (version, random, session_id, cipher_suites, + compression_method) as it did in the original ClientHello. The + server SHOULD use those values to generate its cookie and verify that + they are correct upon cookie receipt. The server MUST use the same + version number in the HelloVerifyRequest that it would use when + sending a ServerHello. Upon receipt of the ServerHello, the client + MUST verify that the server version values match. + + + +Rescorla & Modadugu Standards Track [Page 12] + +RFC 4347 Datagram Transport Layer Security April 2006 + + + The DTLS server SHOULD generate cookies in such a way that they can + be verified without retaining any per-client state on the server. + One technique is to have a randomly generated secret and generate + cookies as: Cookie = HMAC(Secret, Client-IP, Client-Parameters) + + When the second ClientHello is received, the server can verify that + the Cookie is valid and that the client can receive packets at the + given IP address. + + One potential attack on this scheme is for the attacker to collect a + number of cookies from different addresses and then reuse them to + attack the server. The server can defend against this attack by + changing the Secret value frequently, thus invalidating those + cookies. If the server wishes that legitimate clients be able to + handshake through the transition (e.g., they received a cookie with + Secret 1 and then sent the second ClientHello after the server has + changed to Secret 2), the server can have a limited window during + which it accepts both secrets. [IKEv2] suggests adding a version + number to cookies to detect this case. An alternative approach is + simply to try verifying with both secrets. + + DTLS servers SHOULD perform a cookie exchange whenever a new + handshake is being performed. If the server is being operated in an + environment where amplification is not a problem, the server MAY be + configured not to perform a cookie exchange. The default SHOULD be + that the exchange is performed, however. In addition, the server MAY + choose not to do a cookie exchange when a session is resumed. + Clients MUST be prepared to do a cookie exchange with every + handshake. + + If HelloVerifyRequest is used, the initial ClientHello and + HelloVerifyRequest are not included in the calculation of the + verify_data for the Finished message. + +4.2.2. Handshake Message Format + + In order to support message loss, reordering, and fragmentation, DTLS + modifies the TLS 1.1 handshake header: + + struct { + HandshakeType msg_type; + uint24 length; + uint16 message_seq; // New field + uint24 fragment_offset; // New field + uint24 fragment_length; // New field + select (HandshakeType) { + case hello_request: HelloRequest; + case client_hello: ClientHello; + + + +Rescorla & Modadugu Standards Track [Page 13] + +RFC 4347 Datagram Transport Layer Security April 2006 + + + case hello_verify_request: HelloVerifyRequest; // New type + case server_hello: ServerHello; + case certificate:Certificate; + case server_key_exchange: ServerKeyExchange; + case certificate_request: CertificateRequest; + case server_hello_done:ServerHelloDone; + case certificate_verify: CertificateVerify; + case client_key_exchange: ClientKeyExchange; + case finished:Finished; + } body; + } Handshake; + + The first message each side transmits in each handshake always has + message_seq = 0. Whenever each new message is generated, the + message_seq value is incremented by one. When a message is + retransmitted, the same message_seq value is used. For example: + + Client Server + ------ ------ + ClientHello (seq=0) ------> + + X<-- HelloVerifyRequest (seq=0) + (lost) + + [Timer Expires] + + ClientHello (seq=0) ------> + (retransmit) + + <------ HelloVerifyRequest (seq=0) + + ClientHello (seq=1) ------> + (with cookie) + + <------ ServerHello (seq=1) + <------ Certificate (seq=2) + <------ ServerHelloDone (seq=3) + + [Rest of handshake] + + Note, however, that from the perspective of the DTLS record layer, + the retransmission is a new record. This record will have a new + DTLSPlaintext.sequence_number value. + + DTLS implementations maintain (at least notionally) a + next_receive_seq counter. This counter is initially set to zero. + When a message is received, if its sequence number matches + next_receive_seq, next_receive_seq is incremented and the message is + + + +Rescorla & Modadugu Standards Track [Page 14] + +RFC 4347 Datagram Transport Layer Security April 2006 + + + processed. If the sequence number is less than next_receive_seq, the + message MUST be discarded. If the sequence number is greater than + next_receive_seq, the implementation SHOULD queue the message but MAY + discard it. (This is a simple space/bandwidth tradeoff). + +4.2.3. Message Fragmentation and Reassembly + + As noted in Section 4.1.1, each DTLS message MUST fit within a single + transport layer datagram. However, handshake messages are + potentially bigger than the maximum record size. Therefore, DTLS + provides a mechanism for fragmenting a handshake message over a + number of records. + + When transmitting the handshake message, the sender divides the + message into a series of N contiguous data ranges. These ranges MUST + NOT be larger than the maximum handshake fragment size and MUST + jointly contain the entire handshake message. The ranges SHOULD NOT + overlap. The sender then creates N handshake messages, all with the + same message_seq value as the original handshake message. Each new + message is labelled with the fragment_offset (the number of bytes + contained in previous fragments) and the fragment_length (the length + of this fragment). The length field in all messages is the same as + the length field of the original message. An unfragmented message is + a degenerate case with fragment_offset=0 and fragment_length=length. + + When a DTLS implementation receives a handshake message fragment, it + MUST buffer it until it has the entire handshake message. DTLS + implementations MUST be able to handle overlapping fragment ranges. + This allows senders to retransmit handshake messages with smaller + fragment sizes during path MTU discovery. + + Note that as with TLS, multiple handshake messages may be placed in + the same DTLS record, provided that there is room and that they are + part of the same flight. Thus, there are two acceptable ways to pack + two DTLS messages into the same datagram: in the same record or in + separate records. + +4.2.4. Timeout and Retransmission + + DTLS messages are grouped into a series of message flights, according + to the diagrams below. Although each flight of messages may consist + of a number of messages, they should be viewed as monolithic for the + purpose of timeout and retransmission. + + + + + + + + +Rescorla & Modadugu Standards Track [Page 15] + +RFC 4347 Datagram Transport Layer Security April 2006 + + + Client Server + ------ ------ + + ClientHello --------> Flight 1 + + <------- HelloVerifyRequest Flight 2 + + ClientHello --------> Flight 3 + + ServerHello \ + Certificate* \ + ServerKeyExchange* Flight 4 + CertificateRequest* / + <-------- ServerHelloDone / + + Certificate* \ + ClientKeyExchange \ + CertificateVerify* Flight 5 + [ChangeCipherSpec] / + Finished --------> / + + [ChangeCipherSpec] \ Flight 6 + <-------- Finished / + + Figure 1. Message flights for full handshake + + + Client Server + ------ ------ + + ClientHello --------> Flight 1 + + ServerHello \ + [ChangeCipherSpec] Flight 2 + <-------- Finished / + + [ChangeCipherSpec] \Flight 3 + Finished --------> / + + Figure 2. Message flights for session-resuming handshake + (no cookie exchange) + + DTLS uses a simple timeout and retransmission scheme with the + following state machine. Because DTLS clients send the first message + (ClientHello), they start in the PREPARING state. DTLS servers start + in the WAITING state, but with empty buffers and no retransmit timer. + + + + + +Rescorla & Modadugu Standards Track [Page 16] + +RFC 4347 Datagram Transport Layer Security April 2006 + + + +-----------+ + | PREPARING | + +---> | | <--------------------+ + | | | | + | +-----------+ | + | | | + | | | + | | Buffer next flight | + | | | + | \|/ | + | +-----------+ | + | | | | + | | SENDING |<------------------+ | + | | | | | Send + | +-----------+ | | HelloRequest + Receive | | | | + next | | Send flight | | or + flight | +--------+ | | + | | | Set retransmit timer | | Receive + | | \|/ | | HelloRequest + | | +-----------+ | | Send + | | | | | | ClientHello + +--)--| WAITING |-------------------+ | + | | | | Timer expires | | + | | +-----------+ | | + | | | | | + | | | | | + | | +------------------------+ | + | | Read retransmit | + Receive | | | + last | | | + flight | | | + | | | + \|/\|/ | + | + +-----------+ | + | | | + | FINISHED | -------------------------------+ + | | + +-----------+ + + Figure 3. DTLS timeout and retransmission state machine + + The state machine has three basic states. + + + + + + + +Rescorla & Modadugu Standards Track [Page 17] + +RFC 4347 Datagram Transport Layer Security April 2006 + + + In the PREPARING state the implementation does whatever computations + are necessary to prepare the next flight of messages. It then + buffers them up for transmission (emptying the buffer first) and + enters the SENDING state. + + In the SENDING state, the implementation transmits the buffered + flight of messages. Once the messages have been sent, the + implementation then enters the FINISHED state if this is the last + flight in the handshake. Or, if the implementation expects to + receive more messages, it sets a retransmit timer and then enters the + WAITING state. + + There are three ways to exit the WAITING state: + + 1. The retransmit timer expires: the implementation transitions to + the SENDING state, where it retransmits the flight, resets the + retransmit timer, and returns to the WAITING state. + + 2. The implementation reads a retransmitted flight from the peer: + the implementation transitions to the SENDING state, where it + retransmits the flight, resets the retransmit timer, and returns + to the WAITING state. The rationale here is that the receipt of a + duplicate message is the likely result of timer expiry on the peer + and therefore suggests that part of one's previous flight was + lost. + + 3. The implementation receives the next flight of messages: if + this is the final flight of messages, the implementation + transitions to FINISHED. If the implementation needs to send a + new flight, it transitions to the PREPARING state. Partial reads + (whether partial messages or only some of the messages in the + flight) do not cause state transitions or timer resets. + + Because DTLS clients send the first message (ClientHello), they start + in the PREPARING state. DTLS servers start in the WAITING state, but + with empty buffers and no retransmit timer. + + When the server desires a rehandshake, it transitions from the + FINISHED state to the PREPARING state to transmit the HelloRequest. + When the client receives a HelloRequest it transitions from FINISHED + to PREPARING to transmit the ClientHello. + +4.2.4.1. Timer Values + + Though timer values are the choice of the implementation, mishandling + of the timer can lead to serious congestion problems; for example, if + many instances of a DTLS time out early and retransmit too quickly on + a congested link. Implementations SHOULD use an initial timer value + + + +Rescorla & Modadugu Standards Track [Page 18] + +RFC 4347 Datagram Transport Layer Security April 2006 + + + of 1 second (the minimum defined in RFC 2988 [RFC2988]) and double + the value at each retransmission, up to no less than the RFC 2988 + maximum of 60 seconds. Note that we recommend a 1-second timer + rather than the 3-second RFC 2988 default in order to improve latency + for time-sensitive applications. Because DTLS only uses + retransmission for handshake and not dataflow, the effect on + congestion should be minimal. + + Implementations SHOULD retain the current timer value until a + transmission without loss occurs, at which time the value may be + reset to the initial value. After a long period of idleness, no less + than 10 times the current timer value, implementations may reset the + timer to the initial value. One situation where this might occur is + when a rehandshake is used after substantial data transfer. + +4.2.5. ChangeCipherSpec + + As with TLS, the ChangeCipherSpec message is not technically a + handshake message but MUST be treated as part of the same flight as + the associated Finished message for the purposes of timeout and + retransmission. + +4.2.6. Finished Messages + + Finished messages have the same format as in TLS. However, in order + to remove sensitivity to fragmentation, the Finished MAC MUST be + computed as if each handshake message had been sent as a single + fragment. Note that in cases where the cookie exchange is used, the + initial ClientHello and HelloVerifyRequest MUST NOT be included in + the Finished MAC. + +4.2.7. Alert Messages + + Note that Alert messages are not retransmitted at all, even when they + occur in the context of a handshake. However, a DTLS implementation + SHOULD generate a new alert message if the offending record is + received again (e.g., as a retransmitted handshake message). + Implementations SHOULD detect when a peer is persistently sending bad + messages and terminate the local connection state after such + misbehavior is detected. + +4.3. Summary of new syntax + + This section includes specifications for the data structures that + have changed between TLS 1.1 and DTLS. + + + + + + +Rescorla & Modadugu Standards Track [Page 19] + +RFC 4347 Datagram Transport Layer Security April 2006 + + +4.3.1. Record Layer + + struct { + ContentType type; + ProtocolVersion version; + uint16 epoch; // New field + uint48 sequence_number; // New field + uint16 length; + opaque fragment[DTLSPlaintext.length]; + } DTLSPlaintext; + + struct { + ContentType type; + ProtocolVersion version; + uint16 epoch; // New field + uint48 sequence_number; // New field + uint16 length; + opaque fragment[DTLSCompressed.length]; + } DTLSCompressed; + + struct { + ContentType type; + ProtocolVersion version; + uint16 epoch; // New field + uint48 sequence_number; // New field + uint16 length; + select (CipherSpec.cipher_type) { + case block: GenericBlockCipher; + } fragment; + } DTLSCiphertext; + +4.3.2. Handshake Protocol + + enum { + hello_request(0), client_hello(1), server_hello(2), + hello_verify_request(3), // New field + certificate(11), server_key_exchange (12), + certificate_request(13), server_hello_done(14), + certificate_verify(15), client_key_exchange(16), + finished(20), (255) + } HandshakeType; + + struct { + HandshakeType msg_type; + uint24 length; + uint16 message_seq; // New field + uint24 fragment_offset; // New field + uint24 fragment_length; // New field + + + +Rescorla & Modadugu Standards Track [Page 20] + +RFC 4347 Datagram Transport Layer Security April 2006 + + + select (HandshakeType) { + case hello_request: HelloRequest; + case client_hello: ClientHello; + case server_hello: ServerHello; + case hello_verify_request: HelloVerifyRequest; // New field + case certificate:Certificate; + case server_key_exchange: ServerKeyExchange; + case certificate_request: CertificateRequest; + case server_hello_done:ServerHelloDone; + case certificate_verify: CertificateVerify; + case client_key_exchange: ClientKeyExchange; + case finished:Finished; + } body; + } Handshake; + + struct { + ProtocolVersion client_version; + Random random; + SessionID session_id; + opaque cookie<0..32>; // New field + CipherSuite cipher_suites<2..2^16-1>; + CompressionMethod compression_methods<1..2^8-1>; + } ClientHello; + + struct { + ProtocolVersion server_version; + opaque cookie<0..32>; + } HelloVerifyRequest; + +5. Security Considerations + + This document describes a variant of TLS 1.1 and therefore most of + the security considerations are the same as those of TLS 1.1 [TLS11], + described in Appendices D, E, and F. + + The primary additional security consideration raised by DTLS is that + of denial of service. DTLS includes a cookie exchange designed to + protect against denial of service. However, implementations which do + not use this cookie exchange are still vulnerable to DoS. In + particular, DTLS servers which do not use the cookie exchange may be + used as attack amplifiers even if they themselves are not + experiencing DoS. Therefore, DTLS servers SHOULD use the cookie + exchange unless there is good reason to believe that amplification is + not a threat in their environment. Clients MUST be prepared to do a + cookie exchange with every handshake. + + + + + + +Rescorla & Modadugu Standards Track [Page 21] + +RFC 4347 Datagram Transport Layer Security April 2006 + + +6. Acknowledgements + + The authors would like to thank Dan Boneh, Eu-Jin Goh, Russ Housley, + Constantine Sapuntzakis, and Hovav Shacham for discussions and + comments on the design of DTLS. Thanks to the anonymous NDSS + reviewers of our original NDSS paper on DTLS [DTLS] for their + comments. Also, thanks to Steve Kent for feedback that helped + clarify many points. The section on PMTU was cribbed from the DCCP + specification [DCCP]. Pasi Eronen provided a detailed review of this + specification. Helpful comments on the document were also received + from Mark Allman, Jari Arkko, Joel Halpern, Ted Hardie, and Allison + Mankin. + +7. IANA Considerations + + This document uses the same identifier space as TLS [TLS11], so no + new IANA registries are required. When new identifiers are assigned + for TLS, authors MUST specify whether they are suitable for DTLS. + + This document defines a new handshake message, hello_verify_request, + whose value has been allocated from the TLS HandshakeType registry + defined in [TLS11]. The value "3" has been assigned by the IANA. + +8. References + +8.1. Normative References + + [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, + November 1990. + + [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery + for IP version 6", RFC 1981, August 1996. + + [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the + Internet Protocol", RFC 2401, November 1998. + + [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission + Timer", RFC 2988, November 2000. + + [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [TLS11] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.1", RFC 4346, April 2006. + + + + + + + +Rescorla & Modadugu Standards Track [Page 22] + +RFC 4347 Datagram Transport Layer Security April 2006 + + +8.2. Informative References + + [AESCACHE] Bernstein, D.J., "Cache-timing attacks on AES" + http://cr.yp.to/antiforgery/cachetiming-20050414.pdf. + + [AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC + 2402, November 1998. + + [DCCP] Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram + Congestion Control Protocol", Work in Progress, 10 March + 2005. + + [DNS] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation + of Datagram TLS", Proceedings of ISOC NDSS 2004, February + 2004. + + [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security + Payload (ESP)", RFC 2406, November 1998. + + [IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange + (IKE)", RFC 2409, November 1998. + + Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, + December 2005. + + [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION + 4rev1", RFC 3501, March 2003. + + [PHOTURIS] Karn, P. and W. Simpson, "ICMP Security Failures + Messages", RFC 2521, March 1999. + + [POP] Myers, J. and M. Rose, "Post Office Protocol - Version 3", + STD 53, RFC 1939, May 1996. + + [REQ] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [SCTP] Stewart, R., Xie, Q., Morneault, K., Sharp, C., + Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., + Zhang, L., and V. Paxson, "Stream Control Transmission + Protocol", RFC 2960, October 2000. + + + + + + + +Rescorla & Modadugu Standards Track [Page 23] + +RFC 4347 Datagram Transport Layer Security April 2006 + + + [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + June 2002. + + [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", + RFC 2246, January 1999. + + [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", + Work in Progress, October 2003. + +Authors' Addresses + + Eric Rescorla + RTFM, Inc. + 2064 Edgewood Drive + Palo Alto, CA 94303 + + EMail: ekr@rtfm.com + + + Nagendra Modadugu + Computer Science Department + Stanford University + 353 Serra Mall + Stanford, CA 94305 + + EMail: nagendra@cs.stanford.edu + + + + + + + + + + + + + + + + + + + + + + + +Rescorla & Modadugu Standards Track [Page 24] + +RFC 4347 Datagram Transport Layer Security April 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Rescorla & Modadugu Standards Track [Page 25] + |