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 ]
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 ]

Leave a Reply

Your email address will not be published.