RFC 6347 – Datagram Transport Layer Security Version 1.2
Internet Engineering Task Force (IETF) E. Rescorla
Request for Comments: 6347 RTFM, Inc.
Obsoletes: 4347 N. Modadugu
Category: Standards Track Google, Inc.
ISSN: 2070-1721 January 2012
Datagram Transport Layer Security Version 1.2
Abstract
This document specifies version 1.2 of the Datagram Transport Layer
Security (DTLS) protocol. The DTLS protocol provides communications
privacy for datagram protocols. The protocol allows client/server
applications to communicate in a way that is designed to prevent
eavesdropping, tampering, or message forgery. The DTLS protocol is
based on the Transport Layer Security (TLS) protocol and provides
equivalent security guarantees. Datagram semantics of the underlying
transport are preserved by the DTLS protocol. This document updates
DTLS 1.0 to work with TLS version 1.2.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6347.
Rescorla & Modadugu Standards Track [ Page 1 ]
RFC 6347 DTLS January 2012BCP 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. Rescorla & Modadugu Standards Track [ Page 2 ]
RFC 6347 DTLS January 20121. IntroductionTLS] is the most widely deployed protocol for securing network traffic. It is widely used for protecting Web traffic and for e-mail protocols such as IMAP [IMAP] and POP [POP]. The primary advantage of TLS is that it provides a transparent connection-oriented channel. Thus, it is easy to secure an application protocol by inserting TLS between the application layer and the transport layer. However, TLS must run over a reliable transport channel -- typically TCP [TCP]. Therefore, it cannot be used to secure unreliable datagram traffic. An increasing number of application layer protocols have been designed that use UDP transport. In particular, protocols such as the Session Initiation Protocol (SIP) [SIP] and electronic gaming protocols are increasingly popular. (Note that SIP can run over both TCP and UDP, but that there are situations in which UDP is preferable.) Currently, designers of these applications are faced with a number of unsatisfactory choices. First, they can use IPsec [RFC4301]. However, for a number of reasons detailed in [WHYIPSEC], this is only suitable for some applications. Second, they can design a custom application layer security protocol. Unfortunately, although application layer security protocols generally provide superior security properties (e.g., end-to-end security in the case of S/MIME), they typically require a large amount of effort to design -- in contrast to the relatively small amount of effort required to run the protocol over TLS. In many cases, the most desirable way to secure client/server applications would be to use TLS; however, the requirement for datagram semantics automatically prohibits use of TLS. This memo describes a protocol for this purpose: Datagram Transport Layer Security (DTLS). DTLS is deliberately designed to be as similar to TLS as possible, both to minimize new security invention and to maximize the amount of code and infrastructure reuse. 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. Implementations that speak both DTLS 1.2 and DTLS 1.0 can interoperate with those that speak only DTLS 1.0 (using DTLS 1.0 of course), just as TLS 1.2 implementations can interoperate with previous versions of TLS (see Appendix E.1 of [TLS12] for details), with the exception that there is no DTLS version of SSLv2 or SSLv3, so backward compatibility issues for those protocols do not apply. Rescorla & Modadugu Standards Track [ Page 4 ]
RFC 6347 DTLS January 20123.2.2. Reordering3.2.3. Message Size3.3. Replay Detection4. Differences from TLSSection 3, DTLS is intentionally very similar to TLS. Therefore, instead of presenting DTLS as a new protocol, we present it as a series of deltas from TLS 1.2 [TLS12]. Where we do not explicitly call out differences, DTLS is the same as in [TLS12]. Rescorla & Modadugu Standards Track [ Page 7 ]
RFC 6347 DTLS January 20124.1. Record Layer Rescorla & Modadugu Standards Track [ Page 8 ]
RFC 6347 DTLS January 2012TCP] to allow for packet reordering. (Note that
the intention here is that implementors use the current guidance from
the IETF for MSL, not that they attempt to interrogate the MSL that
the system TCP stack is using.) 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 message
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 messages have 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 any other case, the implementation MUST wait for the
receipt of the Finished message to prevent downgrade attack.
As in TLS, implementations MUST either abandon an association or
rehandshake prior to allowing the sequence number to wrap.
Rescorla & Modadugu Standards Track [ Page 9 ]
RFC 6347 DTLS January 2012Section 4.2.8. In practice, implementations rarely rehandshake repeatedly on the same channel, so this is not likely to be an issue. 4.1.1. Transport Layer MappingDCCP] provide their own sequence numbers. When carried over those transports, both the DTLS and the transport sequence numbers will be present. Although this introduces a small amount of inefficiency, the transport layer and DTLS sequence numbers serve different purposes; therefore, for conceptual simplicity, it is superior to use both sequence numbers. In the future, extensions to DTLS may be specified that allow the use of only one set of sequence numbers for deployment in constrained environments. Some transports, such as DCCP, provide congestion control for traffic carried over them. If the congestion window is sufficiently narrow, DTLS handshake retransmissions may be held rather than transmitted immediately, potentially leading to timeouts and spurious retransmission. When DTLS is used over such transports, care should be taken not to overrun the likely congestion window. [DCCPDTLS] defines a mapping of DTLS to DCCP that takes these issues into account. 4.1.1.1. PMTU Issues Rescorla & Modadugu Standards Track [ Page 10 ]
RFC 6347 DTLS January 2012RFC1191] "Datagram Too Big" indications or ICMPv6 [RFC4443]
"Packet Too Big" indications.
- The DTLS handshake messages can exceed the PMTU.
In order to deal with the first two issues, the DTLS record layer
SHOULD behave as described below.
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 Section 14 of [DCCP]), then the
DTLS record layer MUST 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.
Rescorla & Modadugu Standards Track [ Page 11 ]
RFC 6347 DTLS January 20124.1.2. Record Payload Protection4.1.2.1. MAC Rescorla & Modadugu Standards Track [ Page 12 ]
RFC 6347 DTLS January 2012TLS12] be followed. 4.1.2.2. Null or Standard Stream Cipher4.1.2.3. Block Cipher4.1.2.4. AEAD CiphersECCGCM] and [RSAGCM], can be used with DTLS exactly as with TLS 1.2. 4.1.2.5. New Cipher SuitesSection 7 for IANA considerations). 4.1.2.6. Anti-ReplayESP]. The receiver packet counter for this session MUST be initialized to zero when the session is established. For each received record, the receiver MUST verify that the record contains a sequence number that does not duplicate the sequence number of any other record received during the life of this session. This SHOULD be the first check applied to a packet after it has been matched to a session, to speed rejection of duplicate records. Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following text describes the functionality that the implementation must exhibit.) A minimum window size of 32 MUST be supported, but a Rescorla & Modadugu Standards Track [ Page 13 ]
RFC 6347 DTLS January 2012ESP]. If the received record falls within the window and is new, or if the packet is to the right of the window, then the receiver proceeds to MAC verification. If the MAC validation fails, the receiver MUST discard the received record as invalid. The receive window is updated only if the MAC verification succeeds. 4.1.2.7. Handling Invalid Records4.2. The DTLS Handshake Protocol Rescorla & Modadugu Standards Track [ Page 14 ]
RFC 6347 DTLS January 20124.2.1. Denial-of-Service CountermeasuresPHOTURIS] and IKE [IKEv2]. When the client sends its ClientHello message to the server, the server MAY respond with a HelloVerifyRequest message. This message contains a stateless cookie generated using the technique of [PHOTURIS]. The client MUST retransmit the ClientHello with the cookie added. The server then verifies the cookie and proceeds with the handshake only if it is valid. This mechanism forces the attacker/client to be able to receive the cookie, which makes DoS attacks with spoofed IP addresses difficult. This mechanism does not provide any defense against DoS attacks mounted from valid IP addresses. Rescorla & Modadugu Standards Track [ Page 15 ]
RFC 6347 DTLS January 2012 Rescorla & Modadugu Standards Track [ Page 16 ]
RFC 6347 DTLS January 2012IKEv2] suggests adding a version
number to cookies to detect this case. An alternative approach is
simply to try verifying with both secrets.
DTLS servers SHOULD perform a cookie exchange whenever a new
handshake is being performed. If the server is being operated in an
environment where amplification is not a problem, the server MAY be
configured not to perform a cookie exchange. The default SHOULD be
that the exchange is performed, however. In addition, the server MAY
Rescorla & Modadugu Standards Track [ Page 17 ]
RFC 6347 DTLS January 20124.2.2. Handshake Message Format Rescorla & Modadugu Standards Track [ Page 18 ]
RFC 6347 DTLS January 20124.2.3. Handshake Message Fragmentation and ReassemblySection 4.1.1, each DTLS message MUST fit within a single transport layer datagram. However, handshake messages are potentially bigger than the maximum record size. Therefore, DTLS provides a mechanism for fragmenting a handshake message over a number of records, each of which can be transmitted separately, thus avoiding IP fragmentation. Rescorla & Modadugu Standards Track [ Page 19 ]
RFC 6347 DTLS January 20124.2.4. Timeout and Retransmission Rescorla & Modadugu Standards Track [ Page 20 ]
RFC 6347 DTLS January 2012ChangeCipherSpec] /
Finished --------> /
[ChangeCipherSpec] \ Flight 6
<-------- Finished /
Figure 1. Message Flights for Full Handshake
Client Server
------ ------
ClientHello --------> Flight 1
ServerHello \
[ChangeCipherSpec] Flight 2
<-------- Finished /
[ChangeCipherSpec] \Flight 3
Finished --------> /
Figure 2. Message Flights for Session-Resuming Handshake
(No Cookie Exchange)
DTLS uses a simple timeout and retransmission scheme with the
following state machine. Because DTLS clients send the first message
(ClientHello), they start in the PREPARING state. DTLS servers start
in the WAITING state, but with empty buffers and no retransmit timer.
Rescorla & Modadugu Standards Track [ Page 21 ]
RFC 6347 DTLS January 2012 Rescorla & Modadugu Standards Track [ Page 22 ]
RFC 6347 DTLS January 2012TCP],
when in the FINISHED state, the node that 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
Rescorla & Modadugu Standards Track [ Page 23 ]
RFC 6347 DTLS January 2012DTLS1], it was always required for the state machine to function correctly. To see why this is necessary, consider what happens in an ordinary handshake if the server's Finished message is lost: the server believes the handshake is complete but it actually is not. As the client is waiting for the Finished message, the client's retransmit timer will fire and it will retransmit the client's Finished message. This will cause the server to respond with its own Finished message, completing the handshake. The same logic applies on the server side for the resumed handshake. Note that because of packet loss, it is possible for one side to be sending application data even though the other side has not received the first side's Finished message. Implementations MUST either discard or buffer all application data packets for the new epoch until they have received the Finished message for that epoch. Implementations MAY treat receipt of application data with a new epoch prior to receipt of the corresponding Finished message as evidence of reordering or packet loss and retransmit their final flight immediately, shortcutting the retransmission timer. 4.2.4.1. Timer ValuesRFC 6298 [RFC6298]) and double the value at each retransmission, up to no less than the RFC 6298 maximum of 60 seconds. Note that we recommend a 1-second timer rather than the 3-second RFC 6298 default in order to improve latency for time-sensitive applications. Because DTLS only uses retransmission for handshake and not dataflow, the effect on congestion should be minimal. Implementations SHOULD retain the current timer value until a transmission without loss occurs, at which time the value may be reset to the initial value. After a long period of idleness, no less than 10 times the current timer value, implementations may reset the timer to the initial value. One situation where this might occur is when a rehandshake is used after substantial data transfer. Rescorla & Modadugu Standards Track [ Page 24 ]
RFC 6347 DTLS January 20124.2.5. ChangeCipherSpec4.2.6. CertificateVerify and Finished Messages4.2.7. Alert Messages4.2.8. Establishing New Associations with Existing Parameters Rescorla & Modadugu Standards Track [ Page 25 ]
RFC 6347 DTLS January 20124.3. Summary of New SyntaxTLS12] for the definition of this syntax. 4.3.1. Record Layer Rescorla & Modadugu Standards Track [ Page 26 ]
RFC 6347 DTLS January 20124.3.2. Handshake Protocol5. Security ConsiderationsTLS12], described in Appendices D, E, and F. Rescorla & Modadugu Standards Track [ Page 27 ]Read more: A Few Thoughts on Cryptographic Engineering
RFC 6347 DTLS January 2012Section 4.1.2.7 for details on this. 6. AcknowledgmentsDTLS] for their comments. Also, thanks to Steve Kent for feedback that helped clarify many points. The section on PMTU was cribbed from the DCCP specification [DCCP]. Pasi Eronen provided a detailed review of this specification. Peter Saint-Andre provided the list of changes in Section 8. Helpful comments on the document were also received from Mark Allman, Jari Arkko, Mohamed Badra, Michael D'Errico, Adrian Farrell, Joel Halpern, Ted Hardie, Charlia Kaufman, Pekka Savola, Allison Mankin, Nikos Mavrogiannopoulos, Alexey Melnikov, Robin Seggelmann, Michael Tuexen, Juho Vaha-Herttua, and Florian Weimer. 7. IANA ConsiderationsTLS12], so no new IANA registries are required. When new identifiers are assigned for TLS, authors MUST specify whether they are suitable for DTLS. IANA has modified all TLS parameter registries to add a DTLS-OK flag, indicating whether the specification may be used with DTLS. At the time of publication, all of the [TLS12] registrations except the following are suitable for DTLS. The full table of registrations is available at [IANA]. From the TLS Cipher Suite Registry: 0x00,0x03 TLS_RSA_EXPORT_WITH_RC4_40_MD5 [RFC4346] 0x00,0x04 TLS_RSA_WITH_RC4_128_MD5 [RFC5246] 0x00,0x05 TLS_RSA_WITH_RC4_128_SHA [RFC5246] 0x00,0x17 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 [RFC4346] Rescorla & Modadugu Standards Track [ Page 28 ]