< draft-rescorla-dtls-04.txt   draft-rescorla-dtls-05.txt >
E. Rescorla
E. Rescorla
RTFM, Inc. RTFM, Inc.
N. Modadugu N. Modadugu
INTERNET-DRAFT Stanford University INTERNET-DRAFT Stanford University
<draft-rescorla-dtls-04.txt> April 2004 (Expires October 2005) <draft-rescorla-dtls-05.txt> June 2004 (Expires December 2005)
Datagram Transport Layer Security Datagram Transport Layer Security
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 1, line 35 skipping to change at page 1, line 36
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999-2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
This document specifies Version 1.0 of the Datagram Transport This document specifies Version 1.0 of the Datagram Transport
Layer Security (DTLS) protocol. The DTLS protocol provides Layer Security (DTLS) protocol. The DTLS protocol provides
communications privacy for datagram protocols. The protocol communications privacy for datagram protocols. The protocol
allows client/server applications to communicate in a way that allows client/server applications to communicate in a way that
is designed to prevent eavesdropping, tampering, or message is designed to prevent eavesdropping, tampering, or message
forgery. The DTLS protocol is based on the TLS protocol and forgery. The DTLS protocol is based on the TLS protocol and
provides equivalent security guarantees. Datagram semantics of provides equivalent security guarantees. Datagram semantics of
skipping to change at page 2, line 31 skipping to change at page 2, line 31
3 Overview of DTLS 4 3 Overview of DTLS 4
3.1 Loss-insensitive messaging 4 3.1 Loss-insensitive messaging 4
3.2 Providing Reliability for Handshake 5 3.2 Providing Reliability for Handshake 5
3.2.1 Packet Loss 5 3.2.1 Packet Loss 5
3.2.2 Reordering 6 3.2.2 Reordering 6
3.2.3 Message Size 6 3.2.3 Message Size 6
3.3 Replay Detection 6 3.3 Replay Detection 6
4 Differences from TLS 6 4 Differences from TLS 6
4.1 Record Layer 7 4.1 Record Layer 7
4.1.1 Transport Layer Mapping 8 4.1.1 Transport Layer Mapping 8
4.1.1.1 PMTU Discovery 8 4.1.1.1 PMTU Discovery 9
4.1.2 Record payload protection 9 4.1.2 Record payload protection 9
4.1.2.1 MAC 9 4.1.2.1 MAC 10
4.1.2.2 Null or standard stream cipher 9 4.1.2.2 Null or standard stream cipher 10
4.1.2.3 Block Cipher 10 4.1.2.3 Block Cipher 10
4.1.2.4 New Cipher Suites 10 4.1.2.4 New Cipher Suites 10
4.1.2.5 Anti-Replay 10 4.1.2.5 Anti-Replay 10
4.2 The DTLS Handshake Protocol 11 4.2 The DTLS Handshake Protocol 11
4.2.1 Denial of Service Countermeasures 11 4.2.1 Denial of Service Countermeasures 12
4.2.2 Handshake Message Format 13 4.2.2 Handshake Message Format 14
4.2.3 Message Fragmentation and Reassembly 15 4.2.3 Message Fragmentation and Reassembly 16
4.2.4 Timeout and Retransmission 16 4.2.4 Timeout and Retransmission 16
4.2.4.1 Timer Values 19 4.2.4.1 Timer Values 19
4.2.5 ChangeCipherSpec 20 4.2.5 ChangeCipherSpec 20
4.2.6 Finished messages 20 4.2.6 Finished messages 20
4.2.7 Alert Messages 20 4.2.7 Alert Messages 20
4.2 Record Layer 20 4.2 Record Layer 21
4.3 Handshake Protocol 21 4.3 Handshake Protocol 21
5 Security Considerations 22 5 Security Considerations 22
6 IANA Considerations 22 6 IANA Considerations 23
1. Introduction 1. Introduction
TLS [TLS] is the most widely deployed protocol for securing TLS [TLS] is the most widely deployed protocol for securing
network traffic. It is widely used for protecting Web traffic network traffic. It is widely used for protecting Web traffic
and for e-mail protocols such as IMAP [IMAP] and POP [POP]. and for e-mail protocols such as IMAP [IMAP] and POP [POP].
The primary advantage of TLS is that it provides a transparent The primary advantage of TLS is that it provides a transparent
connection-oriented channel. Thus, it is easy to secure an connection-oriented channel. Thus, it is easy to secure an
application protocol by inserting TLS between the application application protocol by inserting TLS between the application
layer and the transport layer. However, TLS must run over a layer and the transport layer. However, TLS must run over a
reliable transport channel--typically TCP [TCP]. It therefore reliable transport channel--typically TCP [TCP]. It therefore
cannot be used to secure unreliable datagram traffic. cannot be used to secure unreliable datagram traffic.
However, over the past few years an increasing number of However, over the past few years an increasing number of
application layer protocols have been designed which UDP application layer protocols have been designed which use UDP
transport. In particular such protocols as the Session transport. In particular such protocols as the Session
Initiation Protocol (SIP) [SIP], and electronic gaming Initiation Protocol (SIP) [SIP], and electronic gaming
protocols are increasingly popular. (Note that SIP can run protocols are increasingly popular. (Note that SIP can run
over both TCP and UDP, but that there are situations in which over both TCP and UDP, but that there are situations in which
UDP is preferable). Currently, designers of these applications UDP is preferable). Currently, designers of these applications
are faced with a number of unsatisfactory choices. First, they are faced with a number of unsatisfactory choices. First, they
can use IPsec [RFC2401]. However, for a number of reasons can use IPsec [RFC2401]. However, for a number of reasons
detailed in [WHYIPSEC], this is only suitable for some detailed in [WHYIPSEC], this is only suitable for some
applications. Second, they can design a custom application applications. Second, they can design a custom application
layer security protocol. SIP, for instance, uses a subsert of layer security protocol. SIP, for instance, uses a subset of
S/MIME to secure its traffic. Unfortunately, while application S/MIME to secure its traffic. Unfortunately, while application
layer security protocols generally provide superior security layer security protocols generally provide superior security
properties (e.g., end-to-end security in the case of S/MIME) properties (e.g., end-to-end security in the case of S/MIME)
it typically require a large amount of effort to design--by it typically requires a large amount of effort to design--by
contrast to the relatively small amount of effort required to contrast to the relatively small amount of effort required to
run the protocol over TLS. run the protocol over TLS.
In many cases, the most desirable way to secure client/server In many cases, the most desirable way to secure client/server
applications would be to use TLS; however the requirement for applications would be to use TLS; however the requirement for
datagram semantics automatically prohibits use of TLS. Thus, a datagram semantics automatically prohibits use of TLS. Thus, a
datagram-compatible variant of TLS would be very desirable. datagram-compatible variant of TLS would be very desirable.
This memo describes such a protocol: Datagram Transport Layer This memo describes such a protocol: Datagram Transport Layer
Security (DTLS). DTLS is deliberately designed to be as Security (DTLS). DTLS is deliberately designed to be as
similar to to TLS as possible, both to minimize new security similar to to TLS as possible, both to minimize new security
skipping to change at page 6, line 48 skipping to change at page 6, line 48
but can also occur due to routing errors. Applications may but can also occur due to routing errors. Applications may
conceivably detect duplicate packets and accordingly modify conceivably detect duplicate packets and accordingly modify
their data transmission strategy. their data transmission strategy.
4. Differences from TLS 4. Differences from TLS
As mentioned in Section 3., DTLS is intentionally very similar As mentioned in Section 3., DTLS is intentionally very similar
to TLS. Therefore, instead of presenting DTLS as a new to TLS. Therefore, instead of presenting DTLS as a new
protocol, we instead present it as a series of deltas from TLS protocol, we instead present it as a series of deltas from TLS
1.1 [TLS11]. Where we do not explicitly call out differences, 1.1 [TLS11]. Where we do not explicitly call out differences,
DTLS is the same as TLS. DTLS is the same as in [TLS11].
4.1. Record Layer 4.1. Record Layer
The DTLS record layer is extremely similar to that of TLS 1.1. The DTLS record layer is extremely similar to that of TLS 1.1.
The only change is the inclusion of an explicit sequence The only change is the inclusion of an explicit sequence
number in the record. This sequence number allows the number in the record. This sequence number allows the
recipient to correctly verify the TLS MAC. The DTLS record recipient to correctly verify the TLS MAC. The DTLS record
format is shown below: format is shown below:
struct { struct {
skipping to change at page 8, line 35 skipping to change at page 8, line 35
per-record overhead). If the application attempts to send a per-record overhead). If the application attempts to send a
record larger than the MTU the DTLS implementation SHOULD record larger than the MTU the DTLS implementation SHOULD
generate an error, thus avoiding sending a packet which will generate an error, thus avoiding sending a packet which will
be fragmented. be fragmented.
Note that unlike IPsec, DTLS records do not contain any Note that unlike IPsec, DTLS records do not contain any
association identifiers. Applications must arrange to association identifiers. Applications must arrange to
multiplex between associations. With UDP, this is presumably multiplex between associations. With UDP, this is presumably
done with host/port number. done with host/port number.
Multiple DTLS records may be placed in a single datagram. hey Multiple DTLS records may be placed in a single datagram. They
are simply encoded consecutively. The DTLS record framing is are simply encoded consecutively. The DTLS record framing is
sufficient to determine the boundaries. Note, however, that sufficient to determine the boundaries. Note, however, that
the first byte of the datagram payload must be the beginning the first byte of the datagram payload must be the beginning
of a record. Records may not span datagrams. of a record. Records may not span datagrams.
Some transports, such as DCCP [DCCP] provide their own
sequence numbers. When carried over those transports, both the
DTLS and the transport sequence numbers will be present.
Although this introduces a small amount of inefficiency, the
transport layer and DTLS sequence numbers serve different
purposes and therefore for conceptual simplicity it is
superior to use both sequence numbers. In the future,
extensions to DTLS may be specified that allow the use of only
one set of sequence numbers for deployment in constrained
environments.
Some transports, such as DCCP, provide congestion control
for traffic carried over them. If the congestion window is
sufficiently narrow, DTLS handshake retransmissions may be
held rather than transmitted immediately, potentially leading
to timeouts and spurious retransmission. When DTLS is used
over such transports, care should be taken not to overrun the
likely congestion window. In the future, a DTLS-DCCP mapping
may be specificied to provide optimal behavior for this
interaction.
4.1.1.1. PMTU Discovery 4.1.1.1. PMTU Discovery
In general, DTLS's philosophy is to avoid dealing with PMTU In general, DTLS's philosophy is to avoid dealing with PMTU
issues. The general strategy is to start with a conservative issues. The general strategy is to start with a conservative
MTU and then update it if events require it, but not actively MTU and then update it if events during the handshake or
probe for MTU values. PMTU discovery is left to the actual application data transport phase require it.
application.
The PMTU SHOULD be initialized from the interface MTU that The PMTU SHOULD be initialized from the interface MTU that
will be used to send packets. If the DTLS implementation will be used to send packets. If the DTLS implementation
receives an RFC 1191 [RFC1191] ICMP Destination Unreachable receives an RFC 1191 [RFC1191] ICMP Destination Unreachable
message with the "fragmentation needed and DF set" Code message with the "fragmentation needed and DF set" Code
(otherwise known as Datagram Too Big) it should decrease its (otherwise known as Datagram Too Big) it should decrease its
PMTU estimate to that given in the ICMP message. A DTLS PMTU estimate to that given in the ICMP message. A DTLS
implementation SHOULD allow the application to occasionally implementation SHOULD allow the application to occasionally
reset its PMTU estimate. The DTLS implementation SHOULD also reset its PMTU estimate. The DTLS implementation SHOULD also
allow applications to control the status of the DF bit. These allow applications to control the status of the DF bit. These
controls allow the application to perform PMTU discovery. 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 One special case is the DTLS handshake system. Handshake
messages should be set with DF set. Because some firewalls and messages should be set with DF set. Because some firewalls and
routers screen out ICMP messages, it is difficult for the routers screen out ICMP messages, it is difficult for the
handshake layer to distinguish packet loss from an overlarge handshake layer to distinguish packet loss from an overlarge
PMTU estimate. In order to allow connections under these PMTU estimate. In order to allow connections under these
circumstances, DTLS implementations SHOULD back off handshake circumstances, DTLS implementations SHOULD back off handshake
packet size during the retransmit backoff described in Section packet size during the retransmit backoff described in Section
4.2.4.. For instance, if a large packet is being sent, after 3 4.2.4.. For instance, if a large packet is being sent, after 3
retransmits the handshake layer might choose to fragment the retransmits the handshake layer might choose to fragment the
skipping to change at page 9, line 44 skipping to change at page 10, line 20
concatenating the epoch and the sequence number in the order concatenating the epoch and the sequence number in the order
they appear on the wire. Note that the DTLS epoch + sequence they appear on the wire. Note that the DTLS epoch + sequence
number is the same length as the TLS sequence number. number is the same length as the TLS sequence number.
Note that one important difference between DTLS and TLS MAC Note that one important difference between DTLS and TLS MAC
handling is that in TLS MAC errors must result in connection handling is that in TLS MAC errors must result in connection
termination. In DTLS, the receiving implementation MAY simply termination. In DTLS, the receiving implementation MAY simply
discard the offending record and continue with the connection. discard the offending record and continue with the connection.
This change is possible because DTLS records are not dependent This change is possible because DTLS records are not dependent
on each other the way that TLS records are. 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 4.1.2.2. Null or standard stream cipher
The DTLS NULL cipher is performed exactly as the TLS 1.1 NULL The DTLS NULL cipher is performed exactly as the TLS 1.1 NULL
cipher. cipher.
The only stream cipher described in TLS 1.1 is RC4, which The only stream cipher described in TLS 1.1 is RC4, which
cannot be randomly accessed. RC4 MUST NOT be used with DTLS. cannot be randomly accessed. RC4 MUST NOT be used with DTLS.
4.1.2.3. Block Cipher 4.1.2.3. Block Cipher
skipping to change at page 10, line 23 skipping to change at page 10, line 49
4.1.2.4. New Cipher Suites 4.1.2.4. New Cipher Suites
Upon registration, new TLS cipher suites MUST indicate whether Upon registration, new TLS cipher suites MUST indicate whether
they are suitable for DTLS usage and what, if any, adaptations they are suitable for DTLS usage and what, if any, adaptations
must be made. must be made.
4.1.2.5. Anti-Replay 4.1.2.5. Anti-Replay
DTLS records contain a sequence number to provide replay DTLS records contain a sequence number to provide replay
protection. Sequence number verification SHOULD be performed protection. Sequence number verification SHOULD be performed
using the following sliding, window procedure, borrowed from using the following sliding window procedure, borrowed from
Section 3.4.3 of [RFC 2402] Section 3.4.3 of [RFC 2402].
The receiver packet counter for this session MUST be The receiver packet counter for this session MUST be
initialized to zero when the session is established. For each initialized to zero when the session is established. For each
received record, the receiver MUST verify that the record received record, the receiver MUST verify that the record
contains a Sequence Number that does not duplicate the contains a Sequence Number that does not duplicate the
Sequence Number of any other record received during the life Sequence Number of any other record received during the life
of this session. This SHOULD be the first check applied to a of this session. This SHOULD be the first check applied to a
packet after it has been matched to a session, to speed packet after it has been matched to a session, to speed
rejection of duplicate records. rejection of duplicate records.
skipping to change at page 12, line 22 skipping to change at page 13, line 4
------ ------ ------ ------
ClientHello ------> ClientHello ------>
<----- HelloVerifyRequest <----- HelloVerifyRequest
(contains cookie) (contains cookie)
ClientHello ------> ClientHello ------>
(with cookie) (with cookie)
[Rest of handshake] [Rest of handshake]
DTLS therefore modifies the ClientHello message to add the DTLS therefore modifies the ClientHello message to add the
cookie value. cookie value.
struct { struct {
ProtocolVersion client_version; ProtocolVersion client_version;
Random random; Random random;
SessionID session_id; SessionID session_id;
opaque cookie<0..32>; // New field opaque cookie<0..32>; // New field
CipherSuite cipher_suites<2..2^16-1>; CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>; CompressionMethod compression_methods<1..2^8-1>;
} ClientHello; } ClientHello;
When sending the first ClientHello, the client does not have a When sending the first ClientHello, the client does not have a
cookie yet; in this case, the Cookie field is left empty (zero cookie yet; in this case, the Cookie field is left empty (zero
length). length).
The definition of HelloVerifyRequest is as follows: The definition of HelloVerifyRequest is as follows:
struct { struct {
Cookie cookie<0..32>; ProtocolVersion server_version;
opaque cookie<0..32>;
} HelloVerifyRequest; } HelloVerifyRequest;
The HelloVerifyRequest message type is The HelloVerifyRequest message type is
hello_verify_request(3). hello_verify_request(3).
The server_version field is defined as in TLS.
When responding to a HelloVerifyRequest the client MUST use When responding to a HelloVerifyRequest the client MUST use
the same parameter values (version, random, session_id, the same parameter values (version, random, session_id,
cipher_suites, compression_method) as in the original cipher_suites, compression_method) as in the original
ClientHello. The server SHOULD use those values to generate ClientHello. The server SHOULD use those values to generate
its cookie and verify that they are correct upon cookie its cookie and verify that they are correct upon cookie
receipt. The DTLS server SHOULD generate cookies in such a way receipt. The server MUST use the same version number in the
that they can be verified without retaining any per-client HelloVerifyRequest that it would use when sending a
state on the server. One technique is to have a randomly ServerHello. Upon receipt of the ServerHello, the client MUST
generated secret and generate cookies as: 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) Cookie = HMAC(Secret, Client-IP, Client-Parameters)
When the second ClientHello is received, the server can verify When the second ClientHello is received, the server can verify
that the Cookie is valid and that the client can receive that the Cookie is valid and that the client can receive
packets at the given IP address. packets at the given IP address.
One potential attack on this scheme is for the attacker to One potential attack on this scheme is for the attacker to
collect a number of cookies from different addresses and then collect a number of cookies from different addresses and then
reuse them to attack the server. The server can defend against reuse them to attack the server. The server can defend against
this attack by changing the Secret value frequently, thus this attack by changing the Secret value frequently, thus
invalidating those cookies. If the server wishes legitimate invalidating those cookies. If the server wishes legitimate
clients to be able to handshake through the transition (e.g., clients to be able to handshake through the transition (e.g.,
they received a cookie with Secret 1 and then sent the second they received a cookie with Secret 1 and then sent the second
ClientHello after the server has changed to Secret 2), the ClientHello after the server has changed to Secret 2), the
server can have a limited window during which it accepts both server can have a limited window during which it accepts both
secrets. [IKEv2] suggests adding a version number to cookies secrets. [IKEv2] suggests adding a version number to cookies
to detect this case. An alternative approach is simply to try to detect this case. An alternative approach is simply to try
verifying with both secrets. verifying with both secrets.
Although DTLS servers are not required to do a cookie DTLS servers SHOULD perform a cookie exchange whenever a new
exchange, they SHOULD do so whenever a new handshake is handshake is being performed. If the server is being operated
performed in order to avoid being used as amplifiers. If the in an environment where amplification is not a problem, the
server is being operated in an environment where amplification server MAY be configured to not to perform a cookie exchange.
is not a problem, the server MAY choose not to perform a The default SHOULD be that the exchange is performed, however.
cookie exchange. In addition, the server MAY choose not do to In addition, the server MAY choose not do to a cookie exchange
a cookie exchange when a session is resumed. Clients MUST be when a session is resumed. Clients MUST be prepared to do a
prepared to do a cookie exchange with every handshake. cookie exchange with every handshake.
If HelloVerifyRequest is used, the initial ClientHello and If HelloVerifyRequest is used, the initial ClientHello and
HelloVerifyRequest are not included in the calculation of the HelloVerifyRequest are not included in the calculation of the
verify_data for the Finished message. verify_data for the Finished message.
4.2.2. Handshake Message Format 4.2.2. Handshake Message Format
In order to support message loss, reordering, and In order to support message loss, reordering, and
fragmentation DTLS modifies the TLS 1.1 handshake header: fragmentation DTLS modifies the TLS 1.1 handshake header:
skipping to change at page 17, line 4 skipping to change at page 17, line 43
ClientHello --------> Flight 1 ClientHello --------> Flight 1
ServerHello \ ServerHello \
[ChangeCipherSpec] Flight 2 [ChangeCipherSpec] Flight 2
<-------- Finished / <-------- Finished /
[ChangeCipherSpec] \Flight 3 [ChangeCipherSpec] \Flight 3
Finished --------> / Finished --------> /
Figure 2: Message flights for session resuming handshake (no Figure 2: Message flights for session resuming handshake (no
cookie exchange) cookie exchange)
DTLS uses a simple timeout and retransmission scheme with the DTLS uses a simple timeout and retransmission scheme with the
following state machine. Because DTLS clients send the first following state machine. Because DTLS clients send the first
message (ClientHello) they start in the PREPARING state. DTLS message (ClientHello) they start in the PREPARING state. DTLS
servers start in the WAITING state, but with empty buffers and servers start in the WAITING state, but with empty buffers and
no retransmit timer. no retransmit timer.
+-----------+ +-----------+
| PREPARING | | PREPARING |
+---> | | +---> | | <--------------------+
| | | | | | |
| +-----------+ | +-----------+ |
| | | | |
| | | | |
| | Buffer next flight | | Buffer next flight |
| | | | |
| \|/ | \|/ |
| +-----------+ | +-----------+ |
| | | | | | |
| | SENDING |<------------------+ | | SENDING |<------------------+ |
| | | | | | | | | Send
| +-----------+ | | +-----------+ | | HelloRequest
Receive | | | Receive | | | |
next | | Send flight | next | | Send flight | | or
flight | +--------+ | flight | +--------+ | |
| | | Set retransmit timer | | | | Set retransmit timer | | Receive
| | \|/ | | | \|/ | | HelloRequest
| | +-----------+ | | | +-----------+ | | Send
| | | | | | | | | | | ClientHello
+--)--| WAITING |-------------------+ +--)--| WAITING |-------------------+ |
| | | | Timer expires | | | | | Timer expires | |
| | +-----------+ | | | +-----------+ | |
| | | | | | | | |
| | | | | | | | |
| | +------------------------+ | | +------------------------+ |
| | Read retransmit | | Read retransmit |
Receive | | Receive | | |
last | | last | | |
flight | | flight | | |
| | | | |
\|/\|/ \|/\|/ |
|
+-----------+ +-----------+ |
| | | | |
| FINISHED | | FINISHED | -------------------------------+
| | | |
+-----------+ +-----------+
Figure 3: DTLS timeout and retransmission state machine Figure 3: DTLS timeout and retransmission state machine
The state machine has three basic states. The state machine has three basic states.
In the PREPARING state the implementation does whatever In the PREPARING state the implementation does whatever
computations are necessary to prepare the next flight of computations are necessary to prepare the next flight of
messages. It then buffers them up for transmission (emptying messages. It then buffers them up for transmission (emptying
the buffer first) and enters the SENDING state. the buffer first) and enters the SENDING state.
In the SENDING state, the implementation transmits the In the SENDING state, the implementation transmits the
buffered flight of messages. Once the messages have been sent, buffered flight of messages. Once the messages have been sent,
skipping to change at page 19, line 41 skipping to change at page 19, line 41
transitions to FINISHED. If the implementation needs to transitions to FINISHED. If the implementation needs to
send a new flight, it transitions to the PREPARING state. send a new flight, it transitions to the PREPARING state.
Partial reads (whether partial messages or only some of the Partial reads (whether partial messages or only some of the
messages in the flight) do not cause state transitions or messages in the flight) do not cause state transitions or
timer resets. timer resets.
Because DTLS clients send the first message (ClientHello) they Because DTLS clients send the first message (ClientHello) they
start in the PREPARING state. DTLS servers start in the start in the PREPARING state. DTLS servers start in the
WAITING state, but with empty buffers and no retransmit timer. 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 4.2.4.1. Timer Values
Timer value choices are a local matter. Implementations SHOULD Though timer value choices are the choice of the
use an initial timer value of 500 ms and double the value at implementation, mishandling of the timer can lead to serious
each retransmission, up to twice the TCP maximum segment congestion problems, for example if many instances of a DTLS
lifetime [TCP] (if the recommendations in [TCP] are followed, time out early and retransmit too quickly on a congested link.
this will be 240 seconds). Implementations SHOULD start the Implementations SHOULD use an initial timer value of 1 second
timer value at the initial value with each new flight of (the minimum defined in RFC 2988 [RFC2988]) and double the
messages. 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 4.2.5. ChangeCipherSpec
As with TLS, the ChangeCipherSpec message is not technically a As with TLS, the ChangeCipherSpec message is not technically a
handshake message but MUST be treated as part of the same handshake message but MUST be treated as part of the same
flight as the associated Finished message for the purposes of flight as the associated Finished message for the purposes of
timeout and retransmission. timeout and retransmission.
4.2.6. Finished messages 4.2.6. Finished messages
Finished messages have the same format as in TLS. However, in Finished messages have the same format as in TLS. However, in
order to remove sensitivity to fragmentation, the Finished MAC order to remove sensitivity to fragmentation, the Finished MAC
MUST be computed as if each handshake message had been sent as MUST be computed as if each handshake message had been sent as
a single fragment. Note that in cases where the cookie a single fragment. Note that in cases where the cookie
exchange is used, the initial ClientHello and exchange is used, the initial ClientHello and
HelloVerifyRequest MUST BE included in the Finished MAC. HelloVerifyRequest MUST NOT included in the Finished MAC.
4.2.7. Alert Messages 4.2.7. Alert Messages
Note that Alert messages are not retransmitted at all, even Note that Alert messages are not retransmitted at all, even
when they occur in the context of a handshake. However, a DTLS when they occur in the context of a handshake. However, a DTLS
implementation SHOULD generate a new alert message if the implementation SHOULD generate a new alert message if the
offending record is received again (e.g., as a retransmitted offending record is received again (e.g., as a retransmitted
handshake message). 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 A.1Summary of new syntax
This section includes specifications for the data structures This section includes specifications for the data structures
that have changed between TLS 1.1 and DTLS. that have changed between TLS 1.1 and DTLS.
4.2. Record Layer 4.2. Record Layer
struct { struct {
ContentType type; ContentType type;
ProtocolVersion version; ProtocolVersion version;
uint16 epoch; // New field uint16 epoch; // New field
uint48 sequence_number; // New field uint48 sequence_number; // New field
uint16 length; uint16 length;
skipping to change at page 22, line 11 skipping to change at page 22, line 31
struct { struct {
ProtocolVersion client_version; ProtocolVersion client_version;
Random random; Random random;
SessionID session_id; SessionID session_id;
opaque cookie<0..32>; // New field opaque cookie<0..32>; // New field
CipherSuite cipher_suites<2..2^16-1>; CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>; CompressionMethod compression_methods<1..2^8-1>;
} ClientHello; } ClientHello;
struct { struct {
Cookie cookie<0..32>; opaque cookie<0..32>;
} HelloVerifyRequest; } HelloVerifyRequest;
5. Security Considerations 5. Security Considerations
This document describes a variant of TLS 1.1 and therefore This document describes a variant of TLS 1.1 and therefore
most of the security considerations are the same as those of most of the security considerations are the same as those of
TLS 1.1 [TLS11], described in Appendices D, E, and F. TLS 1.1 [TLS11], described in Appendices D, E, and F.
The primary additional security consideration raised by DTLS The primary additional security consideration raised by DTLS
is that of denial of service. DTLS includes a cookie exchange is that of denial of service. DTLS includes a cookie exchange
designed to protect against denial of service. However, designed to protect against denial of service. However,
implementations which do not use this cookie exchange are implementations which do not use this cookie exchange are
still vulnerable to DoS. In particular, DTLS servers which do still vulnerable to DoS. In particular, DTLS servers which do
not use the cookie exchange may be used as attack amplifiers not use the cookie exchange may be used as attack amplifiers
even if they themselves are not experiencing DoS. Therefore even if they themselves are not experiencing DoS. Therefore
DTLS servers SHOULD use the cookie exchange unless there is DTLS servers SHOULD use the cookie exchange unless there is
good reason to believe that amplification is not a threat in good reason to believe that amplification is not a threat in
their environment. their environment. Clients MUST be prepared to do a cookie
exchange with every handshake.
6. IANA Considerations 6. IANA Considerations
This document uses the same identifier space as TLS [TLS11], This document uses the same identifier space as TLS [TLS11],
so no new IANA registries are required. When new identifiers so no new IANA registries are required. When new identifiers
are assigned for TLS, authors MUST specify whether they are are assigned for TLS, authors MUST specify whether they are
suitable for DTLS. suitable for DTLS.
This document defines a new handshake message, This document defines a new handshake message,
hello_verify_request, whose value is to be allocated from the hello_verify_request, whose value is to be allocated from the
TLS HandshakeType registry defined in [TLS11]. The value "3" TLS HandshakeType registry defined in [TLS11]. The value "3"
is suggested. is suggested.
References References
Normative References Normative References
[RFC1191] Mogul, J. C., Deering, S.E., "Path MTU Discovery", [RFC1191] Mogul, J. C., Deering, S.E., "Path MTU Discovery",
RFC 1191, November 1990. 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 [RFC2401] Kent, S., Atkinson, R., "Security Architecture for the
Internet Protocol", RFC2401, November 1998. 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", [TCP] Postel, J., "Transmission Control Protocol",
RFC 793, September 1981. RFC 793, September 1981.
[TLS11] Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1", [TLS11] Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1",
draft-ietf-tls-rfc2246-bis-05.txt, July 2003. draft-ietf-tls-rfc2246-bis-05.txt, July 2003.
Informative References 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", [AH] Kent, S., and Atkinson, R., "IP Authentication Header",
RFC 2402, November 1998. RFC 2402, November 1998.
[DCCP] Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram [DCCP] Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram
Congestion Control Protocol", draft-ietf-dccp-spec-11.txt, Congestion Control Protocol", draft-ietf-dccp-spec-11.txt,
10 March 2005 10 March 2005
[DNS] Mockapetris, P.V., "Domain names - implementation and [DNS] Mockapetris, P.V., "Domain names - implementation and
specification", RFC 1035, November 1987. specification", RFC 1035, November 1987.
skipping to change at page 23, line 47 skipping to change at page 24, line 30
[PHOTURIS] Karn, P., Simpson, W., "Photuris: Session-Key Management [PHOTURIS] Karn, P., Simpson, W., "Photuris: Session-Key Management
Protocol", RFC 2521, March 1999. Protocol", RFC 2521, March 1999.
[POP] Myers, J., and Rose, M., "Post Office Protocol - [POP] Myers, J., and Rose, M., "Post Office Protocol -
Version 3", RFC 1939, May 1996. Version 3", RFC 1939, May 1996.
[REQ] Bradner, S., "Key words for use in RFCs to Indicate [REQ] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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., [SIP] Rosenberg, J., Schulzrinne, Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., Schooler, E., Peterson, J., Sparks, R., Handley, M., Schooler, E.,
"SIP: Session Initiation Protocol", RFC 3261, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[TLS] Dierks, T., and Allen, C., "The TLS Protocol Version 1.0", [TLS] Dierks, T., and Allen, C., "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec",
draft-bellovin-useipsec-02.txt, October 2003 draft-bellovin-useipsec-02.txt, October 2003
skipping to change at page 24, line 15 skipping to change at page 25, line 4
"SIP: Session Initiation Protocol", RFC 3261, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[TLS] Dierks, T., and Allen, C., "The TLS Protocol Version 1.0", [TLS] Dierks, T., and Allen, C., "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec",
draft-bellovin-useipsec-02.txt, October 2003 draft-bellovin-useipsec-02.txt, October 2003
Authors' Address Authors' Address
Eric Rescorla <ekr@rtfm.com> Eric Rescorla <ekr@rtfm.com>
RTFM, Inc. RTFM, Inc.
2064 Edgewood Drive 2064 Edgewood Drive
Palo Alto, CA 94303 Palo Alto, CA 94303
Nagendra Modadugu <nagendra@cs.stanford.edu> Nagendra Modadugu <nagendra@cs.stanford.edu>
Computer Science Department Computer Science Department
353 Serra Mall 353 Serra Mall
Stanford University Stanford University
Stanford, CA 94305 Stanford, CA 94305
Acknowledgements Acknowledgements
The authors would like to thank Dan Boneh, Eu-Jin Goh, Russ The authors would like to thank Dan Boneh, Eu-Jin Goh, Russ
Housley, Constantine Sapuntzakis, and Hovav Shacham for Housley, Constantine Sapuntzakis, and Hovav Shacham for
discussions and comments on the design of DTLS. Thanks to the discussions and comments on the design of DTLS. Thanks to the
anonymous NDSS reviewers of our original NDSS paper on DTLS anonymous NDSS reviewers of our original NDSS paper on DTLS
[DTLS] for their comments. Also, thanks to Steve Kent for [DTLS] for their comments. Also, thanks to Steve Kent for
feedback that helped clarify many points. The section on PMTU feedback that helped clarify many points. The section on PMTU
was cribbed from the DCCP specification [DCCP]. Pasi Eronen was cribbed from the DCCP specification [DCCP]. Pasi Eronen
provided a detailed review of this specification. 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.
Full Copyright Statement Full Copyright Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 39 change blocks. 
91 lines changed or deleted 160 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/