--- /dev/null
+
+ E. Rescorla
+ RTFM, Inc.
+ N. Modadugu
+INTERNET-DRAFT Stanford University
+<draft-rescorla-dtls-05.txt> 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]\f
+
+
+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]\f
+
+
+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]\f
+
+
+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]\f
+
+
+ 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]\f
+
+
+ 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]\f
+
+
+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]\f
+
+
+ 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]\f
+
+
+ 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]\f
+
+
+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]\f
+
+
+ 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]\f
+
+
+ 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]\f
+
+
+ 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]\f
+
+
+ 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]\f
+
+
+ } 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]\f
+
+
+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]\f
+
+
+ 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]\f
+
+
+ +-----------+
+ | 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]\f
+
+
+ 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]\f
+
+
+ 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.1\bSummary of new syntax
+
+
+
+
+
+Rescorla, Modadugu [Page 20]\f
+
+
+ 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]\f
+
+
+ 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]\f
+
+
+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]\f
+
+
+ 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]\f
+
+
+ Eric Rescorla <ekr@rtfm.com>
+ RTFM, Inc.
+ 2064 Edgewood Drive
+ Palo Alto, CA 94303
+
+ Nagendra Modadugu <nagendra@cs.stanford.edu>
+ 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]\f
+
+
+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]\f
+
projects / thirdparty / gnutls.git / commitdiff
