< draft-rescorla-dtls-03.txt   draft-rescorla-dtls-04.txt >
E. Rescorla E. Rescorla
RTFM, Inc. RTFM, Inc.
N. Modadugu N. Modadugu
INTERNET-DRAFT Stanford University INTERNET-DRAFT Stanford University
<draft-rescorla-dtls-03.txt> February 2004 (Expires August 2005) <draft-rescorla-dtls-04.txt> April 2004 (Expires October 2005)
Datagram Transport Layer Security Datagram Transport Layer Security
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance with have been or will be disclosed, and any of which he or she becomes
RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than a "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 (1999-2004). All Rights Reserved.
Abstract Abstract
This document specifies Version 1.0 of the Datagram Transport Layer This document specifies Version 1.0 of the Datagram Transport
Security (DTLS) protocol. The DTLS protocol provides communications Layer Security (DTLS) protocol. The DTLS protocol provides
privacy for datagram protocols. The protocol allows client/server communications privacy for datagram protocols. The protocol
applications to communicate in a way that is designed to prevent allows client/server applications to communicate in a way that
eavesdropping, tampering, or message forgery. The DTLS protocol is is designed to prevent eavesdropping, tampering, or message
based on the TLS protocol and provides equivalent security forgery. The DTLS protocol is based on the TLS protocol and
guarantees. Datagram semantics of the underlying transport are provides equivalent security guarantees. Datagram semantics of
preserved by the DTLS protocol. the underlying transport are preserved by the DTLS protocol.
Contents 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 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 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 20
4.3 Handshake Protocol 21
5 Security Considerations 22
6 IANA Considerations 22
1. Introduction 1. Introduction
TLS [TLS] is the most widely deployed protocol for securing network TLS [TLS] is the most widely deployed protocol for securing
traffic. It is widely used for protecting Web traffic and for e-mail network traffic. It is widely used for protecting Web traffic
protocols such as IMAP [IMAP] and POP [POP]. The primary advantage of and for e-mail protocols such as IMAP [IMAP] and POP [POP].
TLS is that it provides a transparent connection-oriented channel. The primary advantage of TLS is that it provides a transparent
Thus, it is easy to secure an application protocol by inserting TLS connection-oriented channel. Thus, it is easy to secure an
between the application layer and the transport layer. However, TLS application protocol by inserting TLS between the application
must run over a reliable transport channel--typically TCP [TCP]. It layer and the transport layer. However, TLS must run over a
therefore cannot be used to secure unreliable datagram traffic. 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 However, over the past few years an increasing number of
layer protocols have been designed which UDP transport. In particular application layer protocols have been designed which UDP
such protocols as the Session Initiation Protocol (SIP) [SIP], and transport. In particular such protocols as the Session
electronic gaming protocols are increasingly popular. (Note that SIP Initiation Protocol (SIP) [SIP], and electronic gaming
can run over both TCP and UDP, but that there are situations in which protocols are increasingly popular. (Note that SIP can run
UDP is preferable). Currently, designers of these applications are over both TCP and UDP, but that there are situations in which
faced with a number of unsatisfactory choices. First, they can use UDP is preferable). Currently, designers of these applications
IPsec [RFC2401]. However, for a number of reasons detailed in are faced with a number of unsatisfactory choices. First, they
[WHYIPSEC], this is only suitable for some applications. Second, they can use IPsec [RFC2401]. However, for a number of reasons
can design a custom application layer security protocol. SIP, for detailed in [WHYIPSEC], this is only suitable for some
instance, uses a subsert of S/MIME to secure its traffic. applications. Second, they can design a custom application
Unfortunately, while application layer security protocols generally layer security protocol. SIP, for instance, uses a subsert of
provide superior security properties (e.g., end-to-end security in S/MIME to secure its traffic. Unfortunately, while application
the case of S/MIME) it typically require a large amount of effort to layer security protocols generally provide superior security
design--by contrast to the relatively small amount of effort required properties (e.g., end-to-end security in the case of S/MIME)
to run the protocol over TLS. it typically require 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 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. This memo datagram-compatible variant of TLS would be very desirable.
describes such a protocol: Datagram Transport Layer Security (DTLS). This memo describes such a protocol: Datagram Transport Layer
DTLS is deliberately designed to be as similar to to TLS as possible, Security (DTLS). DTLS is deliberately designed to be as
both to minimize new security invention and to maximize the amount of similar to to TLS as possible, both to minimize new security
code and infrastructure reuse. invention and to maximize the amount of code and
infrastructure reuse.
1.1. Requirements Terminology 1.1. Requirements Terminology
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD
"MAY" that appear in this document are to be interpreted as described NOT" and "MAY" that appear in this document are to be
in RFC 2119 [REQ]. interpreted as described in RFC 2119 [REQ].
2. Usage Model 2. Usage Model
The DTLS protocol is designed to secure data between communicating The DTLS protocol is designed to secure data between
applications. It is designed to run in application space, without communicating applications. It is designed to run in
requiring any kernel modifications. While the design of the DTLS application space, without requiring any kernel modifications.
protocol does not preclude its use in securing arbitrary datagram
traffic, it is primarily expected to secure communication based on
datagram sockets.
Datagram transport does not require or provide reliable or in-order Datagram transport does not require or provide reliable or in-
delivery of data. The DTLS protocol preserves this property for order delivery of data. The DTLS protocol preserves this
payload data. Applications such as media streaming, Internet property for payload data. Applications such as media
telephony and online gaming use datagram transport for communication streaming, Internet telephony and online gaming use datagram
due to the delay-sensitive nature of transported data. The behavior transport for communication due to the delay-sensitive nature
of such applications is unchanged when the DTLS protocol is used to of transported data. The behavior of such applications is
secure communication, since the DTLS protocol does not compensate for unchanged when the DTLS protocol is used to secure
communication, since the DTLS protocol does not compensate for
lost or re-ordered data traffic. lost or re-ordered data traffic.
3. Overview of DTLS 3. Overview of DTLS
The basic design philosophy of DTLS is to construct "TLS over The basic design philosophy of DTLS is to construct "TLS over
datagram". The reason that TLS cannot be used directly in datagram datagram". The reason that TLS cannot be used directly in
environments is simply that packets may be lost or reordered. TLS has datagram environments is simply that packets may be lost or
no internal facilities to handle this kind of unreliability and reordered. TLS has no internal facilities to handle this kind
therefore TLS implementations break when rehosted on datagram of unreliability and therefore TLS implementations break when
transport. The purpose of DTLS is to make only the minimal changes to rehosted on datagram transport. The purpose of DTLS is to make
TLS required to fix this problem. To the greatest extent possible, only the minimal changes to TLS required to fix this problem.
DTLS is identical to TLS. Whenever we need to invent new mechanisms, To the greatest extent possible, DTLS is identical to TLS.
we attempt to do so in such a way that it preserves the style of 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: Unreliability creates problems for TLS at two levels:
1. TLS's traffic encryption layer does not allow independent 1. TLS's traffic encryption layer does not allow
decryption of individual records. If record N is not received, independent decryption of individual records. If record N
then record N+1 cannot be decrypted. is not received, then record N+1 cannot be decrypted.
2. The TLS handshake layer assumes that handshake messages are 2. The TLS handshake layer assumes that handshake messages
delivered reliably and breaks if those messages are lost. are delivered reliably and breaks if those messages are
lost.
The rest of this section describes the approach that DTLS uses to The rest of this section describes the approach that DTLS uses
solve these problems. to solve these problems.
3.1. Loss-insensitive messaging 3.1. Loss-insensitive messaging
In TLS's traffic encryption layer (called the TLS Record Layer), In TLS's traffic encryption layer (called the TLS Record
records are not independent. There are two kinds of inter-record Layer), records are not independent. There are two kinds of
dependency: inter-record dependency:
1. Cryptographic context (CBC state, stream cipher key stream) is 1. Cryptographic context (CBC state, stream cipher key
chained between records. stream) is chained between records.
2. Anti-replay and message reordering protection are provided by a 2. Anti-replay and message reordering protection are
MAC which includes a sequence number, but the sequence numbers are provided by a MAC which includes a sequence number, but the
implicit in the records. sequence numbers are implicit in the records.
The fix for both of these problems is straightforward and well-known The fix for both of these problems is straightforward and
from IPsec ESP [ESP]: add explicit state to the records. TLS 1.1 well-known from IPsec ESP [ESP]: add explicit state to the
[TLS11] is already adding explicit CBC state to TLS records. DTLS records. TLS 1.1 [TLS11] is already adding explicit CBC state
borrows that mechanism and adds explicit sequence numbers. to TLS records. DTLS borrows that mechanism and adds explicit
sequence numbers.
3.2. Providing Reliability for Handshake 3.2. Providing Reliability for Handshake
The TLS handshake is a lockstep cryptographic handshake. Messages The TLS handshake is a lockstep cryptographic handshake.
must be transmitted and received in a defined order and any other Messages must be transmitted and received in a defined order
order is an error. Clearly, this is incompatible with reordering and and any other order is an error. Clearly, this is incompatible
message loss. In addition, TLS handshake messages are potentially with reordering and message loss. In addition, TLS handshake
larger than any given datagram, thus creating the problem of messages are potentially larger than any given datagram, thus
fragmentation. DTLS must provide fixes for both these problems. creating the problem of fragmentation. DTLS must provide fixes
for both these problems.
3.2.1. Packet Loss 3.2.1. Packet Loss
DTLS uses a simple retransmission timer to handle packet loss. The DTLS uses a simple retransmission timer to handle packet loss.
following figure demonstrates the basic concept using the first phase The following figure demonstrates the basic concept using the
of the DTLS handshake: first phase of the DTLS handshake:
Client Server Client Server
------ ------ ------ ------
ClientHello ------> ClientHello ------>
X<-- HelloVerifyRequest X<-- HelloVerifyRequest
(lost) (lost)
[Timer Expires] [Timer Expires]
ClientHello ------> ClientHello ------>
(retransmit) (retransmit)
Once the client has transmitted the ClientHello message, it expects Once the client has transmitted the ClientHello message, it
to see a HelloVerifyRequest from the server. However, if the server's expects to see a HelloVerifyRequest from the server. However,
message is lost the client knows that either the ClientHello or the if the server's message is lost the client knows that either
HelloVerifyRequest has been lost and retransmits. When the server the ClientHello or the HelloVerifyRequest has been lost and
receives the retransmission, it knows to retransmit. The server also retransmits. When the server receives the retransmission, it
maintains a retransmission timer and retransmits when that timer knows to retransmit. The server also maintains a
expires. 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 3.2.2. Reordering
In DTLS, each handshake message is assigned a specific sequence In DTLS, each handshake message is assigned a specific
number within that handshake. When a peer receives a handshake sequence number within that handshake. When a peer receives a
message, it can quickly determine whether that message is the next handshake message, it can quickly determine whether that
message it expects. If it is, then it processes it. If not, it queues message is the next message it expects. If it is, then it
it up for future handling once all previous messages have been processes it. If not, it queues it up for future handling once
received. all previous messages have been received.
3.2.3. Message Size 3.2.3. Message Size
TLS and DTLS handshake messages can be quite large (in theory up to TLS and DTLS handshake messages can be quite large (in theory
2^24-1 bytes, in practice many kilobytes). By contrast, UDP datagrams up to 2^24-1 bytes, in practice many kilobytes). By contrast,
are often limited to <1500 bytes. In order to compensate for this 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 limitation, each DTLS handshake message may be fragmented over
several DTLS records. Each DTLS handshake message contains both a several DTLS records. Each DTLS handshake message contains
fragment offset and a fragment length. Thus, a recipient in both a fragment offset and a fragment length. Thus, a
possession of all bytes of a handshake message can reassemble the recipient in possession of all bytes of a handshake message
original unfragmented message. can reassemble the original unfragmented message.
3.3. Replay Detection 3.3. Replay Detection
DTLS optionally supports record replay detection. The technique used DTLS optionally supports record replay detection. The
is the same as in IPsec AH/ESP, by maintaining a bitmap window of technique used is the same as in IPsec AH/ESP, by maintaining
received records. Records that are too old to fit in the window and a bitmap window of received records. Records that are too old
records that have been previously received are silently discarded. to fit in the window and records that have been previously
The replay detection feature is optional, since packet duplication is received are silently discarded. The replay detection feature
not always malicious, but can also occur due to routing errors. is optional, since packet duplication is not always malicious,
Applications may conceivably detect duplicate packets and accordingly but can also occur due to routing errors. Applications may
modify their data transmission strategy. conceivably detect duplicate packets and accordingly modify
their data transmission strategy.
4. Differences from TLS 4. Differences from TLS
As mentioned in Section 3., DTLS is intentionally very similar to As mentioned in Section 3., DTLS is intentionally very similar
TLS. Therefore, instead of presenting DTLS as a new protocol, we to TLS. Therefore, instead of presenting DTLS as a new
instead present it as a series of deltas from TLS 1.1 [TLS11]. Where protocol, we instead present it as a series of deltas from TLS
we do not explicitly call out differences, DTLS is the same as TLS. 1.1 [TLS11]. Where we do not explicitly call out differences,
DTLS is the same as TLS.
4.1. Record Layer 4.1. Record Layer
The DTLS record layer is extremely similar to that of TLS 1.1. The The DTLS record layer is extremely similar to that of TLS 1.1.
only change is the inclusion of an explicit sequence number in the The only change is the inclusion of an explicit sequence
record. This sequence number allows the recipient to correctly verify number in the record. This sequence number allows the
the TLS MAC. The DTLS record format is shown below: recipient to correctly verify the TLS MAC. The DTLS record
format is shown below:
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;
opaque fragment[DTLSPlaintext.length]; opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext; } DTLSPlaintext;
skipping to change at page 6, line 46 skipping to change at page 7, line 47
sequence_number sequence_number
The sequence number for this record. The sequence number for this record.
length length
Identical to the length field in a TLS 1.1 record. As in TLS Identical to the length field in a TLS 1.1 record. As in TLS
1.1, the length should not exceed 2^14. 1.1, the length should not exceed 2^14.
fragment fragment
Identical to the fragment field of a TLS 1.1 record. Identical to the fragment field of a TLS 1.1 record.
DTLS uses an explicit rather than implicit sequence number, carried DTLS uses an explicit rather than implicit sequence number,
in the sequence_number field of the record. As with TLS, the sequence carried in the sequence_number field of the record. As with
number is set to zero after each ChangeCipherSpec message is sent. TLS, the sequence number is set to zero after each
ChangeCipherSpec message is sent.
If several handshakes are performed in close succession, there might If several handshakes are performed in close succession, there
be multiple records on the wire with the same sequence number but might be multiple records on the wire with the same sequence
from different cipher states. The epoch field allows recipients to number but from different cipher states. The epoch field
distinguish such packets. The epoch number is initially zero and is allows recipients to distinguish such packets. The epoch
incremented each time the ChangeCipherSpec messages is sent. In order number is initially zero and is incremented each time the
to ensure that any given sequence/epoch pair is unique, ChangeCipherSpec messages is sent. In order to ensure that any
implementations MUST NOT allow the same epoch value to be reused given sequence/epoch pair is unique, implementations MUST NOT
within two times the maximum segment lifetime. In practice, TLS allow the same epoch value to be reused within two times the
implementations rehandshake rarely and we therefore do not expect TCP maximum segment lifetime. In practice, TLS implementations
this to be a problem. rehandshake rarely and we therefore do not expect this to be a
problem.
4.1.1. Transport Layer Mapping 4.1.1. Transport Layer Mapping
Each DTLS record MUST fit within a single datagram. In order to avoid Each DTLS record MUST fit within a single datagram. In order
IP fragmentation [MOGUL], DTLS implementations SHOULD determine the to avoid IP fragmentation [MOGUL], DTLS implementations SHOULD
MTU and send records smaller than the MTU. DTLS implementations determine the MTU and send records smaller than the MTU. DTLS
SHOULD provide a way for applications to determine the value of the implementations SHOULD provide a way for applications to
MTU (optimally the maximum application datagram size, which is the determine the value of the PMTU (or alternately the maximum
PMTU minus the DTLS per-record overhead). If the application attempts application datagram size, which is the PMTU minus the DTLS
to send a record larger than the MTU, the DTLS implementation MUST per-record overhead). If the application attempts to send a
either generate an error or fragment the packet. record larger than the MTU the DTLS implementation SHOULD
generate an error, thus avoiding sending a packet which will
be fragmented.
Multiple DTLS records may be placed in a single datagram. They are Note that unlike IPsec, DTLS records do not contain any
simply encoded consecutively. The DTLS record framing is sufficient association identifiers. Applications must arrange to
to determine the boundaries. Note, however, that the first byte of multiplex between associations. With UDP, this is presumably
the datagram payload must be the beginning of a record. Records may done with host/port number.
not span datagrams.
4.1.1.1. PMTU Discovery Multiple DTLS records may be placed in a single datagram. hey
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.
The PMTU SHOULD be initialized from the interface MTU that will be 4.1.1.1. PMTU Discovery
used to send packets.
To perform PMTU discovery, the DTLS sender sets the IP Don't Fragment In general, DTLS's philosophy is to avoid dealing with PMTU
(DF) bit. As specified in [RFC 1191], when a router receives a packet issues. The general strategy is to start with a conservative
with DF set that is larger than the next link's MTU, it sends an ICMP MTU and then update it if events require it, but not actively
Destination Unreachable message to the source of the datagram with probe for MTU values. PMTU discovery is left to the
the Code indicating "fragmentation needed and DF set" (also known as application.
a "Datagram Too Big" message). When a DTLS implementation receives a
Datagram Too Big message, it decreases its PMTU to the Next-Hop MTU
value given in the ICMP message. If the MTU given in the message is
zero, the sender chooses a value for PMTU using the algorithm
described in Section 7 of [RFC 1191]. If the MTU given in the message
is greater than the current PMTU, the Datagram Too Big message is
ignored, as described in [RFC 1191].
A DTLS implementation may allow the application to occasionally The PMTU SHOULD be initialized from the interface MTU that
request that PMTU discovery be performed again. This will reset the will be used to send packets. If the DTLS implementation
PMTU to the outgoing interface's MTU. Such requests SHOULD be rate receives an RFC 1191 [RFC1191] ICMP Destination Unreachable
limited, to one per two seconds, for example. 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.
Because some firewalls and routers screen out ICMP messages, it is One special case is the DTLS handshake system. Handshake
difficult to distinguish packet loss from a large PMTU estimate. In messages should be set with DF set. Because some firewalls and
order to allow connections under these circumstances, DTLS routers screen out ICMP messages, it is difficult for the
implementations MAY choose to back off their PMTU estimate during the handshake layer to distinguish packet loss from an overlarge
retransmit backoff described in Section 4.2.4.. For instance, if a PMTU estimate. In order to allow connections under these
large packet is being sent, after 3 retransmits a sender might choose circumstances, DTLS implementations SHOULD back off handshake
to fragment the packet. 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 4.1.2. Record payload protection
Like TLS, DTLS transmits data as a series of protected records. The Like TLS, DTLS transmits data as a series of protected
rest of this section describes the details of that format. records. The rest of this section describes the details of
that format.
4.1.2.1. MAC 4.1.2.1. MAC
The DTLS MAC is the same as that of TLS 1.1. However, rather than The DTLS MAC is the same as that of TLS 1.1. However, rather
using TLS's implicit sequence number, the sequence number used to than using TLS's implicit sequence number, the sequence number
compute the MAC is the 64-bit value formed by concatenating the epoch used to compute the MAC is the 64-bit value formed by
and the sequence number in the order they appear on the wire. Note concatenating the epoch and the sequence number in the order
that the DTLS epoch + sequence number is the same length as the TLS they appear on the wire. Note that the DTLS epoch + sequence
sequence number. 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.
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 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 The only stream cipher described in TLS 1.1 is RC4, which
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
DTLS block cipher encryption and decryption are performed exactly as DTLS block cipher encryption and decryption are performed
with TLS 1.1. exactly as with TLS 1.1.
4.1.2.4. New Cipher Suites 4.1.2.4. New Cipher Suites
Upon registration, new TLS cipher suites MUST indicate whether they Upon registration, new TLS cipher suites MUST indicate whether
are suitable for DTLS usage and what, if any, adaptations must be they are suitable for DTLS usage and what, if any, adaptations
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 protection. DTLS records contain a sequence number to provide replay
Sequence number verification SHOULD be performed using the following protection. Sequence number verification SHOULD be performed
sliding, window procedure, borrowed from Section 3.4.3 of [RFC 2402] 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 The receiver packet counter for this session MUST be
zero when the session is established. For each received record, the initialized to zero when the session is established. For each
receiver MUST verify that the record contains a Sequence Number that received record, the receiver MUST verify that the record
does not duplicate the Sequence Number of any other record received contains a Sequence Number that does not duplicate the
during the life of this session. This SHOULD be the first check Sequence Number of any other record received during the life
applied to a packet after it has been matched to a session, to speed 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. rejection of duplicate records.
Duplicates are rejected through the use of a sliding receive window. Duplicates are rejected through the use of a sliding receive
(How the window is implemented is a local matter, but the following window. (How the window is implemented is a local matter, but
text describes the functionality that the implementation must the following text describes the functionality that the
exhibit.) A minimum window size of 32 MUST be supported; but a window implementation must exhibit.) A minimum window size of 32 MUST
size of 64 is preferred and SHOULD be employed as the default. be supported; but a window size of 64 is preferred and SHOULD
Another window size (larger than the minimum) MAY be chosen by the be employed as the default. Another window size (larger than
receiver. (The receiver does not notify the sender of the window the minimum) MAY be chosen by the receiver. (The receiver does
size.) not notify the sender of the window size.)
The "right" edge of the window represents the highest, validated The "right" edge of the window represents the highest,
Sequence Number value received on this session. Records that contain validated Sequence Number value received on this session.
Sequence Numbers lower than the "left" edge of the window are Records that contain Sequence Numbers lower than the "left"
rejected. Packets falling within the window are checked against a edge of the window are rejected. Packets falling within the
list of received packets within the window. An efficient means for window are checked against a list of received packets within
performing this check, based on the use of a bit mask, is described the window. An efficient means for performing this check,
in Appendix C of [RFC 2401]. 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 If the received record falls within the window and is new, or
packet is to the right of the window, then the receiver proceeds to if the packet is to the right of the window, then the receiver
MAC verification. If the MAC validation fails, the receiver MUST proceeds to MAC verification. If the MAC validation fails, the
discard the received record as invalid. The receive window is updated receiver MUST discard the received record as invalid. The
only if the MAC verification succeeds. receive window is updated only if the MAC verification
succeeds.
4.2. The DTLS Handshake Protocol 4.2. The DTLS Handshake Protocol
DTLS uses all of the same handshake messages and flows as TLS, with DTLS uses all of the same handshake messages and flows as TLS,
three principal changes: with three principal changes:
1. A stateless cookie exchange has been added to prevent denial of 1. A stateless cookie exchange has been added to prevent
service attacks. denial of service attacks.
2. Modifications to the handshake header to handle message loss, 2. Modifications to the handshake header to handle message
reordering and fragmentation. loss, reordering and fragmentation.
3. Retransmission timers to handle message loss. 3. Retransmission timers to handle message loss.
With these exceptions, the DTLS message formats, flows, and logic are With these exceptions, the DTLS message formats, flows, and
the same as those of TLS 1.1. logic are the same as those of TLS 1.1.
4.2.1. Denial of Service Countermeasures 4.2.1. Denial of Service Countermeasures
Datagram security protocols are extremely susceptible to a variety of Datagram security protocols are extremely susceptible to a
denial of service (DoS) attacks. Two attacks are of particular variety of denial of service (DoS) attacks. Two attacks are of
concern: particular concern:
1. An attacker can consume excessive resources on the server by 1. An attacker can consume excessive resources on the
transmitting a series of handshake initiation requests, causing server by transmitting a series of handshake initiation
the server to allocate state and potentially perform expensive requests, causing the server to allocate state and
cryptographic operations. potentially perform expensive cryptographic operations.
2. An attacker can use the server as an amplifier by sending 2. An attacker can use the server as an amplifier by
connection initiation messages with a forged source of the victim. sending connection initiation messages with a forged source
The server then sends its next message (in DTLS, a Certificate of the victim. The server then sends its next message (in
message, which can be quite large) to the victim machine, thus DTLS, a Certificate message, which can be quite large) to
flooding it. the victim machine, thus flooding it.
In order to prevent both of these attacks, DTLS borrows the stateless In order to counter both of these attacks, DTLS borrows the
cookie technique used by Photuris [PHOTURIS] and IKEv2 [IKE]. When stateless cookie technique used by Photuris [PHOTURIS] and IKE
the client sends its ClientHello message to the server, the server [IKE]. When the client sends its ClientHello message to the
MAY respond with a HelloVerifyRequest message. This message contains server, the server MAY respond with a HelloVerifyRequest
a stateless cookie generated using the technique of [PHOTURIS]. The message. This message contains a stateless cookie generated
client MUST retransmit the ClientHello with the cookie added. The using the technique of [PHOTURIS]. The client MUST retransmit
server then verifies the cookie and proceeds with the handshake only the ClientHello with the cookie added. The server then
if it is valid. 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: The exchange is shown below:
Client Server Client Server
------ ------ ------ ------
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 cookie DTLS therefore modifies the ClientHello message to add the
value. cookie value.
struct { struct {
ProtocolVersion client_version; ProtocolVersion client_version;
Random random; Random random;
SessionID session_id; SessionID session_id;
Cookie 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;
If the client does not have a cookie for a given server, it should When sending the first ClientHello, the client does not have a
use a zero-length cookie. cookie yet; in this case, the Cookie field is left empty (zero
length).
The definition of HelloVerifyRequest is as follows: The definition of HelloVerifyRequest is as follows:
struct { struct {
Cookie cookie<0..32>; Cookie cookie<0..32>;
} HelloVerifyRequest; } HelloVerifyRequest;
The HelloVerifyRequest message type is hello_verify_request(3). The HelloVerifyRequest message type is
hello_verify_request(3).
When responding to a HelloVerifyRequest the client MUST use the same When responding to a HelloVerifyRequest the client MUST use
parameter values (version, random, session_id, cipher_suites, the same parameter values (version, random, session_id,
compression_method) as in the original ClientHello. The server SHOULD cipher_suites, compression_method) as in the original
use those values to generate its cookie and verify that they are ClientHello. The server SHOULD use those values to generate
correct upon cookie receipt. its cookie and verify that they are correct upon cookie
receipt. 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)
Although DTLS servers are not required to do a cookie exchange, they When the second ClientHello is received, the server can verify
SHOULD do so whenever a new handshake is performed in order to avoid that the Cookie is valid and that the client can receive
being used as amplifiers. If the server is being operated in an packets at the given IP address.
environment where amplification is not a problem, the server MAY One potential attack on this scheme is for the attacker to
choose not to perform a cookie exchange. In addition, the server MAY collect a number of cookies from different addresses and then
choose not do to a cookie exchange when a session is resumed. Clients reuse them to attack the server. The server can defend against
MUST be prepared to do a cookie exchange with every handshake. 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.
Although DTLS servers are not required to do a cookie
exchange, they SHOULD do so whenever a new handshake is
performed in order to avoid being used as amplifiers. If the
server is being operated in an environment where amplification
is not a problem, the server MAY choose not to perform a
cookie exchange. 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 4.2.2. Handshake Message Format
In order to support message loss, reordering, and fragmentation DTLS In order to support message loss, reordering, and
modifies the TLS 1.1 handshake header: fragmentation DTLS modifies the TLS 1.1 handshake header:
struct { struct {
HandshakeType msg_type; HandshakeType msg_type;
uint24 length; uint24 length;
uint16 message_seq; // New field uint16 message_seq; // New field
uint24 fragment_offset; // New field uint24 fragment_offset; // New field
uint24 fragment_length; // New field uint24 fragment_length; // New field
select (HandshakeType) { select (HandshakeType) {
case hello_request: HelloRequest; case hello_request: HelloRequest;
case client_hello: ClientHello; case client_hello: ClientHello;
skipping to change at page 12, line 11 skipping to change at page 14, line 18
case certificate:Certificate; case certificate:Certificate;
case server_key_exchange: ServerKeyExchange; case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest; case certificate_request: CertificateRequest;
case server_hello_done:ServerHelloDone; case server_hello_done:ServerHelloDone;
case certificate_verify: CertificateVerify; case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange; case client_key_exchange: ClientKeyExchange;
case finished:Finished; case finished:Finished;
} body; } body;
} Handshake; } Handshake;
The first message each side transmits in each handshake always has The first message each side transmits in each handshake always
message_seq = 0. Whenever each new message is generated, the has message_seq = 0. Whenever each new message is generated,
message_seq value is incremented by one. When a message is the message_seq value is incremented by one. When a message is
retransmitted, the same message_seq value is used. For example. retransmitted, the same message_seq value is used. For
example.
Client Server Client Server
------ ------ ------ ------
ClientHello (seq=0) ------> ClientHello (seq=0) ------>
X<-- HelloVerifyRequest (seq=0) X<-- HelloVerifyRequest (seq=0)
(lost) (lost)
[Timer Expires] [Timer Expires]
skipping to change at page 12, line 39 skipping to change at page 14, line 47
ClientHello (seq=1) ------> ClientHello (seq=1) ------>
(with cookie) (with cookie)
<------ ServerHello (seq=1) <------ ServerHello (seq=1)
<------ Certificate (seq=2) <------ Certificate (seq=2)
<------ ServerHelloDone (seq=3) <------ ServerHelloDone (seq=3)
[Rest of handshake] [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 DTLS implementations maintain (at least notionally) a
next_receive_seq counter. This counter is initially set to zero. When next_receive_seq counter. This counter is initially set to
a message is received, if its sequence number matches zero. When a message is received, if its sequence number
next_receive_seq, next_receive_seq is incremented and the message is matches next_receive_seq, next_receive_seq is incremented and
processed. If the sequence number is less than next_receive_seq the the message is processed. If the sequence number is less than
message MUST be discarded. If the sequence number is greater than next_receive_seq the message MUST be discarded. If the
next_receive_seq, the implementation SHOULD queue the message but MAY sequence number is greater than next_receive_seq, the
discard it. (This is a simple space/bandwidth tradeoff). implementation SHOULD queue the message but MAY discard it.
(This is a simple space/bandwidth tradeoff).
4.2.3. Message Fragmentation and Reassembly 4.2.3. Message Fragmentation and Reassembly
As noted in Section 4.1.1., each DTLS message MUST fit within a As noted in Section 4.1.1., each DTLS message MUST fit within
single transport layer datagram. However, handshake messages are a single transport layer datagram. However, handshake messages
potentially bigger than the maximum record size. Therefore DTLS are potentially bigger than the maximum record size. Therefore
provides a mechanism for fragmenting a handshake message over a DTLS provides a mechanism for fragmenting a handshake message
number of records. over a number of records.
When transmitting the handshake message, the sender divides the When transmitting the handshake message, the sender divides
message into a series of N contiguous data ranges. These range MUST the message into a series of N contiguous data ranges. These
NOT be larger than the maximum handshake fragment size and MUST range MUST NOT be larger than the maximum handshake fragment
jointly contain the entire handshake message. The ranges SHOULD NOT size and MUST jointly contain the entire handshake message.
overlap. The sender then creates N handshake messages, all with the The ranges SHOULD NOT overlap. The sender then creates N
same message_seq value as the original handshake message. Each new handshake messages, all with the same message_seq value as the
message is labelled with the fragment_offset (the number of bytes original handshake message. Each new message is labelled with
contained in previous fragments) and the fragment_length (the length the fragment_offset (the number of bytes contained in previous
of this fragment). The length field in all messages is the same as fragments) and the fragment_length (the length of this
the length field of the original message. An unfragmented message is fragment). The length field in all messages is the same as the
a degenerate case with fragment_offset=0 and fragment_length=length. 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 When a DTLS implementation receives a handshake message
MUST buffer it until it has the entire handshake message. DTLS fragment, it MUST buffer it until it has the entire handshake
implementations MUST be able to handle overlapping fragment ranges. message. DTLS implementations MUST be able to handle
This allows senders to retransmit handshake messages with smaller overlapping fragment ranges. This allows senders to retransmit
fragment sizes during path MTU discovery. handshake messages with smaller fragment sizes during path MTU
discovery.
Note that as with TLS, multiple handshake messages may be placed in Note that as with TLS, multiple handshake messages may be
the same DTLS record, provided that there is room and that they are placed in the same DTLS record, provided that there is room
part of the same flight. Thus, there are two acceptable ways to pack and that they are part of the same flight. Thus, there are two
two DTLS messages into the same datagram: in the same record or in acceptable ways to pack two DTLS messages into the same
separate records. datagram: in the same record or in separate records.
4.2.4. Timeout and Retransmission 4.2.4. Timeout and Retransmission
DTLS messages are grouped into a series of message flights, according DTLS messages are grouped into a series of message flights,
the diagrams below. Although each flight of messages may consist of a according the diagrams below. Although each flight of messages
number of messages, they should be viewed as monolithic for the may consist of a number of messages, they should be viewed as
purpose of timeout and retransmission. monolithic for the purpose of timeout and retransmission.
Client Server Client Server
------ ------ ------ ------
ClientHello --------> Flight 1 ClientHello --------> Flight 1
<------- HelloVerifyRequest Flight 2 <------- HelloVerifyRequest Flight 2
ClientHello --------> Flight 3 ClientHello --------> Flight 3
skipping to change at page 14, line 28 skipping to change at page 16, line 35
<-------- ServerHelloDone / <-------- ServerHelloDone /
Certificate* \ Certificate* \
ClientKeyExchange \ ClientKeyExchange \
CertificateVerify* Flight 5 CertificateVerify* Flight 5
[ChangeCipherSpec] / [ChangeCipherSpec] /
Finished --------> / Finished --------> /
[ChangeCipherSpec] \ Flight 6 [ChangeCipherSpec] \ Flight 6
<-------- Finished / <-------- Finished /
Figure 1: Message flights for full handshake Figure 1: Message flights for full handshake
Client Server Client Server
------ ------ ------ ------
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 cookie exchange) Figure 2: Message flights for session resuming handshake (no
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 message following state machine. Because DTLS clients send the first
(ClientHello) they start in the PREPARING state. DTLS servers start message (ClientHello) they start in the PREPARING state. DTLS
in the WAITING state, but with empty buffers and no retransmit timer. servers start in the WAITING state, but with empty buffers and
no retransmit timer.
+-----------+ +-----------+
| PREPARING | | PREPARING |
+---> | | +---> | |
| | | | | |
| +-----------+ | +-----------+
| | | |
| | | |
| | Buffer next flight | | Buffer next flight
| | | |
skipping to change at page 15, line 46 skipping to change at page 18, line 46
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 computations In the PREPARING state the implementation does whatever
are necessary to prepare the next flight of messages. It then buffers computations are necessary to prepare the next flight of
them up for transmission (emptying the buffer first) and enters the messages. It then buffers them up for transmission (emptying
SENDING state. the buffer first) and enters the SENDING state.
In the SENDING state, the implementation transmits the buffered In the SENDING state, the implementation transmits the
flight of messages. Once the messages have been sent, the buffered flight of messages. Once the messages have been sent,
implementation then enters the FINISHED state if this is the last the implementation then enters the FINISHED state if this is
flight in the handshake, or, if the implementation expects to receive the last flight in the handshake, or, if the implementation
more messages, sets a retransmit timer and then enters the WAITING expects to receive more messages, sets a retransmit timer and
state. then enters the WAITING state.
There are three ways to exit the WAITING state: There are three ways to exit the WAITING state:
1. The retransmit timer expires: the implementation transitions to 1. The retransmit timer expires: the implementation
the SENDING state, where it retransmits the flight, resets the transitions to the SENDING state, where it retransmits the
retransmit timer, and returns to the WAITING state. flight, resets the retransmit timer, and returns to the
WAITING state.
2. The implementation reads a retransmitted flight from the peer: 2. The implementation reads a retransmitted flight from the
the implementation transitions to the SENDING state, where it peer: the implementation transitions to the SENDING state,
retransmits the flight, resets the retransmit timer, and returns where it retransmits the flight, resets the retransmit
to the WAITING state. The rationale here is that the receipt of a timer, and returns to the WAITING state. The rationale here
duplicate message is the likely result of timer expiry on the peer is that the receipt of a duplicate message is the likely
and therefore suggests that part of one's previous flight was result of timer expiry on the peer and therefore suggests
lost. that part of one's previous flight was lost.
3. The implementation receives the next flight of messages: if 3. The implementation receives the next flight of messages:
this is the final flight of messages the implementation if this is the final flight of messages the implementation
transitions to FINISHED. If the implementation needs to send a new transitions to FINISHED. If the implementation needs to
flight, it transitions to the PREPARING state. Partial reads send a new flight, it transitions to the PREPARING state.
(whether partial messages or only some of the messages in the Partial reads (whether partial messages or only some of the
flight) do not cause state transitions or timer resets. 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.
4.2.4.1. Timer Values 4.2.4.1. Timer Values
Timer value choices are a local matter. We RECOMMEND that Timer value choices are a local matter. Implementations SHOULD
implementations use an initial timer value of 500 ms and double the use an initial timer value of 500 ms and double the value at
value at each retransmission, up to twice the TCP Maximum Segment each retransmission, up to twice the TCP maximum segment
Lifetime. [TCP] Implementations SHOULD start the timer value at the lifetime [TCP] (if the recommendations in [TCP] are followed,
initial value with each new flight of messages. this will be 240 seconds). Implementations SHOULD start the
timer value at the initial value with each new flight of
messages.
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 flight as handshake message but MUST be treated as part of the same
the associated Finished message for the purposes of timeout and flight as the associated Finished message for the purposes of
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 order Finished messages have the same format as in TLS. However, in
to remove sensitivity to fragmentation, the Finished MAC MUST be order to remove sensitivity to fragmentation, the Finished MAC
computed as if each handshake message had been sent as a single MUST be computed as if each handshake message had been sent as
fragment. Note that in cases where the cookie exchange is used, the a single fragment. Note that in cases where the cookie
initial ClientHello and HelloVerifyRequest MUST BE included in the exchange is used, the initial ClientHello and
Finished MAC. HelloVerifyRequest MUST BE included in the Finished MAC.
4.2.7. Alert Messages
Note that Alert messages are not retransmitted at all, even
when they occur in the context of a handshake. However, a DTLS
implementation SHOULD generate a new alert message if the
offending record is received again (e.g., as a retransmitted
handshake message).
A.1Summary of new syntax A.1Summary of new syntax
This section includes specifications for the data structures that This section includes specifications for the data structures
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;
opaque fragment[DTLSPlaintext.length]; opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext; } DTLSPlaintext;
skipping to change at page 18, line 37 skipping to change at page 21, line 50
case server_key_exchange: ServerKeyExchange; case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest; case certificate_request: CertificateRequest;
case server_hello_done:ServerHelloDone; case server_hello_done:ServerHelloDone;
case certificate_verify: CertificateVerify; case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange; case client_key_exchange: ClientKeyExchange;
case finished:Finished; case finished:Finished;
} body; } body;
} Handshake; } Handshake;
struct { struct {
Cookie cookie<H0..32>; 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 {
Cookie cookie<0..32>;
} HelloVerifyRequest; } HelloVerifyRequest;
5. Security Considerations 5. Security Considerations
This document describes a variant of TLS 1.1 and therefore most of This document describes a variant of TLS 1.1 and therefore
the security considerations are the same as those of TLS 1.1 [TLS11], most of the security considerations are the same as those of
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 is that The primary additional security consideration raised by DTLS
of denial of service. DTLS includes a cookie exchange designed to is that of denial of service. DTLS includes a cookie exchange
protect against denial of service. However, implementations which do designed to protect against denial of service. However,
not use this cookie exchange are still vulnerable to DoS. In implementations which do not use this cookie exchange are
particular, DTLS servers which do not use the cookie exchange may be still vulnerable to DoS. In particular, DTLS servers which do
used as attack amplifiers even if they themselves are not not use the cookie exchange may be used as attack amplifiers
experiencing DoS. Therefore DTLS servers SHOULD use the cookie even if they themselves are not experiencing DoS. Therefore
exchange unless there is good reason to believe that amplification is DTLS servers SHOULD use the cookie exchange unless there is
not a threat in their environment. good reason to believe that amplification is not a threat in
their environment.
6. IANA Considerations 6. IANA Considerations
This document uses the same identifier space as TLS [TLS11], so no This document uses the same identifier space as TLS [TLS11],
IANA registries are required beyond those for TLS. Identifiers MAY so no new IANA registries are required. When new identifiers
NOT be assigned for DTLS that conflict with TLS. When new identifiers are assigned for TLS, authors MUST specify whether they are
are assigned for TLS, authors MUST specify whether they are suitable suitable for DTLS.
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 References
Normative References Normative References
[PHOTURIS] Karn, P., Simpson, W., "Photuris: Session-Key Management
Protocol", RFC 2521, March 1999.
[REQ] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[REQ]
[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.
[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.
[TCP] Postel, J., "Transmission Control Protocol", [TCP] Postel, J., "Transmission Control Protocol",
RFC 793, September 1981. RFC 793, September 1981.
[TLS] Dierks, T., and Allen, C., "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[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
[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-05.txt, Congestion Control Protocol", draft-ietf-dccp-spec-11.txt,
October 2003 10 March 2005
[DNS] Mockapetris, P.V., "Domain names - implementation and
specification", RFC 1035, November 1987.
[DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation [DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation
of Datagram TLS", in Proceedings of ISOC NDSS 2004, of Datagram TLS", Proceedings of ISOC NDSS 2004, February 2004.
February 2004.
[ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998. Payload (ESP)", RFC 2406, November 1998.
[IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)",
RFC 2409, November 1998. 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 [IMAP] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 3501, March 2003. 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 - [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
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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",
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 Housley, The authors would like to thank Dan Boneh, Eu-Jin Goh, Russ
Constantine Sapuntzakis, and Hovav Shacham for discussions and Housley, Constantine Sapuntzakis, and Hovav Shacham for
comments on the design of DTLS. Thanks to the anonymous NDSS discussions and comments on the design of DTLS. Thanks to the
reviewers of our original NDSS paper on DTLS [DTLS] for their anonymous NDSS reviewers of our original NDSS paper on DTLS
comments. Also, thanks to Steve Kent for feedback that helped clarify [DTLS] for their comments. Also, thanks to Steve Kent for
many points. The section on PMTU was cribbed from the DCCP feedback that helped clarify many points. The section on PMTU
specification [DCCP]. was cribbed from the DCCP specification [DCCP]. Pasi Eronen
provided a detailed review of this specification.
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. 100 change blocks. 
409 lines changed or deleted 556 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/