From: Simon Josefsson Date: Fri, 24 Jun 2005 20:35:38 +0000 (+0000) Subject: Add. X-Git-Tag: gnutls_1_2_5~9 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=4e60f5daa63e60b2e28cfb30fcf274ad37ef04d8;p=thirdparty%2Fgnutls.git Add. --- diff --git a/doc/protocol/draft-rescorla-dtls-05.txt b/doc/protocol/draft-rescorla-dtls-05.txt new file mode 100644 index 0000000000..ba75c2ad99 --- /dev/null +++ b/doc/protocol/draft-rescorla-dtls-05.txt @@ -0,0 +1,1393 @@ + + E. Rescorla + RTFM, Inc. + N. Modadugu +INTERNET-DRAFT Stanford University + June 2004 (Expires December 2005) + + Datagram Transport Layer Security + +Status of this Memo + +By submitting this Internet-Draft, each author represents that any +applicable patent or other IPR claims of which he or she is aware +have been or will be disclosed, and any of which he or she becomes +aware will be disclosed, in accordance with Section 6 of BCP 79. + +Internet-Drafts are working documents of the Internet Engineering +Task Force (IETF), its areas, and its working groups. Note that +other groups may also distribute working documents as +Internet-Drafts. + +Internet-Drafts are draft documents valid for a maximum of six months +and may be updated, replaced, or obsoleted by other documents at any +time. It is inappropriate to use Internet-Drafts as reference +material or to cite them other than as "work in progress." + +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/1id-abstracts.html + +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html + +Copyright Notice + + Copyright (C) The Internet Society (2005). All Rights Reserved. + + + + + + +Rescorla, Modadugu [Page 1] + + +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 TLS protocol and + provides equivalent security guarantees. Datagram semantics of + the underlying transport are preserved by the DTLS protocol. + + +Contents + + 1 Introduction 3 + 1.1 Requirements Terminology 3 + 2 Usage Model 4 + 3 Overview of DTLS 4 + 3.1 Loss-insensitive messaging 4 + 3.2 Providing Reliability for Handshake 5 + 3.2.1 Packet Loss 5 + 3.2.2 Reordering 6 + 3.2.3 Message Size 6 + 3.3 Replay Detection 6 + 4 Differences from TLS 6 + 4.1 Record Layer 7 + 4.1.1 Transport Layer Mapping 8 + 4.1.1.1 PMTU Discovery 9 + 4.1.2 Record payload protection 9 + 4.1.2.1 MAC 10 + 4.1.2.2 Null or standard stream cipher 10 + 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 12 + 4.2.2 Handshake Message Format 14 + 4.2.3 Message Fragmentation and Reassembly 16 + 4.2.4 Timeout and Retransmission 16 + 4.2.4.1 Timer Values 19 + 4.2.5 ChangeCipherSpec 20 + 4.2.6 Finished messages 20 + 4.2.7 Alert Messages 20 + 4.2 Record Layer 21 + 4.3 Handshake Protocol 21 + 5 Security Considerations 22 + 6 IANA Considerations 23 + + + + +Rescorla, Modadugu [Page 2] + + +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 which use UDP + transport. In particular such protocols 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 secure its traffic. Unfortunately, while application + layer security protocols generally provide superior security + properties (e.g., end-to-end security in the case of S/MIME) + it typically requires a large amount of effort to design--by + 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 to TLS as possible, both to minimize new security + invention and to maximize the amount of code and + infrastructure reuse. + + +1.1. Requirements Terminology + + Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD + NOT" and "MAY" that appear in this document are to be + interpreted as described in RFC 2119 [REQ]. + + + + +Rescorla, Modadugu [Page 3] + + +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. + +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 it 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: + + + + +Rescorla, Modadugu [Page 4] + + + 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 which 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 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 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. + + + +Rescorla, Modadugu [Page 5] + + + 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 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 been previously + 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 instead 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]. + + + + + + + +Rescorla, Modadugu [Page 6] + + +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 + numbers ensures that records from the two protocols can be + easily distinguished. + + 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 rather than implicit sequence number, + 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. + + + + + +Rescorla, Modadugu [Page 7] + + + 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 + rehandshake rarely 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. + + 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 + + + +Rescorla, Modadugu [Page 8] + + + 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 specificied 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. + + 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. + + + + + + + +Rescorla, Modadugu [Page 9] + + +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. + + 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 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. + +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]. + + + + + +Rescorla, Modadugu [Page 10] + + + 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. + +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. + + + + + +Rescorla, Modadugu [Page 11] + + + 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 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. + + The exchange is shown below: + + Client Server + ------ ------ + ClientHello ------> + + <----- HelloVerifyRequest + (contains cookie) + + ClientHello ------> + (with cookie) + + [Rest of handshake] + + + + + +Rescorla, Modadugu [Page 12] + + + 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 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. + + 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 + + + +Rescorla, Modadugu [Page 13] + + + 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 legitimate + clients to 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 to not to perform a cookie exchange. + The default SHOULD be that the exchange is performed, however. + In addition, the server MAY choose not do to 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; + 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; + + + +Rescorla, Modadugu [Page 14] + + + } 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 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). + + + + + + +Rescorla, Modadugu [Page 15] + + +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 + range 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 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 [Page 16] + + + 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 [Page 17] + + + +-----------+ + | 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. + + In the PREPARING state the implementation does whatever + computations are necessary to prepare the next flight of + + + +Rescorla, Modadugu [Page 18] + + + 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, 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 value choices are the choice of the + implementation, mishandling of the timer can lead to serious + congestion problems, for example if many instances of a DTLS + + + +Rescorla, Modadugu [Page 19] + + + time out early and retransmit too quickly on a congested link. + Implementations SHOULD use an initial timer value of 1 second + (the minimum defined in RFC 2988 [RFC2988]) and double the + value at each retransmission, up to no less than the 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 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. + + + +A.1Summary of new syntax + + + + + +Rescorla, Modadugu [Page 20] + + + This section includes specifications for the data structures + that have changed between TLS 1.1 and DTLS. + +4.2. 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. 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 + + + +Rescorla, Modadugu [Page 21] + + + uint24 fragment_offset; // New field + uint24 fragment_length; // New field + 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 { + 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 [Page 22] + + +6. 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 is to be allocated from the + TLS HandshakeType registry defined in [TLS11]. The value "3" + is suggested. + +References + +Normative References + + [RFC1191] Mogul, J. C., Deering, S.E., "Path MTU Discovery", + RFC 1191, November 1990. + + [RFC1981] J. McCann, S. Deering, J. Mogul, "Path MTU Discovery + for IP version 6", RFC1981, August 1996. + + [RFC2401] Kent, S., Atkinson, R., "Security Architecture for the + Internet Protocol", RFC2401, November 1998. + + [RFC2988] Paxson, V., Allman, M., "Computing TCP's Retransmission + Timer", RFC 2988, November 2000. + + [TCP] Postel, J., "Transmission Control Protocol", + RFC 793, September 1981. + + [TLS11] Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1", + draft-ietf-tls-rfc2246-bis-05.txt, July 2003. + + +Informative References + + [AESCACHE] Bernstein, D.J., "Cache-timing attacks on AES" + http://cr.yp.to/antiforgery/cachetiming-20050414.pdf. + + [AH] Kent, S., and Atkinson, R., "IP Authentication Header", + RFC 2402, November 1998. + + [DCCP] Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram + Congestion Control Protocol", draft-ietf-dccp-spec-11.txt, + 10 March 2005 + + [DNS] Mockapetris, P.V., "Domain names - implementation and + + + +Rescorla, Modadugu [Page 23] + + + specification", 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 Atkinson, R., "IP Encapsulating Security + Payload (ESP)", RFC 2406, November 1998. + + + [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", + RFC 2409, November 1998. + + [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", + draft-ietf-ipsec-ikev2-17.txt, September 2004. + + [IMAP] Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 3501, March 2003. + + [PHOTURIS] Karn, P., Simpson, W., "Photuris: Session-Key Management + Protocol", RFC 2521, March 1999. + + + [POP] Myers, J., and Rose, M., "Post Office Protocol - + Version 3", RFC 1939, May 1996. + + + [REQ] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [SCTP] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, + T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson, + Stream Control Transmission Protocol", RFC 2960, + October 2000. + + [SIP] Rosenberg, J., Schulzrinne, Camarillo, G., Johnston, A., + Peterson, J., Sparks, R., Handley, M., Schooler, E., + "SIP: Session Initiation Protocol", RFC 3261, + June 2002. + + [TLS] Dierks, T., and Allen, C., "The TLS Protocol Version 1.0", + RFC 2246, January 1999. + + [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", + draft-bellovin-useipsec-02.txt, October 2003 + +Authors' Address + + + + + +Rescorla, Modadugu [Page 24] + + + Eric Rescorla + RTFM, Inc. + 2064 Edgewood Drive + Palo Alto, CA 94303 + + Nagendra Modadugu + Computer Science Department + 353 Serra Mall + Stanford University + Stanford, CA 94305 + + + +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. + + + + + + + + + + + + + + + + + + + + + + + + + + +Rescorla, Modadugu [Page 25] + + +Full Copyright Statement + + 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. + +Copyright Notice + Copyright (C) The Internet Society (2003). 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. + + + + + + + + + + + + + + + +Rescorla, Modadugu [Page 26] +