Request for Comments: 4347 RTFM, Inc.
Category: Standards Track N. Modadugu
Stanford University
April 2006
Datagram Transport Layer Security
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document specifies Version 1.0 of the Datagram Transport Layer
Security (DTLS) protocol. The DTLS protocol provides communications
privacy for datagram protocols. The protocol allows client/server
applications to communicate in a way that is designed to prevent
eavesdropping, tampering, or message forgery. The DTLS protocol is
based on the Transport Layer Security (TLS) protocol and provides
equivalent security guarantees. Datagram semantics of the underlying
transport are preserved by the DTLS protocol.
Table of Contents
1. Introduction ....................................................2
1.1. Requirements Terminology ...................................3
2. Usage Model .....................................................3
3. Overview of DTLS ................................................4
3.1. Loss-Insensitive Messaging .................................4
3.2. Providing Reliability for Handshake ........................4
3.2.1. Packet Loss .........................................5
3.2.2. Reordering ..........................................5
3.2.3. Message Size ........................................5
3.3. Replay Detection ...........................................6
4. Differences from TLS ............................................6
4.1. Record Layer ...............................................6
4.1.1. Transport Layer Mapping .............................7
4.1.1.1. PMTU Discovery .............................8
4.1.2. Record Payload Protection ...........................9
4.1.2.1. MAC ........................................9
4.1.2.2. Null or Standard Stream Cipher .............9
4.1.2.3. Block Cipher ..............................10
4.1.2.4. New Cipher Suites .........................10
4.1.2.5. Anti-replay ...............................10
4.2. The DTLS Handshake Protocol ...............................11
4.2.1. Denial of Service Countermeasures ..................11
4.2.2. Handshake Message Format ...........................13
4.2.3. Message Fragmentation and Reassembly ...............15
4.2.4. Timeout and Retransmission .........................15
4.2.4.1. Timer Values ..............................18
4.2.5. ChangeCipherSpec ...................................19
4.2.6. Finished Messages ..................................19
4.2.7. Alert Messages .....................................19
4.3. Summary of new syntax .....................................19
4.3.1. Record Layer .......................................20
4.3.2. Handshake Protocol .................................20
5. Security Considerations ........................................21
6. Acknowledgements ...............................................22
7. IANA Considerations ............................................22
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................23
1. Introduction
TLS [TLS] is the most widely deployed protocol for securing network
traffic. It is widely used for protecting Web traffic and for e-mail
protocols such as IMAP [IMAP] and POP [POP]. The primary advantage
of TLS is that it provides a transparent connection-oriented channel.
Thus, it is easy to secure an application protocol by inserting TLS
between the application layer and the transport layer. However, TLS
must run over a reliable transport channel -- typically TCP [TCP].
It therefore cannot be used to secure unreliable datagram traffic.
However, over the past few years an increasing number of application
layer protocols have been designed that use UDP transport. In
particular protocols such as the Session Initiation Protocol (SIP)
[SIP] and electronic gaming protocols are increasingly popular.
(Note that SIP can run over both TCP and UDP, but that there are
situations in which UDP is preferable). Currently, designers of
these applications are faced with a number of unsatisfactory choices.
First, they can use IPsec [RFC2401]. However, for a number of
reasons detailed in [WHYIPSEC], this is only suitable for some
applications. Second, they can design a custom application layer
security protocol. SIP, for instance, uses a subset of S/MIME to
secure its traffic. Unfortunately, although application layer
security protocols generally provide superior security properties
(e.g., end-to-end security in the case of S/MIME), they typically
requires a large amount of effort to design -- in contrast to the
relatively small amount of effort required to run the protocol over
TLS.
In many cases, the most desirable way to secure client/server
applications would be to use TLS; however, the requirement for
datagram semantics automatically prohibits use of TLS. Thus, a
datagram-compatible variant of TLS would be very desirable. This
memo describes such a protocol: Datagram Transport Layer Security
(DTLS). DTLS is deliberately designed to be as similar to TLS as
possible, both to minimize new security invention and to maximize the
amount of code and infrastructure reuse.
1.1. Requirements Terminology
In this document, the keywords "MUST", "MUST NOT", "REQUIRED",
"SHOULD", "SHOULD NOT", and "MAY" are to be interpreted as described
in RFC 2119 [REQ].
2. Usage Model
The DTLS protocol is designed to secure data between communicating
applications. It is designed to run in application space, without
requiring any kernel modifications.
Datagram transport does not require or provide reliable or in-order
delivery of data. The DTLS protocol preserves this property for
payload data. Applications such as media streaming, Internet
telephony, and online gaming use datagram transport for communication
due to the delay-sensitive nature of transported data. The behavior
of such applications is unchanged when the DTLS protocol is used to
secure communication, since the DTLS protocol does not compensate for
lost or re-ordered data traffic.
3. Overview of DTLS
The basic design philosophy of DTLS is to construct "TLS over
datagram". The reason that TLS cannot be used directly in datagram
environments is simply that packets may be lost or reordered. TLS
has no internal facilities to handle this kind of unreliability, and
therefore TLS implementations break when rehosted on datagram
transport. The purpose of DTLS is to make only the minimal changes
to TLS required to fix this problem. To the greatest extent
possible, DTLS is identical to TLS. Whenever we need to invent new
mechanisms, we attempt to do so in such a way that preserves the
style of TLS.
Unreliability creates problems for TLS at two levels:
1. TLS’s traffic encryption layer does not allow independent
decryption of individual records. If record N is not received,
then record N+1 cannot be decrypted.
2. The TLS handshake layer assumes that handshake messages are
delivered reliably and breaks if those messages are lost.
The rest of this section describes the approach that DTLS uses to
solve these problems.
3.1. Loss-Insensitive Messaging
In TLS’s traffic encryption layer (called the TLS Record Layer),
records are not independent. There are two kinds of inter-record
dependency:
1. Cryptographic context (CBC state, stream cipher key stream) is
chained between records.
2. Anti-replay and message reordering protection are provided by a
MAC that includes a sequence number, but the sequence numbers are
implicit in the records.
The fix for both of these problems is straightforward and well known
from IPsec ESP [ESP]: add explicit state to the records. TLS 1.1
[TLS11] is already adding explicit CBC state to TLS records. DTLS
borrows that mechanism and adds explicit sequence numbers.
3.2. Providing Reliability for Handshake
The TLS handshake is a lockstep cryptographic handshake. Messages
must be transmitted and received in a defined order, and any other
order is an error. Clearly, this is incompatible with reordering and
message loss. In addition, TLS handshake messages are potentially
larger than any given datagram, thus creating the problem of
fragmentation. DTLS must provide fixes for both of these problems.
3.2.1. Packet Loss
DTLS uses a simple retransmission timer to handle packet loss. The
following figure demonstrates the basic concept, using the first
phase of the DTLS handshake:
Client Server
------ ------
ClientHello ------>
X<-- HelloVerifyRequest
(lost)
[Timer Expires]
ClientHello ------>
(retransmit)
Once the client has transmitted the ClientHello message, it expects
to see a HelloVerifyRequest from the server. However, if the
server’s message is lost the client knows that either the ClientHello
or the HelloVerifyRequest has been lost and retransmits. When the
server receives the retransmission, it knows to retransmit. The
server also maintains a retransmission timer and retransmits when
that timer expires.
Note: timeout and retransmission do not apply to the
HelloVerifyRequest, because this requires creating state on the
server.
3.2.2. Reordering
In DTLS, each handshake message is assigned a specific sequence
number within that handshake. When a peer receives a handshake
message, it can quickly determine whether that message is the next
message it expects. If it is, then it processes it. If not, it
queues it up for future handling once all previous messages have been
received.
3.2.3. Message Size
TLS and DTLS handshake messages can be quite large (in theory up to
2^24-1 bytes, in practice many kilobytes). By contrast, UDP
datagrams are often limited to <1500 bytes if fragmentation is not
desired. In order to compensate for this limitation, each DTLS
handshake message may be fragmented over several DTLS records. Each
DTLS handshake message contains both a fragment offset and a fragment
length. Thus, a recipient in possession of all bytes of a handshake
message can reassemble the original unfragmented message.
3.3. Replay Detection
DTLS optionally supports record replay detection. The technique used
is the same as in IPsec AH/ESP, by maintaining a bitmap window of
received records. Records that are too old to fit in the window and
records that have previously been received are silently discarded.
The replay detection feature is optional, since packet duplication is
not always malicious, but can also occur due to routing errors.
Applications may conceivably detect duplicate packets and accordingly
modify their data transmission strategy.
4. Differences from TLS
As mentioned in Section 3, DTLS is intentionally very similar to TLS.
Therefore, instead of presenting DTLS as a new protocol, we present
it as a series of deltas from TLS 1.1 [TLS11]. Where we do not
explicitly call out differences, DTLS is the same as in [TLS11].
4.1. Record Layer
The DTLS record layer is extremely similar to that of TLS 1.1. The
only change is the inclusion of an explicit sequence number in the
record. This sequence number allows the recipient to correctly
verify the TLS MAC. The DTLS record format is shown below:
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch; // New field
uint48 sequence_number; // New field
uint16 length;
opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext;
type
Equivalent to the type field in a TLS 1.1 record.
version
The version of the protocol being employed. This document
describes DTLS Version 1.0, which uses the version { 254, 255
}. The version value of 254.255 is the 1’s complement of DTLS
Version 1.0. This maximal spacing between TLS and DTLS version
numbers ensures that records from the two protocols can be
easily distinguished. It should be noted that future on-the-wire
version numbers of DTLS are decreasing in value (while the true
version number is increasing in value.)
epoch
A counter value that is incremented on every cipher state
change.
sequence_number
The sequence number for this record.
length
Identical to the length field in a TLS 1.1 record. As in TLS
1.1, the length should not exceed 2^14.
fragment
Identical to the fragment field of a TLS 1.1 record.
DTLS uses an explicit sequence number, rather than an implicit one,
carried in the sequence_number field of the record. As with TLS, the
sequence number is set to zero after each ChangeCipherSpec message is
sent.
If several handshakes are performed in close succession, there might
be multiple records on the wire with the same sequence number but
from different cipher states. The epoch field allows recipients to
distinguish such packets. The epoch number is initially zero and is
incremented each time the ChangeCipherSpec messages is sent. In
order to ensure that any given sequence/epoch pair is unique,
implementations MUST NOT allow the same epoch value to be reused
within two times the TCP maximum segment lifetime. In practice, TLS
implementations rarely rehandshake and we therefore do not expect
this to be a problem.
4.1.1. Transport Layer Mapping
Each DTLS record MUST fit within a single datagram. In order to
avoid IP fragmentation [MOGUL], DTLS implementations SHOULD determine
the MTU and send records smaller than the MTU. DTLS implementations
SHOULD provide a way for applications to determine the value of the
PMTU (or, alternately, the maximum application datagram size, which
is the PMTU minus the DTLS per-record overhead). If the application
attempts to send a record larger than the MTU, the DTLS
implementation SHOULD generate an error, thus avoiding sending a
packet which will be fragmented.
Note that unlike IPsec, DTLS records do not contain any association
identifiers. Applications must arrange to multiplex between
associations. With UDP, this is presumably done with host/port
number.
Multiple DTLS records may be placed in a single datagram. They are
simply encoded consecutively. The DTLS record framing is sufficient
to determine the boundaries. Note, however, that the first byte of
the datagram payload must be the beginning of a record. Records may
not span datagrams.
Some transports, such as DCCP [DCCP] provide their own sequence
numbers. When carried over those transports, both the DTLS and the
transport sequence numbers will be present. Although this introduces
a small amount of inefficiency, the transport layer and DTLS sequence
numbers serve different purposes, and therefore for conceptual
simplicity it is superior to use both sequence numbers. In the
future, extensions to DTLS may be specified that allow the use of
only one set of sequence numbers for deployment in constrained
environments.
Some transports, such as DCCP, provide congestion control for traffic
carried over them. If the congestion window is sufficiently narrow,
DTLS handshake retransmissions may be held rather than transmitted
immediately, potentially leading to timeouts and spurious
retransmission. When DTLS is used over such transports, care should
be taken not to overrun the likely congestion window. In the future,
a DTLS-DCCP mapping may be specified to provide optimal behavior for
this interaction.
4.1.1.1. PMTU Discovery
In general, DTLS’s philosophy is to avoid dealing with PMTU issues.
The general strategy is to start with a conservative MTU and then
update it if events during the handshake or actual application data
transport phase require it.
The PMTU SHOULD be initialized from the interface MTU that will be
used to send packets. If the DTLS implementation receives an RFC
1191 [RFC1191] ICMP Destination Unreachable message with the
"fragmentation needed and DF set" Code (otherwise known as Datagram
Too Big), it should decrease its PMTU estimate to that given in the
ICMP message. A DTLS implementation SHOULD allow the application to
occasionally reset its PMTU estimate. The DTLS implementation SHOULD
also allow applications to control the status of the DF bit. These
controls allow the application to perform PMTU discovery. RFC 1981
[RFC1981] procedures SHOULD be followed for IPv6.
One special case is the DTLS handshake system. Handshake messages
should be set with DF set. Because some firewalls and routers screen
out ICMP messages, it is difficult for the handshake layer to
distinguish packet loss from an overlarge PMTU estimate. In order to
allow connections under these circumstances, DTLS implementations
SHOULD back off handshake packet size during the retransmit backoff
described in Section 4.2.4. For instance, if a large packet is being
sent, after 3 retransmits the handshake layer might choose to
fragment the handshake message on retransmission. In general, choice
of a conservative initial MTU will avoid this problem.
4.1.2. Record Payload Protection
Like TLS, DTLS transmits data as a series of protected records. The
rest of this section describes the details of that format.
4.1.2.1. MAC
The DTLS MAC is the same as that of TLS 1.1. However, rather than
using TLS’s implicit sequence number, the sequence number used to
compute the MAC is the 64-bit value formed by concatenating the epoch
and the sequence number in the order they appear on the wire. Note
that the DTLS epoch + sequence number is the same length as the TLS
sequence number.
TLS MAC calculation is parameterized on the protocol version number,
which, in the case of DTLS, is the on-the-wire version, i.e., {254,
255 } for DTLS 1.0.
Note that one important difference between DTLS and TLS MAC handling
is that in TLS MAC errors must result in connection termination. In
DTLS, the receiving implementation MAY simply discard the offending
record and continue with the connection. This change is possible
because DTLS records are not dependent on each other in the way that
TLS records are.
In general, DTLS implementations SHOULD silently discard data with
bad MACs. If a DTLS implementation chooses to generate an alert when
it receives a message with an invalid MAC, it MUST generate
bad_record_mac alert with level fatal and terminate its connection
state.
4.1.2.2. Null or Standard Stream Cipher
The DTLS NULL cipher is performed exactly as the TLS 1.1 NULL cipher.
The only stream cipher described in TLS 1.1 is RC4, which cannot be
randomly accessed. RC4 MUST NOT be used with DTLS.
4.1.2.3. Block Cipher
DTLS block cipher encryption and decryption are performed exactly as
with TLS 1.1.
4.1.2.4. New Cipher Suites
Upon registration, new TLS cipher suites MUST indicate whether they
are suitable for DTLS usage and what, if any, adaptations must be
made.
4.1.2.5. Anti-replay
DTLS records contain a sequence number to provide replay protection.
Sequence number verification SHOULD be performed using the following
sliding window procedure, borrowed from Section 3.4.3 of [RFC 2402].
The receiver packet counter for this session MUST be initialized to
zero when the session is established. For each received record, the
receiver MUST verify that the record contains a Sequence Number that
does not duplicate the Sequence Number of any other record received
during the life of this session. This SHOULD be the first check
applied to a packet after it has been matched to a session, to speed
rejection of duplicate records.
Duplicates are rejected through the use of a sliding receive window.
(How the window is implemented is a local matter, but the following
text describes the functionality that the implementation must
exhibit.) A minimum window size of 32 MUST be supported, but a
window size of 64 is preferred and SHOULD be employed as the default.
Another window size (larger than the minimum) MAY be chosen by the
receiver. (The receiver does not notify the sender of the window
size.)
The "right" edge of the window represents the highest validated
Sequence Number value received on this session. Records that contain
Sequence Numbers lower than the "left" edge of the window are
rejected. Packets falling within the window are checked against a
list of received packets within the window. An efficient means for
performing this check, based on the use of a bit mask, is described
in Appendix C of [RFC 2401].
If the received record falls within the window and is new, or if the
packet is to the right of the window, then the receiver proceeds to
MAC verification. If the MAC validation fails, the receiver MUST
discard the received record as invalid. The receive window is
updated only if the MAC verification succeeds.
4.2. The DTLS Handshake Protocol
DTLS uses all of the same handshake messages and flows as TLS, with
three principal changes:
1. A stateless cookie exchange has been added to prevent denial of
service attacks.
2. Modifications to the handshake header to handle message loss,
reordering, and fragmentation.
3. Retransmission timers to handle message loss.
With these exceptions, the DTLS message formats, flows, and logic are
the same as those of TLS 1.1.
4.2.1. Denial of Service Countermeasures
Datagram security protocols are extremely susceptible to a variety of
denial of service (DoS) attacks. Two attacks are of particular
concern:
1. An attacker can consume excessive resources on the server by
transmitting a series of handshake initiation requests, causing
the server to allocate state and potentially to perform expensive
cryptographic operations.
2. An attacker can use the server as an amplifier by sending
connection initiation messages with a forged source of the victim.
The server then sends its next message (in DTLS, a Certificate
message, which can be quite large) to the victim machine, thus
flooding it.
In order to counter both of these attacks, DTLS borrows the stateless
cookie technique used by Photuris [PHOTURIS] and IKE [IKE]. When the