rfc4347.txt   draft-ietf-tls-rfc4347-bis-04.txt 
Network Working Group E. Rescorla INTERNET-DRAFT E. Rescorla
Request for Comments: 4347 RTFM, Inc. Obsoletes (if approved): RFC 4347 RTFM, Inc.
Category: Standards Track N. Modadugu Intended Status: Proposed Standard N. Modadugu
Stanford University <draft-ietf-tls-rfc4347-bis-04.txt> Stanford University
April 2006 July 12, 2010 (Expires January 2011)
Datagram Transport Layer Security Datagram Transport Layer Security version 1.2
Status of This Memo Status of This Memo
This document specifies an Internet standards track protocol for the This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet Copyright (c) 2010 IETF Trust and the persons identified as
Official Protocol Standards" (STD 1) for the standardization state the document authors. All rights reserved.
and status of this protocol. Distribution of this memo is unlimited.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents carefully,
as they describe your rights and restrictions with respect to this
document. Code Components extracted from this document must include
Simplified BSD License text as described in Section 4.e of the Trust
Legal Provisions and are provided without warranty as described in the
Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s)
controlling the copyright in such materials, this document may not
be modified outside the IETF Standards Process, and derivative
works of it may not be created outside the IETF Standards Process,
except to format it for publication as an RFC or to translate it
into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This document specifies Version 1.0 of the Datagram Transport Layer This document specifies Version 1.2 of the Datagram Transport Layer
Security (DTLS) protocol. The DTLS protocol provides communications Security (DTLS) protocol. The DTLS protocol provides communications
privacy for datagram protocols. The protocol allows client/server privacy for datagram protocols. The protocol allows client/server
applications to communicate in a way that is designed to prevent applications to communicate in a way that is designed to prevent
eavesdropping, tampering, or message forgery. The DTLS protocol is eavesdropping, tampering, or message forgery. The DTLS protocol is
based on the Transport Layer Security (TLS) protocol and provides based on the Transport Layer Security (TLS) protocol and provides
equivalent security guarantees. Datagram semantics of the underlying equivalent security guarantees. Datagram semantics of the underlying
transport are preserved by the DTLS protocol. transport are preserved by the DTLS protocol. This document updates
DTLS 1.0 to work with TLS version 1.2.
Legal
This documents and the information contained therein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Table of Contents Table of Contents
1. Introduction ....................................................2 1. Introduction 3
1.1. Requirements Terminology ...................................3 1.1. Requirements Terminology 4
2. Usage Model .....................................................3 2. Usage Model 4
3. Overview of DTLS ................................................4 3. Overview of DTLS 5
3.1. Loss-Insensitive Messaging .................................4 3.1. Loss-Insensitive Messaging 5
3.2. Providing Reliability for Handshake ........................4 3.2. Providing Reliability for Handshake 5
3.2.1. Packet Loss .........................................5 3.2.1. Packet Loss 6
3.2.2. Reordering ..........................................5 3.2.2. Reordering 6
3.2.3. Message Size ........................................5 3.2.3. Message Size 6
3.3. Replay Detection ...........................................6 3.3. Replay Detection 7
4. Differences from TLS ............................................6 4. Differences from TLS 7
4.1. Record Layer ...............................................6 4.1. Record Layer 7
4.1.1. Transport Layer Mapping .............................7 4.1.1. Transport Layer Mapping 9
4.1.1.1. PMTU Discovery .............................8 4.1.1.1. PMTU Issues 10
4.1.2. Record Payload Protection ...........................9 4.1.2. Record Payload Protection 11
4.1.2.1. MAC ........................................9 4.1.2.1. MAC 11
4.1.2.2. Null or Standard Stream Cipher .............9 4.1.2.2. Null or Standard Stream Cipher 12
4.1.2.3. Block Cipher ..............................10 4.1.2.3. Block Cipher 12
4.1.2.4. New Cipher Suites .........................10 4.1.2.3. AEAD Ciphers 12
4.1.2.5. Anti-replay ...............................10 4.1.2.5. New Cipher Suites 12
4.2. The DTLS Handshake Protocol ...............................11 4.1.2.6. Anti-replay 13
4.2.1. Denial of Service Countermeasures ..................11 4.1.2.7. Handling Invalid Records 13
4.2.2. Handshake Message Format ...........................13 4.2. The DTLS Handshake Protocol 14
4.2.3. Message Fragmentation and Reassembly ...............15 4.2.1. Denial of Service Countermeasures 14
4.2.4. Timeout and Retransmission .........................15 4.2.2. Handshake Message Format 17
4.2.4.1. Timer Values ..............................18 4.2.3. Message Fragmentation and Reassembly 18
4.2.5. ChangeCipherSpec ...................................19 4.2.4. Timeout and Retransmission 19
4.2.6. Finished Messages ..................................19 4.2.4.1. Timer Values 23
4.2.7. Alert Messages .....................................19 4.2.5. ChangeCipherSpec 23
4.3. Summary of new syntax .....................................19 4.2.6. CertificateVerify and Finished Messages 23
4.3.1. Record Layer .......................................20 4.2.7. Alert Messages 23
4.3.2. Handshake Protocol .................................20 4.3. Summary of new syntax 24
5. Security Considerations ........................................21 4.3.1. Record Layer 25
6. Acknowledgements ...............................................22 4.3.2. Handshake Protocol 25
7. IANA Considerations ............................................22 5. Security Considerations 26
8. References .....................................................22 6. Acknowledgements 27
8.1. Normative References ......................................22 7. IANA Considerations 27
8.2. Informative References ....................................23 8. References 27
8.1. Normative References 27
8.2. Informative References 28
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 network
traffic. It is widely used for protecting Web traffic and for e-mail traffic. It is widely used for protecting Web traffic and for e-mail
protocols such as IMAP [IMAP] and POP [POP]. The primary advantage protocols such as IMAP [IMAP] and POP [POP]. The primary advantage
of TLS is that it provides a transparent connection-oriented channel. of TLS is that it provides a transparent connection-oriented channel.
Thus, it is easy to secure an application protocol by inserting TLS Thus, it is easy to secure an application protocol by inserting TLS
between the application layer and the transport layer. However, TLS between the application layer and the transport layer. However, TLS
must run over a reliable transport channel -- typically TCP [TCP]. must run over a reliable transport channel -- typically TCP [TCP].
It therefore cannot be used to secure unreliable datagram traffic. It therefore cannot be used to secure unreliable datagram traffic.
However, over the past few years an increasing number of application However, an increasing number of application layer protocols have
layer protocols have been designed that use UDP transport. In been designed that use UDP transport. In particular protocols such
particular protocols such as the Session Initiation Protocol (SIP) as the Session Initiation Protocol (SIP) [SIP] and electronic gaming
[SIP] and electronic gaming protocols are increasingly popular. protocols are increasingly popular. (Note that SIP can run over both
(Note that SIP can run over both TCP and UDP, but that there are TCP and UDP, but that there are situations in which UDP is
situations in which UDP is preferable). Currently, designers of preferable). Currently, designers of these applications are faced
these applications are faced with a number of unsatisfactory choices. with a number of unsatisfactory choices. First, they can use IPsec
First, they can use IPsec [RFC2401]. However, for a number of [RFC4301]. However, for a number of reasons detailed in [WHYIPSEC],
reasons detailed in [WHYIPSEC], this is only suitable for some this is only suitable for some applications. Second, they can design
applications. Second, they can design a custom application layer a custom application layer security protocol. Unfortunately,
security protocol. SIP, for instance, uses a subset of S/MIME to although application layer security protocols generally provide
secure its traffic. Unfortunately, although application layer superior security properties (e.g., end-to-end security in the case
security protocols generally provide superior security properties of S/MIME), they typically require a large amount of effort to design
(e.g., end-to-end security in the case of S/MIME), they typically -- in contrast to the relatively small amount of effort required to
requires a large amount of effort to design -- in contrast to the run the protocol over TLS.
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. This memo
datagram-compatible variant of TLS would be very desirable. This describes a protocol for this purpose: Datagram Transport Layer
memo describes such a protocol: Datagram Transport Layer Security Security (DTLS). DTLS is deliberately designed to be as similar to
(DTLS). DTLS is deliberately designed to be as similar to TLS as TLS as possible, both to minimize new security invention and to
possible, both to minimize new security invention and to maximize the maximize the amount of code and infrastructure reuse.
amount of code and infrastructure reuse.
DTLS 1.0 [DTLS1] was originally defined as a delta from [TLS11]. This
document introduces a new version of DTLS, DTLS 1.2, which is defined
as a series of deltas to TLS 1.2 [TLS12] There is no DTLS 1.1. That
version number was skipped in order to harmonize version numbers with
TLS. This version also clarifies some confusing points in the DTLS
1.0 specification.
1.1. Requirements Terminology 1.1. Requirements Terminology
In this document, the keywords "MUST", "MUST NOT", "REQUIRED", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", and "MAY" are to be interpreted as described "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
in RFC 2119 [REQ]. document are to be 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 communicating
applications. It is designed to run in application space, without applications. It is designed to run in application space, without
requiring any kernel modifications. requiring any kernel modifications.
Datagram transport does not require or provide reliable or in-order Datagram transport does not require or provide reliable or in-order
delivery of data. The DTLS protocol preserves this property for delivery of data. The DTLS protocol preserves this property for
payload data. Applications such as media streaming, Internet payload data. Applications such as media streaming, Internet
telephony, and online gaming use datagram transport for communication telephony, and online gaming use datagram transport for communication
due to the delay-sensitive nature of transported data. The behavior due to the delay-sensitive nature of transported data. The behavior
of such applications is unchanged when the DTLS protocol is used to of such applications is unchanged when the DTLS protocol is used to
secure communication, since the DTLS protocol does not compensate for 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 transport." The reason that TLS cannot be used directly in
environments is simply that packets may be lost or reordered. TLS datagram environments is simply that packets may be lost or
has no internal facilities to handle this kind of unreliability, and reordered. TLS has no internal facilities to handle this kind of
therefore TLS implementations break when rehosted on datagram unreliability, and therefore TLS implementations break when rehosted
transport. The purpose of DTLS is to make only the minimal changes on datagram transport. The purpose of DTLS is to make only the
to TLS required to fix this problem. To the greatest extent minimal changes to TLS required to fix this problem. To the greatest
possible, DTLS is identical to TLS. Whenever we need to invent new extent possible, DTLS is identical to TLS. Whenever we need to
mechanisms, we attempt to do so in such a way that preserves the invent new mechanisms, we attempt to do so in such a way that
style of TLS. 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 does not allow independent decryption of individual
decryption of individual records. If record N is not received, records. Because the integrity check depends on the sequence
then record N+1 cannot be decrypted. number, if record N is not received, then the integrity check on
record N+1 will be based on the wrong sequence number and thus
will fail. [Note that prior to TLS 1.1, there was no explicit IV
and so decryption would also fail.]
2. The TLS handshake layer assumes that handshake messages are 2. The TLS handshake layer assumes that handshake messages are
delivered reliably and breaks if those messages are lost. 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 to
solve these problems. 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 Layer),
records are not independent. There are two kinds of inter-record records are not independent. There are two kinds of inter-record
dependency: dependency:
1. Cryptographic context (CBC state, stream cipher key stream) is 1. Cryptographic context (stream cipher key stream) is retained
chained between records. between records.
2. Anti-replay and message reordering protection are provided by a 2. Anti-replay and message reordering protection are provided by a
MAC that includes a sequence number, but the sequence numbers are MAC that includes a sequence number, but the sequence numbers are
implicit in the records. implicit in the records.
The fix for both of these problems is straightforward and well known DTLS solves the first problem by banning stream ciphers. DTLS solves
from IPsec ESP [ESP]: add explicit state to the records. TLS 1.1 the second problem by adding explicit sequence numbers.
[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 3.2. Providing Reliability for Handshake
The TLS handshake is a lockstep cryptographic handshake. Messages The TLS handshake is a lockstep cryptographic handshake. Messages
must be transmitted and received in a defined order, and any other must be transmitted and received in a defined order, and any other
order is an error. Clearly, this is incompatible with reordering and order is an error. Clearly, this is incompatible with reordering and
message loss. In addition, TLS handshake messages are potentially message loss. In addition, TLS handshake messages are potentially
larger than any given datagram, thus creating the problem of larger than any given datagram, thus creating the problem of
fragmentation. DTLS must provide fixes for both of these problems. fragmentation. DTLS must provide fixes for both of 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. The
skipping to change at page 6, line 25 skipping to change at page 7, line 28
records that have previously been received are silently discarded. records that have previously been received are silently discarded.
The replay detection feature is optional, since packet duplication is The replay detection feature is optional, since packet duplication is
not always malicious, but can also occur due to routing errors. not always malicious, but can also occur due to routing errors.
Applications may conceivably detect duplicate packets and accordingly Applications may conceivably detect duplicate packets and accordingly
modify their data transmission strategy. modify their data transmission strategy.
4. Differences from TLS 4. Differences from TLS
As mentioned in Section 3, DTLS is intentionally very similar to TLS. As mentioned in Section 3, DTLS is intentionally very similar to TLS.
Therefore, instead of presenting DTLS as a new protocol, we present 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 it as a series of deltas from TLS 1.2 [TLS12]. Where we do not
explicitly call out differences, DTLS is the same as in [TLS11]. explicitly call out differences, DTLS is the same as in [TLS12].
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.2. The
only change is the inclusion of an explicit sequence number in the only change is the inclusion of an explicit sequence number in the
record. This sequence number allows the recipient to correctly record. This sequence number allows the recipient to correctly
verify the TLS MAC. The DTLS record format is shown below: 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;
type type
Equivalent to the type field in a TLS 1.1 record. Equivalent to the type field in a TLS 1.2 record.
version version
The version of the protocol being employed. This document The version of the protocol being employed. This document
describes DTLS Version 1.0, which uses the version { 254, 255 describes DTLS Version 1.2, which uses the version { 254, 253
}. The version value of 254.255 is the 1's complement of DTLS }. The version value of 254.253 is the 1's complement of DTLS
Version 1.0. This maximal spacing between TLS and DTLS version Version 1.2. This maximal spacing between TLS and DTLS version
numbers ensures that records from the two protocols can be numbers ensures that records from the two protocols can be
easily distinguished. It should be noted that future on-the-wire easily distinguished. It should be noted that future on-the-wire
version numbers of DTLS are decreasing in value (while the true version numbers of DTLS are decreasing in value (while the true
version number is increasing in value.) version number is increasing in value.)
epoch epoch
A counter value that is incremented on every cipher state A counter value that is incremented on every cipher state
change. change.
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.2 record. As in TLS
1.1, the length should not exceed 2^14. 1.2, 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.2 record.
DTLS uses an explicit sequence number, rather than an implicit one, DTLS uses an explicit sequence number, rather than an implicit one,
carried in the sequence_number field of the record. As with TLS, the carried in the sequence_number field of the record. Sequence numbers
sequence number is set to zero after each ChangeCipherSpec message is are maintained separately for each epoch, with each sequence_number
sent. initially being 0 for each epoch. For instance, if a handshake
message from epoch 0 is retransmitted, it might have a sequence
number after a message from epoch 1, even if the message from epoch 1
was transmitted first. Note that some care needs to be taken during
the handshake to ensure that retransmitted messages use the right
epoch and keying material.
If several handshakes are performed in close succession, there might If several handshakes are performed in close succession, there might
be multiple records on the wire with the same sequence number but be multiple records on the wire with the same sequence number but
from different cipher states. The epoch field allows recipients to from different cipher states. The epoch field allows recipients to
distinguish such packets. The epoch number is initially zero and is distinguish such packets. The epoch number is initially zero and is
incremented each time the ChangeCipherSpec messages is sent. In incremented each time the ChangeCipherSpec messages is sent. In
order to ensure that any given sequence/epoch pair is unique, order to ensure that any given sequence/epoch pair is unique,
implementations MUST NOT allow the same epoch value to be reused implementations MUST NOT allow the same epoch value to be reused
within two times the TCP maximum segment lifetime. In practice, TLS within two times the TCP maximum segment lifetime. In practice, TLS
implementations rarely rehandshake and we therefore do not expect implementations rarely rehandshake and we therefore do not expect
this to be a problem. this to be a problem.
Note that because DTLS records may be reordered, a record from epoch
1 may be received after epoch 2 has begun. In general,
implementations SHOULD discard packets from earlier epochs, but if
packet loss causes noticeable problems MAY choose to retain keying
material from previous epochs for up to 120 seconds (the default TCP
MSL) to allow for packet reordering. Until the handshake has
completed, implementations MUST accept packets from the old epoch.
Conversely, it is possible for records that are protected by the
newly negotiated context to be received prior to the completion of a
handshake. For instance, the server may send its Finished and then
start transmitting data. Implementations MAY either buffer or
discard such packets, though when DTLS is used over reliable
transports (e.g., SCTP), they SHOULD be buffered and processed once
the handshake completes. Note that TLS's restrictions on when
packets may be sent still apply, and the receiver treats the packets
as if they were sent in the right order. In particular, it is still
impermissible to send data prior to completion of the first
handshake.
Note that in the special case of a rehandshake on an existing
association, it is safe to process a data packet immediately even if
the ChangeCipherSpec or Finished has not yet been received provided
that either the rehandshake resumes the existing session or that it
uses exactly the same security parameters as the existing
association. In an other case, the implementation MUST wait for the
receipt of the Finished to prevent downgrade attack.
4.1.1. Transport Layer Mapping 4.1.1. Transport Layer Mapping
Each DTLS record MUST fit within a single datagram. In order to Each DTLS record MUST fit within a single datagram. In order to
avoid IP fragmentation [MOGUL], DTLS implementations SHOULD determine avoid fragmentation, clients of the DTLS record layer SHOULD attempt
the MTU and send records smaller than the MTU. DTLS implementations to size records so that they fit within any PMTU estimates obtained
SHOULD provide a way for applications to determine the value of the from the record layer.
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 Note that unlike IPsec, DTLS records do not contain any association
identifiers. Applications must arrange to multiplex between identifiers. Applications must arrange to multiplex between
associations. With UDP, this is presumably done with host/port associations. With UDP, this is presumably done with host/port
number. number.
Multiple DTLS records may be placed in a single datagram. They are Multiple DTLS records may be placed in a single datagram. They are
simply encoded consecutively. The DTLS record framing is sufficient simply encoded consecutively. The DTLS record framing is sufficient
to determine the boundaries. Note, however, that the first byte of to determine the boundaries. Note, however, that the first byte of
the datagram payload must be the beginning of a record. Records may the datagram payload must be the beginning of a record. Records may
skipping to change at page 8, line 31 skipping to change at page 10, line 14
simplicity it is superior to use both sequence numbers. In the simplicity it is superior to use both sequence numbers. In the
future, extensions to DTLS may be specified that allow the use of future, extensions to DTLS may be specified that allow the use of
only one set of sequence numbers for deployment in constrained only one set of sequence numbers for deployment in constrained
environments. environments.
Some transports, such as DCCP, provide congestion control for traffic Some transports, such as DCCP, provide congestion control for traffic
carried over them. If the congestion window is sufficiently narrow, carried over them. If the congestion window is sufficiently narrow,
DTLS handshake retransmissions may be held rather than transmitted DTLS handshake retransmissions may be held rather than transmitted
immediately, potentially leading to timeouts and spurious immediately, potentially leading to timeouts and spurious
retransmission. When DTLS is used over such transports, care should retransmission. When DTLS is used over such transports, care should
be taken not to overrun the likely congestion window. In the future, be taken not to overrun the likely congestion window. [DCCPDTLS]
a DTLS-DCCP mapping may be specified to provide optimal behavior for defines a mapping of DTLS to DCCP that takes these issues into
this interaction. account.
4.1.1.1. PMTU Discovery 4.1.1.1. PMTU Issues
In general, DTLS's philosophy is to avoid dealing with PMTU issues. In general, DTLS's philosophy is to leave PMTU discovery to the
The general strategy is to start with a conservative MTU and then application. However, DTLS cannot completely ignore PMTU for three
update it if events during the handshake or actual application data reasons:
transport phase require it.
The PMTU SHOULD be initialized from the interface MTU that will be - The DTLS record framing expands the datagram size,
used to send packets. If the DTLS implementation receives an RFC thus lowering the effective PMTU from the application's
1191 [RFC1191] ICMP Destination Unreachable message with the perspective.
"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 - In some implementations the application may not directly
should be set with DF set. Because some firewalls and routers screen talk to the network, in which case the DTLS stack may
out ICMP messages, it is difficult for the handshake layer to absorb ICMP [RFC1191] Datagram Too Big indications.
distinguish packet loss from an overlarge PMTU estimate. In order to
allow connections under these circumstances, DTLS implementations - The DTLS handshake messages can exceed the PMTU.
SHOULD back off handshake packet size during the retransmit backoff
described in Section 4.2.4. For instance, if a large packet is being In order to deal with the first two issues, the DTLS record layer
sent, after 3 retransmits the handshake layer might choose to SHOULD behave as described below.
fragment the handshake message on retransmission. In general, choice
of a conservative initial MTU will avoid this problem. If PMTU estimates are available from the underlying transport
protocol, they should be made available to upper layer protocols. In
particular:
- For DTLS over UDP, the upper layer protocol SHOULD be allowed
to obtain the PMTU estimate maintained in the IP layer.
- For DTLS over DCCP, the upper layer protocol
SHOULD be allowed to obtain the current estimate of the
PMTU.
- For DTLS over TCP or SCTP, which automatically fragment
and reassemble datagrams, there is no PMTU limitation.
However, the upper layer protocol MUST NOT write any
record that exceeds the maximum record size of 2^14 bytes.
The DTLS record layer SHOULD allow the upper layer protocol to
discover the amount of record expansion expected by the DTLS
processing. Note that this number is only an estimate because of
block padding and the potential use of DTLS compression.
If there is a transport protocol indication (either via ICMP or via a
refusal to send the datagram as in DCCP Section 14), then DTLS record
layer should inform the upper layer protocol of the error.
The DTLS record layer SHOULD NOT interfere with upper layer protocols
performing PMTU discovery, whether via [RFC1191] or [RFC4821]
mechanisms. In particular:
- Where allowed by the underlying transport protocol,
the upper layer protocol SHOULD be allowed to set
the state of the DF bit (in IPv4) or prohibit local
fragmentation (in IPv6).
- If the underlying transport protocol allows the application
to request PMTU probing (e.g., DCCP), the DTLS record
layer should honor this request.
The final issue is the DTLS handshake protocol. From the perspective
of the DTLS record layer, this is merely another upper layer
protocol. However, DTLS handshakes occur infrequently and involve
only a few round trips, and therefore the handshake protocol PMTU
handling places a premium on rapid completion over accurate PMTU
discovery. In order to allow connections under these circumstances,
DTLS implementations SHOULD follow the following rules:
- If the DTLS record layer informs the DTLS handshake layer
that a message is too big, it SHOULD immediately attempt
to fragment it, using any existing information about the
PMTU.
- If repeated retransmissions do not result in a response, and the
PMTU is unknown, subsequent retransmissions SHOULD back off to a
smaller record size, fragmenting the handshake message as
appropriate. This standard does not specify an exact number
of retransmits to attempt before backing off, but 2-3 seems
appropriate.
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 records. The
rest of this section describes the details of that format. 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.2. However, rather than
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 using TLS's implicit sequence number, the sequence number used to
compute the MAC is the 64-bit value formed by concatenating the epoch 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 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 that the DTLS epoch + sequence number is the same length as the TLS
sequence number. sequence number.
TLS MAC calculation is parameterized on the protocol version 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, which, in the case of DTLS, is the on-the-wire version, i.e., {254,
255 } for DTLS 1.0. 253} for DTLS 1.2.
Note that one important difference between DTLS and TLS MAC handling Note that one important difference between DTLS and TLS MAC handling
is that in TLS MAC errors must result in connection termination. In is that in TLS MAC errors must result in connection termination. In
DTLS, the receiving implementation MAY simply discard the offending DTLS, the receiving implementation MAY simply discard the offending
record and continue with the connection. This change is possible record and continue with the connection. This change is possible
because DTLS records are not dependent on each other in the way that because DTLS records are not dependent on each other in the way that
TLS records are. TLS records are.
In general, DTLS implementations SHOULD silently discard data with In general, DTLS implementations SHOULD silently discard records with
bad MACs. If a DTLS implementation chooses to generate an alert when bad MACs or that are otherwise invalid. If a DTLS implementation
it receives a message with an invalid MAC, it MUST generate chooses to generate an alert when it receives a message with an
bad_record_mac alert with level fatal and terminate its connection invalid MAC, it MUST generate a bad_record_mac alert with level fatal
state. 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 cipher. The DTLS NULL cipher is performed exactly as the TLS 1.2 NULL cipher.
The only stream cipher described in TLS 1.1 is RC4, which cannot be The only stream cipher described in TLS 1.2 is RC4, which cannot be
randomly accessed. RC4 MUST NOT be used with DTLS. 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 exactly as
with TLS 1.1. with TLS 1.2.
4.1.2.4. New Cipher Suites 4.1.2.3. AEAD Ciphers
TLS 1.2 introduced authenticated encryption with additional data
(AEAD) cipher suites. The existing AEAD cipher suites, defined in
[ECCGCM] and [RSAGCM] can be used with DTLS exactly as with TLS 1.2.
4.1.2.5. New Cipher Suites
Upon registration, new TLS cipher suites MUST indicate whether they Upon registration, new TLS cipher suites MUST indicate whether they
are suitable for DTLS usage and what, if any, adaptations must be are suitable for DTLS usage and what, if any, adaptations must be
made. made.
4.1.2.5. Anti-replay 4.1.2.6. Anti-replay
DTLS records contain a sequence number to provide replay protection. DTLS records contain a sequence number to provide replay protection.
Sequence number verification SHOULD be performed using the following Sequence number verification SHOULD be performed using the following
sliding window procedure, borrowed from Section 3.4.3 of [RFC 2402]. sliding window procedure, borrowed from Section 3.4.3 of [ESP].
The receiver packet counter for this session MUST be initialized to The receiver packet counter for this session MUST be initialized to
zero when the session is established. For each received record, the zero when the session is established. For each received record, the
receiver MUST verify that the record contains a Sequence Number that receiver MUST verify that the record contains a Sequence Number that
does not duplicate the Sequence Number of any other record received does not duplicate the Sequence Number of any other record received
during the life of this session. This SHOULD be the first check 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 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 window.
skipping to change at page 10, line 45 skipping to change at page 13, line 34
Another window size (larger than the minimum) MAY be chosen by the Another window size (larger than the minimum) MAY be chosen by the
receiver. (The receiver does not notify the sender of the window receiver. (The receiver does not notify the sender of the window
size.) size.)
The "right" edge of the window represents the highest validated The "right" edge of the window represents the highest validated
Sequence Number value received on this session. Records that contain Sequence Number value received on this session. Records that contain
Sequence Numbers lower than the "left" edge of the window are Sequence Numbers lower than the "left" edge of the window are
rejected. Packets falling within the window are checked against a rejected. Packets falling within the window are checked against a
list of received packets within the window. An efficient means for list of received packets within the window. An efficient means for
performing this check, based on the use of a bit mask, is described performing this check, based on the use of a bit mask, is described
in Appendix C of [RFC 2401]. in Section 3.4.3 of [ESP].
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 if the
packet is to the right of the window, then the receiver proceeds to packet is to the right of the window, then the receiver proceeds to
MAC verification. If the MAC validation fails, the receiver MUST MAC verification. If the MAC validation fails, the receiver MUST
discard the received record as invalid. The receive window is discard the received record as invalid. The receive window is
updated only if the MAC verification succeeds. updated only if the MAC verification succeeds.
4.1.2.7. Handling Invalid Records
Unlike TLS, DTLS is resilient in the face of invalid
records (e.g., invalid formatting, length, MAC, etc.) In
general, invalid records SHOULD be silently discarded, thus
preserving the association. Implementations which choose to
generate an alert instead, MUST generate fatal level alerts to
avoid attacks where the attacker repeatedly probes the
implementation to see how it responds to various types of error.
Note that if DTLS is run over UDP, then any implementation which
does this will be extremely susceptible to DoS attacks because
UDP forgery is so easy. Thus, this practice is NOT RECOMMENDED
for such transports. If DTLS is being carried over a
transport which is resistant to forgery (e.g., SCTP with SCTP-
AUTH), then it is safer to send alerts because an attacker will
have difficulty forging a datagram which will not be rejected by the
transport layer.
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, with
three principal changes: 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 denial of
service attacks. service attacks.
2. Modifications to the handshake header to handle message loss, 2. Modifications to the handshake header to handle message loss,
reordering, and fragmentation. 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 logic are
the same as those of TLS 1.1. the same as those of TLS 1.2.
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 variety of
denial of service (DoS) attacks. Two attacks are of particular denial of service (DoS) attacks. Two attacks are of particular
concern: concern:
1. An attacker can consume excessive resources on the server by 1. An attacker can consume excessive resources on the server by
transmitting a series of handshake initiation requests, causing transmitting a series of handshake initiation requests, causing
the server to allocate state and potentially to perform expensive the server to allocate state and potentially to perform expensive
cryptographic operations. 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 sending
connection initiation messages with a forged source of the victim. connection initiation messages with a forged source of the victim.
The server then sends its next message (in DTLS, a Certificate The server then sends its next message (in DTLS, a Certificate
message, which can be quite large) to the victim machine, thus message, which can be quite large) to the victim machine, thus
flooding it. flooding it.
In order to counter both of these attacks, DTLS borrows the stateless In order to counter both of these attacks, DTLS borrows the stateless
cookie technique used by Photuris [PHOTURIS] and IKE [IKE]. When the cookie technique used by Photuris [PHOTURIS] and IKE [IKEv2]. When
client sends its ClientHello message to the server, the server MAY the client sends its ClientHello message to the server, the server
respond with a HelloVerifyRequest message. This message contains a MAY respond with a HelloVerifyRequest message. This message contains
stateless cookie generated using the technique of [PHOTURIS]. The a stateless cookie generated using the technique of [PHOTURIS]. The
client MUST retransmit the ClientHello with the cookie added. The client MUST retransmit the ClientHello with the cookie added. The
server then verifies the cookie and proceeds with the handshake only server then verifies the cookie and proceeds with the handshake only
if it is valid. This mechanism forces the attacker/client to be able if it is valid. This mechanism forces the attacker/client to be able
to receive the cookie, which makes DoS attacks with spoofed IP to receive the cookie, which makes DoS attacks with spoofed IP
addresses difficult. This mechanism does not provide any defense addresses difficult. This mechanism does not provide any defense
against DoS attacks mounted from valid IP addresses. against DoS attacks mounted from valid IP addresses.
The exchange is shown below: The exchange is shown below:
Client Server Client Server
skipping to change at page 12, line 26 skipping to change at page 15, line 29
[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 cookie
value. 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..2^8-1>; // 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 cookie When sending the first ClientHello, the client does not have a cookie
yet; in this case, the Cookie field is left empty (zero length). 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 {
ProtocolVersion server_version; ProtocolVersion server_version;
opaque cookie<0..32>; opaque cookie<0..2^8-1>;
} HelloVerifyRequest; } HelloVerifyRequest;
The HelloVerifyRequest message type is hello_verify_request(3). The HelloVerifyRequest message type is hello_verify_request(3).
The server_version field is defined as in TLS. The server_version field is defined as in TLS.
When responding to a HelloVerifyRequest the client MUST use the same When responding to a HelloVerifyRequest the client MUST use the same
parameter values (version, random, session_id, cipher_suites, parameter values (version, random, session_id, cipher_suites,
compression_method) as it did in the original ClientHello. The compression_method) as it did in the original ClientHello. The
server SHOULD use those values to generate its cookie and verify that server SHOULD use those values to generate its cookie and verify that
they are correct upon cookie receipt. The server MUST use the same they are correct upon cookie receipt. The server MUST use the same
version number in the HelloVerifyRequest that it would use when version number in the HelloVerifyRequest that it would use when
sending a ServerHello. Upon receipt of the ServerHello, the client sending a ServerHello. Upon receipt of the ServerHello, the client
MUST verify that the server version values match. MUST verify that the server version values match.
Note: this specification increases the cookie size limit to 255 bytes
for greater future flexibility. The limit remains 32 for previous
versions of DTLS.
The DTLS server SHOULD generate cookies in such a way that they can The DTLS server SHOULD generate cookies in such a way that they can
be verified without retaining any per-client state on the server. be verified without retaining any per-client state on the server.
One technique is to have a randomly generated secret and generate One technique is to have a randomly generated secret and generate
cookies as: Cookie = HMAC(Secret, Client-IP, Client-Parameters) cookies as: Cookie = HMAC(Secret, Client-IP, Client-Parameters)
When the second ClientHello is received, the server can verify that When the second ClientHello is received, the server can verify that
the Cookie is valid and that the client can receive packets at the the Cookie is valid and that the client can receive packets at the
given IP address. given IP address.
One potential attack on this scheme is for the attacker to collect a One potential attack on this scheme is for the attacker to collect a
number of cookies from different addresses and then reuse them to number of cookies from different addresses and then reuse them to
attack the server. The server can defend against this attack by attack the server. The server can defend against this attack by
changing the Secret value frequently, thus invalidating those changing the Secret value frequently, thus invalidating those
cookies. If the server wishes that legitimate clients be able to cookies. If the server wishes that legitimate clients be able to
skipping to change at page 13, line 37 skipping to change at page 16, line 46
handshake is being performed. If the server is being operated in an handshake is being performed. If the server is being operated in an
environment where amplification is not a problem, the server MAY be environment where amplification is not a problem, the server MAY be
configured not to perform a cookie exchange. The default SHOULD be configured not to perform a cookie exchange. The default SHOULD be
that the exchange is performed, however. In addition, the server MAY that the exchange is performed, however. In addition, the server MAY
choose not to do a cookie exchange when a session is resumed. choose not to do a cookie exchange when a session is resumed.
Clients MUST be prepared to do a cookie exchange with every Clients MUST be prepared to do a cookie exchange with every
handshake. 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. handshake_messages (for the CertificateVerify message) and
verify_data (for the Finished message).
If a server receives a ClientHello with an invalid cookie, it SHOULD
treat it the same as a ClientHello with no cookie. This avoids
race/deadlock conditions if the client somehow gets a bad cookie
(e.g., because the server changes its cookie signing key). Note to
implementors: this may results in clients receiving multiple
HelloVerifyRequest messages with different cookies. Clients SHOULD
handle this by sending a new ClientHello with a cookie in response to
the new HelloVerifyRequest.
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 fragmentation, DTLS
modifies the TLS 1.1 handshake header: modifies the TLS 1.2 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;
case hello_verify_request: HelloVerifyRequest; // New type case hello_verify_request: HelloVerifyRequest; // New type
case server_hello: ServerHello; case server_hello: ServerHello;
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 has
message_seq = 0. Whenever each new message is generated, the message_seq = 0. Whenever each new message is generated, the
message_seq value is incremented by one. When a message is 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
------ ------ ------ ------
skipping to change at page 15, line 33 skipping to change at page 19, line 6
message is labelled with the fragment_offset (the number of bytes message is labelled with the fragment_offset (the number of bytes
contained in previous fragments) and the fragment_length (the length contained in previous fragments) and the fragment_length (the length
of this fragment). The length field in all messages is the same as of this fragment). The length field in all messages is the same as
the length field of the original message. An unfragmented message is the length field of the original message. An unfragmented message is
a degenerate case with fragment_offset=0 and fragment_length=length. 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 fragment, it
MUST buffer it until it has the entire handshake message. DTLS MUST buffer it until it has the entire handshake message. DTLS
implementations MUST be able to handle overlapping fragment ranges. implementations MUST be able to handle overlapping fragment ranges.
This allows senders to retransmit handshake messages with smaller This allows senders to retransmit handshake messages with smaller
fragment sizes during path MTU discovery. fragment sizes if the PMTU estimate changes.
Note that as with TLS, multiple handshake messages may be placed in Note that as with TLS, multiple handshake messages may be placed in
the same DTLS record, provided that there is room and that they are the same DTLS record, provided that there is room and that they are
part of the same flight. Thus, there are two acceptable ways to pack part of the same flight. Thus, there are two acceptable ways to pack
two DTLS messages into the same datagram: in the same record or in two DTLS messages into the same datagram: in the same record or in
separate records. 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, according
skipping to change at page 17, line 45 skipping to change at page 21, line 45
last | | | last | | |
flight | | | flight | | |
| | | | | |
\|/\|/ | \|/\|/ |
| |
+-----------+ | +-----------+ |
| | | | | |
| FINISHED | -------------------------------+ | FINISHED | -------------------------------+
| | | |
+-----------+ +-----------+
| /|\
| |
| |
+---+
Read retransmit
Retransmit last flight
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 computations
are necessary to prepare the next flight of messages. It then are necessary to prepare the next flight of messages. It then
buffers them up for transmission (emptying the buffer first) and buffers them up for transmission (emptying the buffer first) and
enters the SENDING state. enters the SENDING state.
In the SENDING state, the implementation transmits the buffered In the SENDING state, the implementation transmits the buffered
skipping to change at page 18, line 31 skipping to change at page 22, line 34
retransmit timer, and returns to the WAITING state. 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 peer:
the implementation transitions to the SENDING state, where it the implementation transitions to the SENDING state, where it
retransmits the flight, resets the retransmit timer, and returns retransmits the flight, resets the retransmit timer, and returns
to the WAITING state. The rationale here is that the receipt of a to the WAITING state. The rationale here is that the receipt of a
duplicate message is the likely result of timer expiry on the peer duplicate message is the likely result of timer expiry on the peer
and therefore suggests that part of one's previous flight was and therefore suggests that part of one's previous flight was
lost. lost.
3. The implementation receives the next flight of messages: if 3. The implementation receives the next flight of messages: if
this is the final flight of messages, the implementation this is the final flight of messages, the implementation
transitions to FINISHED. If the implementation needs to send a transitions to FINISHED. If the implementation needs to send a
new flight, it transitions to the PREPARING state. Partial reads new flight, it transitions to the PREPARING state. Partial reads
(whether partial messages or only some of the messages in the (whether partial messages or only some of the messages in the
flight) do not cause state transitions or timer resets. flight) do not cause state transitions or timer resets.
Because DTLS clients send the first message (ClientHello), they start Because DTLS clients send the first message (ClientHello), they start
in the PREPARING state. DTLS servers start in the WAITING state, but in the PREPARING state. DTLS servers start in the WAITING state, but
with empty buffers and no retransmit timer. with empty buffers and no retransmit timer.
When the server desires a rehandshake, it transitions from the When the server desires a rehandshake, it transitions from the
FINISHED state to the PREPARING state to transmit the HelloRequest. FINISHED state to the PREPARING state to transmit the HelloRequest.
When the client receives a HelloRequest it transitions from FINISHED When the client receives a HelloRequest it transitions from FINISHED
to PREPARING to transmit the ClientHello. to PREPARING to transmit the ClientHello. In addition, for at least
2MSL, when in the FINISHED state, the node which transmits the last
flight (the server in an ordinary handshake or the client in a
resumed handshake) MUST respond to a retransmit of the peer's last
flight with a retransmit of the last flight. This avoids deadlock
conditions if the last flight gets lost. This requirement applies to
DTLS 1.0 as well, and though not explicit in [DTLS1] but was always
required for the state machine to function correctly.
4.2.4.1. Timer Values 4.2.4.1. Timer Values
Though timer values are the choice of the implementation, mishandling Though timer values are the choice of the implementation, mishandling
of the timer can lead to serious congestion problems; for example, if of the timer can lead to serious congestion problems; for example, if
many instances of a DTLS time out early and retransmit too quickly on many instances of a DTLS time out early and retransmit too quickly on
a congested link. Implementations SHOULD use an initial timer value a congested link. Implementations SHOULD use an initial timer value
of 1 second (the minimum defined in RFC 2988 [RFC2988]) and double of 1 second (the minimum defined in RFC 2988 [RFC2988]) and double
the value at each retransmission, up to no less than the RFC 2988 the value at each retransmission, up to no less than the RFC 2988
maximum of 60 seconds. Note that we recommend a 1-second timer maximum of 60 seconds. Note that we recommend a 1-second timer
skipping to change at page 19, line 26 skipping to change at page 23, line 37
timer to the initial value. One situation where this might occur is timer to the initial value. One situation where this might occur is
when a rehandshake is used after substantial data transfer. 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 flight as handshake message but MUST be treated as part of the same flight as
the associated Finished message for the purposes of timeout and the associated Finished message for the purposes of timeout and
retransmission. retransmission.
4.2.6. Finished Messages 4.2.6. CertificateVerify and Finished Messages
Finished messages have the same format as in TLS. However, in order CertificateVerify and Finished messages have the same format as in
to remove sensitivity to fragmentation, the Finished MAC MUST be TLS. Hash calculations include entire handshake messages, including
computed as if each handshake message had been sent as a single DTLS specific fields: message_seq, fragment_offset and
fragment. Note that in cases where the cookie exchange is used, the fragment_length. However, in order to remove sensitivity to
initial ClientHello and HelloVerifyRequest MUST NOT be included in fragmentation, the Finished MAC MUST be computed as if each handshake
the Finished MAC. message had been sent as a single fragment. Note that in cases where
the cookie exchange is used, the initial ClientHello and
HelloVerifyRequest MUST NOT be included in the CertificateVerify or
Finished MAC computations.
4.2.7. Alert Messages 4.2.7. Alert Messages
Note that Alert messages are not retransmitted at all, even when they Note that Alert messages are not retransmitted at all, even when they
occur in the context of a handshake. However, a DTLS implementation occur in the context of a handshake. However, a DTLS implementation
SHOULD generate a new alert message if the offending record is SHOULD generate a new alert message if the offending record is
received again (e.g., as a retransmitted handshake message). received again (e.g., as a retransmitted handshake message).
Implementations SHOULD detect when a peer is persistently sending bad Implementations SHOULD detect when a peer is persistently sending bad
messages and terminate the local connection state after such messages and terminate the local connection state after such
misbehavior is detected. misbehavior is detected.
4.3. Summary of new syntax 4.3. Summary of new syntax
skipping to change at page 19, line 48 skipping to change at page 24, line 15
occur in the context of a handshake. However, a DTLS implementation occur in the context of a handshake. However, a DTLS implementation
SHOULD generate a new alert message if the offending record is SHOULD generate a new alert message if the offending record is
received again (e.g., as a retransmitted handshake message). received again (e.g., as a retransmitted handshake message).
Implementations SHOULD detect when a peer is persistently sending bad Implementations SHOULD detect when a peer is persistently sending bad
messages and terminate the local connection state after such messages and terminate the local connection state after such
misbehavior is detected. misbehavior is detected.
4.3. Summary of new syntax 4.3. Summary of new syntax
This section includes specifications for the data structures that This section includes specifications for the data structures that
have changed between TLS 1.1 and DTLS. have changed between TLS 1.2 and DTLS.
4.3.1. Record Layer 4.3.1. 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];
skipping to change at page 20, line 33 skipping to change at page 25, line 33
} DTLSCompressed; } DTLSCompressed;
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;
select (CipherSpec.cipher_type) { select (CipherSpec.cipher_type) {
case block: GenericBlockCipher; case block: GenericBlockCipher;
case aead: GenericAEADCipher; // New field
} fragment; } fragment;
} DTLSCiphertext; } DTLSCiphertext;
4.3.2. Handshake Protocol 4.3.2. Handshake Protocol
enum { enum {
hello_request(0), client_hello(1), server_hello(2), hello_request(0), client_hello(1), server_hello(2),
hello_verify_request(3), // New field hello_verify_request(3), // New field
certificate(11), server_key_exchange (12), certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14), certificate_request(13), server_hello_done(14),
skipping to change at page 21, line 15 skipping to change at page 26, line 16
case hello_request: HelloRequest; case hello_request: HelloRequest;
case client_hello: ClientHello; case client_hello: ClientHello;
case server_hello: ServerHello; case server_hello: ServerHello;
case hello_verify_request: HelloVerifyRequest; // New field case hello_verify_request: HelloVerifyRequest; // New field
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;
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..2^8-1>; // 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 {
ProtocolVersion server_version; ProtocolVersion server_version;
opaque cookie<0..32>; opaque cookie<0..2^8-1>;
} 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.2 and therefore most of
the security considerations are the same as those of TLS 1.1 [TLS11], the security considerations are the same as those of TLS 1.2 [TLS12],
described in Appendices D, E, and F. 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 is that
of denial of service. DTLS includes a cookie exchange designed to of denial of service. DTLS includes a cookie exchange designed to
protect against denial of service. However, implementations which do protect against denial of service. However, implementations which do
not use this cookie exchange are still vulnerable to DoS. In not use this cookie exchange are still vulnerable to DoS. In
particular, DTLS servers which do not use the cookie exchange may be particular, DTLS servers which do not use the cookie exchange may be
used as attack amplifiers even if they themselves are not used as attack amplifiers even if they themselves are not
experiencing DoS. Therefore, DTLS servers SHOULD use the cookie experiencing DoS. Therefore, DTLS servers SHOULD use the cookie
exchange unless there is good reason to believe that amplification is exchange unless there is good reason to believe that amplification is
skipping to change at page 22, line 15 skipping to change at page 27, line 15
6. Acknowledgements 6. 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 Housley,
Constantine Sapuntzakis, and Hovav Shacham for discussions and Constantine Sapuntzakis, and Hovav Shacham for discussions and
comments on the design of DTLS. Thanks to the anonymous NDSS comments on the design of DTLS. Thanks to the anonymous NDSS
reviewers of our original NDSS paper on DTLS [DTLS] for their reviewers of our original NDSS paper on DTLS [DTLS] for their
comments. Also, thanks to Steve Kent for feedback that helped comments. Also, thanks to Steve Kent for feedback that helped
clarify many points. The section on PMTU was cribbed from the DCCP clarify many points. The section on PMTU was cribbed from the DCCP
specification [DCCP]. Pasi Eronen provided a detailed review of this specification [DCCP]. Pasi Eronen provided a detailed review of this
specification. Helpful comments on the document were also received specification. Helpful comments on the document were also received
from Mark Allman, Jari Arkko, Joel Halpern, Ted Hardie, and Allison from Mark Allman, Jari Arkko, Mohamed Badra, Michael D'Errico, Joel
Mankin. Halpern, Ted Hardie, Allison Mankin, Robin Seggelman and Michael
Tuexen.
7. IANA Considerations 7. IANA Considerations
This document uses the same identifier space as TLS [TLS11], so no This document uses the same identifier space as TLS [TLS12], so no
new IANA registries are required. When new identifiers are assigned new IANA registries are required. When new identifiers are assigned
for TLS, authors MUST specify whether they are suitable for DTLS. for TLS, authors MUST specify whether they are suitable for DTLS.
This document defines a new handshake message, hello_verify_request, This document defines a new handshake message, hello_verify_request,
whose value has been allocated from the TLS HandshakeType registry whose value has been allocated from the TLS HandshakeType registry
defined in [TLS11]. The value "3" has been assigned by the IANA. defined in [TLS12]. The value "3" has been assigned by the IANA.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990. November 1990.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
for IP version 6", RFC 1981, August 1996. Internet Protocol", RFC 4301, December 2005.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000. Timer", RFC 2988, November 2000.
[RFC4821] Mathis, M., and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007.
[RSAGCM] Salowey, J., Choudhury, A., and D. McGrew, "AES-GCM Cipher
Suites for TLS", RFC 5288, August 2008.
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981. 793, September 1981.
[TLS11] Dierks, T. and E. Rescorla, "The Transport Layer Security [TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.2", RFC 5246, May 2008.
8.2. Informative References 8.2. Informative References
[AESCACHE] Bernstein, D.J., "Cache-timing attacks on AES"
http://cr.yp.to/antiforgery/cachetiming-20050414.pdf.
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", 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", Work in Progress, 10 March Congestion Control Protocol", Work in Progress, 10 March
2005. 2005.
[DNS] Mockapetris, P., "Domain names - implementation and [DCCPDTLS] T. Phelan, "Datagram Transport Layer Security (DTLS) over
specification", STD 13, RFC 1035, November 1987. the Datagram Congestion Control Protocol (DCCP)", RFC
5238, May 2008.
[DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation [DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation
of Datagram TLS", Proceedings of ISOC NDSS 2004, February of Datagram TLS", Proceedings of ISOC NDSS 2004, February
2004. 2004.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security [DTLS1] Rescorla, E., and N. Modadugu, "Datagram Transport Layer
Payload (ESP)", RFC 2406, November 1998. Security", RFC 4347, April 2006.
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange [ECCGCM] E. Rescorla, "TLS Elliptic Curve Cipher Suites with
(IKE)", RFC 2409, November 1998. SHA-256/384 and AES Galois Counter Mode", RFC 5289, August
2008.
[ESP] S. Kent "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[IKEv2] C. Kaufman (ed), "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
December 2005. December 2005.
[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. and W. Simpson, "ICMP Security Failures [PHOTURIS] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Messages", RFC 2521, March 1999. Protocol", RFC 2522, March 1999.
[POP] Myers, J. and M. Rose, "Post Office Protocol - Version 3", [POP] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996. STD 53, 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] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[TLS11] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec",
Work in Progress, October 2003. Work in Progress, October 2003.
Authors' Addresses Authors' Addresses
Eric Rescorla Eric Rescorla
RTFM, Inc. RTFM, Inc.
2064 Edgewood Drive 2064 Edgewood Drive
Palo Alto, CA 94303 Palo Alto, CA 94303
EMail: ekr@rtfm.com EMail: ekr@rtfm.com
Nagendra Modadugu Nagendra Modadugu
Computer Science Department Computer Science Department
Stanford University Stanford University
353 Serra Mall 353 Serra Mall
Stanford, CA 94305 Stanford, CA 94305
EMail: nagendra@cs.stanford.edu EMail: nagendra@cs.stanford.edu
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 78 change blocks. 
220 lines changed or deleted 412 lines changed or added

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