summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6347.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6347.txt')
-rw-r--r--doc/rfc/rfc6347.txt1795
1 files changed, 1795 insertions, 0 deletions
diff --git a/doc/rfc/rfc6347.txt b/doc/rfc/rfc6347.txt
new file mode 100644
index 0000000..af118d3
--- /dev/null
+++ b/doc/rfc/rfc6347.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+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 2012
+
+
+Copyright Notice
+
+ Copyright (c) 2012 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
+ (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 2012
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 1.1. Requirements Terminology ...................................5
+ 2. Usage Model .....................................................5
+ 3. Overview of DTLS ................................................5
+ 3.1. Loss-Insensitive Messaging .................................6
+ 3.2. Providing Reliability for Handshake ........................6
+ 3.2.1. Packet Loss .........................................6
+ 3.2.2. Reordering ..........................................7
+ 3.2.3. Message Size ........................................7
+ 3.3. Replay Detection ...........................................7
+ 4. Differences from TLS ............................................7
+ 4.1. Record Layer ...............................................8
+ 4.1.1. Transport Layer Mapping ............................10
+ 4.1.1.1. PMTU Issues ...............................10
+ 4.1.2. Record Payload Protection ..........................12
+ 4.1.2.1. MAC .......................................12
+ 4.1.2.2. Null or Standard Stream Cipher ............13
+ 4.1.2.3. Block Cipher ..............................13
+ 4.1.2.4. AEAD Ciphers ..............................13
+ 4.1.2.5. New Cipher Suites .........................13
+ 4.1.2.6. Anti-Replay ...............................13
+ 4.1.2.7. Handling Invalid Records ..................14
+ 4.2. The DTLS Handshake Protocol ...............................14
+ 4.2.1. Denial-of-Service Countermeasures ..................15
+ 4.2.2. Handshake Message Format ...........................18
+ 4.2.3. Handshake Message Fragmentation and Reassembly .....19
+ 4.2.4. Timeout and Retransmission .........................20
+ 4.2.4.1. Timer Values ..............................24
+ 4.2.5. ChangeCipherSpec ...................................25
+ 4.2.6. CertificateVerify and Finished Messages ............25
+ 4.2.7. Alert Messages .....................................25
+ 4.2.8. Establishing New Associations with Existing
+ Parameters .........................................25
+ 4.3. Summary of New Syntax .....................................26
+ 4.3.1. Record Layer .......................................26
+ 4.3.2. Handshake Protocol .................................27
+ 5. Security Considerations ........................................27
+ 6. Acknowledgments ................................................28
+ 7. IANA Considerations ............................................28
+ 8. Changes since DTLS 1.0 .........................................29
+ 9. References .....................................................30
+ 9.1. Normative References ......................................30
+ 9.2. Informative References ....................................31
+
+
+
+
+
+
+Rescorla & Modadugu Standards Track [Page 3]
+
+RFC 6347 DTLS January 2012
+
+
+1. Introduction
+
+ TLS [TLS] is the most widely deployed protocol for securing network
+ traffic. It is widely used for protecting Web traffic and for e-mail
+ protocols such as IMAP [IMAP] and POP [POP]. The primary advantage
+ of TLS is that it provides a transparent connection-oriented channel.
+ Thus, it is easy to secure an application protocol by inserting TLS
+ between the application layer and the transport layer. However, TLS
+ must run over a reliable transport channel -- typically TCP [TCP].
+ 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 2012
+
+
+1.1. Requirements Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [REQ].
+
+2. Usage Model
+
+ The DTLS protocol is designed to secure data between communicating
+ applications. It is designed to run in application space, without
+ requiring any kernel modifications.
+
+ Datagram transport does not require or provide reliable or in-order
+ delivery of data. The DTLS protocol preserves this property for
+ payload data. Applications such as media streaming, Internet
+ telephony, and online gaming use datagram transport for communication
+ due to the delay-sensitive nature of transported data. The behavior
+ of such applications is unchanged when the DTLS protocol is used to
+ secure communication, since the DTLS protocol does not compensate for
+ lost or re-ordered data traffic.
+
+3. Overview of DTLS
+
+ The basic design philosophy of DTLS is to construct "TLS over
+ datagram transport". The reason that TLS cannot be used directly in
+ datagram environments is simply that packets may be lost or
+ reordered. TLS has no internal facilities to handle this kind of
+ unreliability; therefore, TLS implementations break when rehosted on
+ datagram transport. The purpose of DTLS is to make only the minimal
+ changes to TLS required to fix this problem. To the greatest extent
+ possible, DTLS is identical to TLS. Whenever we need to invent new
+ mechanisms, we attempt to do so in such a way that preserves the
+ style of TLS.
+
+ Unreliability creates problems for TLS at two levels:
+
+ 1. TLS does not allow independent decryption of individual
+ records. Because the integrity check depends on the sequence
+ 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
+ delivered reliably and breaks if those messages are lost.
+
+ The rest of this section describes the approach that DTLS uses to
+ solve these problems.
+
+
+
+Rescorla & Modadugu Standards Track [Page 5]
+
+RFC 6347 DTLS January 2012
+
+
+3.1. Loss-Insensitive Messaging
+
+ In TLS's traffic encryption layer (called the TLS Record Layer),
+ records are not independent. There are two kinds of inter-record
+ dependency:
+
+ 1. Cryptographic context (stream cipher key stream) is retained
+ between records.
+
+ 2. Anti-replay and message reordering protection are provided by a
+ MAC that includes a sequence number, but the sequence numbers
+ are implicit in the records.
+
+ DTLS solves the first problem by banning stream ciphers. DTLS solves
+ the second problem by adding explicit sequence numbers.
+
+3.2. Providing Reliability for Handshake
+
+ The TLS handshake is a lockstep cryptographic handshake. Messages
+ must be transmitted and received in a defined order; any other order
+ is an error. Clearly, this is incompatible with reordering and
+ message loss. In addition, TLS handshake messages are potentially
+ larger than any given datagram, thus creating the problem of IP
+ fragmentation. DTLS must provide fixes for both of these problems.
+
+3.2.1. Packet Loss
+
+ DTLS uses a simple retransmission timer to handle packet loss. The
+ following figure demonstrates the basic concept, using the first
+ phase of the DTLS handshake:
+
+ Client Server
+ ------ ------
+ ClientHello ------>
+
+ X<-- HelloVerifyRequest
+ (lost)
+
+ [Timer Expires]
+
+ ClientHello ------>
+ (retransmit)
+
+ Once the client has transmitted the ClientHello message, it expects
+ to see a HelloVerifyRequest from the server. However, if the
+ server's message is lost, the client knows that either the
+ ClientHello or the HelloVerifyRequest has been lost and retransmits.
+ When the server receives the retransmission, it knows to retransmit.
+
+
+
+Rescorla & Modadugu Standards Track [Page 6]
+
+RFC 6347 DTLS January 2012
+
+
+ The server also maintains a retransmission timer and retransmits when
+ that timer expires.
+
+ Note that timeout and retransmission do not apply to the
+ HelloVerifyRequest, because this would require creating state on the
+ server. The HelloVerifyRequest is designed to be small enough that
+ it will not itself be fragmented, thus avoiding concerns about
+ interleaving multiple HelloVerifyRequests.
+
+3.2.2. Reordering
+
+ In DTLS, each handshake message is assigned a specific sequence
+ number within that handshake. When a peer receives a handshake
+ message, it can quickly determine whether that message is the next
+ message it expects. If it is, then it processes it. If not, it
+ queues it for future handling once all previous messages have been
+ received.
+
+3.2.3. Message Size
+
+ TLS and DTLS handshake messages can be quite large (in theory up to
+ 2^24-1 bytes, in practice many kilobytes). By contrast, UDP
+ datagrams are often limited to <1500 bytes if IP fragmentation is not
+ desired. In order to compensate for this limitation, each DTLS
+ handshake message may be fragmented over several DTLS records, each
+ of which is intended to fit in a single IP datagram. Each DTLS
+ handshake message contains both a fragment offset and a fragment
+ length. Thus, a recipient in possession of all bytes of a handshake
+ message can reassemble the original unfragmented message.
+
+3.3. Replay Detection
+
+ DTLS optionally supports record replay detection. The technique used
+ is the same as in IPsec AH/ESP, by maintaining a bitmap window of
+ received records. Records that are too old to fit in the window and
+ records that have previously been received are silently discarded.
+ The replay detection feature is optional, since packet duplication is
+ not always malicious, but can also occur due to routing errors.
+ Applications may conceivably detect duplicate packets and accordingly
+ modify their data transmission strategy.
+
+4. Differences from TLS
+
+ As mentioned in Section 3, DTLS is intentionally very similar to TLS.
+ Therefore, instead of presenting DTLS as a new protocol, we present
+ it as a series of deltas from TLS 1.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 2012
+
+
+4.1. Record Layer
+
+ 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
+ record. This sequence number allows the recipient to correctly
+ verify the TLS MAC. The DTLS record format is shown below:
+
+ struct {
+ ContentType type;
+ ProtocolVersion version;
+ uint16 epoch; // New field
+ uint48 sequence_number; // New field
+ uint16 length;
+ opaque fragment[DTLSPlaintext.length];
+ } DTLSPlaintext;
+
+ type
+ Equivalent to the type field in a TLS 1.2 record.
+
+ version
+ The version of the protocol being employed. This document
+ describes DTLS version 1.2, which uses the version { 254, 253 }.
+ The version value of 254.253 is the 1's complement of DTLS version
+ 1.2. This maximal spacing between TLS and DTLS version numbers
+ ensures that records from the two protocols can be easily
+ distinguished. It should be noted that future on-the-wire version
+ numbers of DTLS are decreasing in value (while the true version
+ number is increasing in value.)
+
+ epoch
+ A counter value that is incremented on every cipher state change.
+
+ sequence_number
+ The sequence number for this record.
+
+ length
+ Identical to the length field in a TLS 1.2 record. As in TLS 1.2,
+ the length should not exceed 2^14.
+
+ fragment
+ Identical to the fragment field of a TLS 1.2 record.
+
+ DTLS uses an explicit sequence number, rather than an implicit one,
+ carried in the sequence_number field of the record. Sequence numbers
+ are maintained separately for each epoch, with each sequence_number
+ 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
+
+
+
+Rescorla & Modadugu Standards Track [Page 8]
+
+RFC 6347 DTLS January 2012
+
+
+ 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
+ be multiple records on the wire with the same sequence number but
+ from different cipher states. The epoch field allows recipients to
+ distinguish such packets. The epoch number is initially zero and is
+ incremented each time a ChangeCipherSpec message is sent. In order
+ to ensure that any given sequence/epoch pair is unique,
+ implementations MUST NOT allow the same epoch value to be reused
+ within two times the TCP maximum segment lifetime. In practice, TLS
+ implementations rarely rehandshake; therefore, we do not expect 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 they MAY choose to retain
+ keying material from previous epochs for up to the default MSL
+ specified for TCP [TCP] 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 2012
+
+
+ Similarly, implementations MUST NOT allow the epoch to wrap, but
+ instead MUST establish a new association, terminating the old
+ association as described in Section 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 Mapping
+
+ Each DTLS record MUST fit within a single datagram. In order to
+ avoid IP fragmentation, clients of the DTLS record layer SHOULD
+ attempt to size records so that they fit within any PMTU estimates
+ obtained from the record layer.
+
+ Note that unlike IPsec, DTLS records do not contain any association
+ identifiers. Applications must arrange to multiplex between
+ associations. With UDP, this is presumably done with the host/port
+ number.
+
+ Multiple DTLS records may be placed in a single datagram. They are
+ simply encoded consecutively. The DTLS record framing is sufficient
+ to determine the boundaries. Note, however, that the first byte of
+ the datagram payload must be the beginning of a record. Records may
+ not span datagrams.
+
+ Some transports, such as DCCP [DCCP] provide their own sequence
+ numbers. When carried over those transports, both the DTLS and the
+ transport sequence numbers will be present. Although this introduces
+ a small amount of inefficiency, the transport layer and DTLS sequence
+ numbers serve different purposes; 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
+
+ In general, DTLS's philosophy is to leave PMTU discovery to the
+ application. However, DTLS cannot completely ignore PMTU for three
+ reasons:
+
+
+
+Rescorla & Modadugu Standards Track [Page 10]
+
+RFC 6347 DTLS January 2012
+
+
+ - The DTLS record framing expands the datagram size, thus lowering
+ the effective PMTU from the application's perspective.
+
+ - In some implementations, the application may not directly talk to
+ the network, in which case the DTLS stack may absorb ICMP
+ [RFC1191] "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 2012
+
+
+ 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; 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
+
+ Like TLS, DTLS transmits data as a series of protected records. The
+ rest of this section describes the details of that format.
+
+4.1.2.1. MAC
+
+ The DTLS MAC is the same as that of TLS 1.2. However, rather than
+ using TLS's implicit sequence number, the sequence number used to
+ compute the MAC is the 64-bit value formed by concatenating the epoch
+ and the sequence number in the order they appear on the wire. Note
+ that the DTLS epoch + sequence number is the same length as the TLS
+ sequence number.
+
+ TLS MAC calculation is parameterized on the protocol version number,
+ which, in the case of DTLS, is the on-the-wire version, i.e., {254,
+ 253} for DTLS 1.2.
+
+ Note that one important difference between DTLS and TLS MAC handling
+ is that in TLS, MAC errors must result in connection termination. In
+ DTLS, the receiving implementation MAY simply discard the offending
+ record and continue with the connection. This change is possible
+ because DTLS records are not dependent on each other in the way that
+ TLS records are.
+
+ In general, DTLS implementations SHOULD silently discard records with
+ bad MACs or that are otherwise invalid. They MAY log an error. If a
+ DTLS implementation chooses to generate an alert when it receives a
+ message with an invalid MAC, it MUST generate a bad_record_mac alert
+
+
+
+Rescorla & Modadugu Standards Track [Page 12]
+
+RFC 6347 DTLS January 2012
+
+
+ with level fatal and terminate its connection state. Note that
+ because errors do not cause connection termination, DTLS stacks are
+ more efficient error type oracles than TLS stacks. Thus, it is
+ especially important that the advice in Section 6.2.3.2 of [TLS12] be
+ followed.
+
+4.1.2.2. Null or Standard Stream Cipher
+
+ The DTLS NULL cipher is performed exactly as the TLS 1.2 NULL cipher.
+
+ The only stream cipher described in TLS 1.2 is RC4, which cannot be
+ randomly accessed. RC4 MUST NOT be used with DTLS.
+
+4.1.2.3. Block Cipher
+
+ DTLS block cipher encryption and decryption are performed exactly as
+ with TLS 1.2.
+
+4.1.2.4. 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
+ are suitable for DTLS usage and what, if any, adaptations must be
+ made (see Section 7 for IANA considerations).
+
+4.1.2.6. Anti-Replay
+
+ DTLS records contain a sequence number to provide replay protection.
+ Sequence number verification SHOULD be performed using the following
+ sliding window procedure, borrowed from Section 3.4.3 of [ESP].
+
+ 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 2012
+
+
+ window size of 64 is preferred and SHOULD be employed as the default.
+ Another window size (larger than the minimum) MAY be chosen by the
+ receiver. (The receiver does not notify the sender of the window
+ size.)
+
+ The "right" edge of the window represents the highest validated
+ sequence number value received on this session. Records that contain
+ sequence numbers lower than the "left" edge of the window are
+ rejected. Packets falling within the window are checked against a
+ list of received packets within the window. An efficient means for
+ performing this check, based on the use of a bit mask, is described
+ in Section 3.4.3 of [ESP].
+
+ 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 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;
+ however, an error MAY be logged for diagnostic purposes.
+ 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
+ denial-of-service (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 that 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 that will
+ not be rejected by the transport layer.
+
+4.2. The DTLS Handshake Protocol
+
+ DTLS uses all of the same handshake messages and flows as TLS, with
+ three principal changes:
+
+ 1. A stateless cookie exchange has been added to prevent denial-
+ of-service attacks.
+
+
+
+
+
+
+Rescorla & Modadugu Standards Track [Page 14]
+
+RFC 6347 DTLS January 2012
+
+
+ 2. Modifications to the handshake header to handle message loss,
+ reordering, and DTLS message fragmentation (in order to avoid
+ IP fragmentation).
+
+ 3. Retransmission timers to handle message loss.
+
+ With these exceptions, the DTLS message formats, flows, and logic are
+ the same as those of TLS 1.2.
+
+4.2.1. Denial-of-Service Countermeasures
+
+ Datagram security protocols are extremely susceptible to a variety of
+ DoS attacks. Two attacks are of particular concern:
+
+ 1. An attacker can consume excessive resources on the server by
+ transmitting a series of handshake initiation requests, causing
+ the server to allocate state and potentially to perform
+ expensive cryptographic operations.
+
+ 2. An attacker can use the server as an amplifier by sending
+ connection initiation messages with a forged source of the
+ victim. The server then sends its next message (in DTLS, a
+ Certificate message, which can be quite large) to the victim
+ machine, thus flooding it.
+
+ In order to counter both of these attacks, DTLS borrows the stateless
+ cookie technique used by Photuris [PHOTURIS] and IKE [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
+
+
+ The exchange is shown below:
+
+ Client Server
+ ------ ------
+ ClientHello ------>
+
+ <----- HelloVerifyRequest
+ (contains cookie)
+
+ ClientHello ------>
+ (with cookie)
+
+ [Rest of handshake]
+
+ DTLS therefore modifies the ClientHello message to add the cookie
+ value.
+
+ struct {
+ ProtocolVersion client_version;
+ Random random;
+ SessionID session_id;
+ opaque cookie<0..2^8-1>; // New field
+ CipherSuite cipher_suites<2..2^16-1>;
+ CompressionMethod compression_methods<1..2^8-1>;
+ } ClientHello;
+
+ When sending the first ClientHello, the client does not have a cookie
+ yet; in this case, the Cookie field is left empty (zero length).
+
+ The definition of HelloVerifyRequest is as follows:
+
+ struct {
+ ProtocolVersion server_version;
+ opaque cookie<0..2^8-1>;
+ } HelloVerifyRequest;
+
+ The HelloVerifyRequest message type is hello_verify_request(3).
+
+ The server_version field has the same syntax as in TLS. However, in
+ order to avoid the requirement to do version negotiation in the
+ initial handshake, DTLS 1.2 server implementations SHOULD use DTLS
+ version 1.0 regardless of the version of TLS that is expected to be
+ negotiated. DTLS 1.2 and 1.0 clients MUST use the version solely to
+ indicate packet formatting (which is the same in both DTLS 1.2 and
+ 1.0) and not as part of version negotiation. In particular, DTLS 1.2
+ clients MUST NOT assume that because the server uses version 1.0 in
+ the HelloVerifyRequest that the server is not DTLS 1.2 or that it
+ will eventually negotiate DTLS 1.0 rather than DTLS 1.2.
+
+
+
+Rescorla & Modadugu Standards Track [Page 16]
+
+RFC 6347 DTLS January 2012
+
+
+ When responding to a HelloVerifyRequest, the client MUST use the same
+ parameter values (version, random, session_id, cipher_suites,
+ compression_method) as it did in the original ClientHello. The
+ server SHOULD use those values to generate its cookie and verify that
+ they are correct upon cookie receipt. The server MUST use the same
+ version number in the HelloVerifyRequest that it would use when
+ sending a ServerHello. Upon receipt of the ServerHello, the client
+ MUST verify that the server version values match. In order to avoid
+ sequence number duplication in case of multiple HelloVerifyRequests,
+ the server MUST use the record sequence number in the ClientHello as
+ the record sequence number in the HelloVerifyRequest.
+
+ 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
+ be verified without retaining any per-client state on the server.
+ One technique is to have a randomly generated secret and generate
+ cookies as:
+
+ Cookie = HMAC(Secret, Client-IP, Client-Parameters)
+
+ When the second ClientHello is received, the server can verify that
+ the Cookie is valid and that the client can receive packets at the
+ given IP address. In order to avoid sequence number duplication in
+ case of multiple cookie exchanges, the server MUST use the record
+ sequence number in the ClientHello as the record sequence number in
+ its initial ServerHello. Subsequent ServerHellos will only be sent
+ after the server has created state and MUST increment normally.
+
+ One potential attack on this scheme is for the attacker to collect a
+ number of cookies from different addresses and then reuse them to
+ attack the server. The server can defend against this attack by
+ changing the Secret value frequently, thus invalidating those
+ cookies. If the server wishes that legitimate clients be able to
+ handshake through the transition (e.g., they received a cookie with
+ Secret 1 and then sent the second ClientHello after the server has
+ changed to Secret 2), the server can have a limited window during
+ which it accepts both secrets. [IKEv2] suggests adding a version
+ number to cookies to detect this case. An alternative approach is
+ simply to try verifying with both secrets.
+
+ 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 2012
+
+
+ choose not to do a cookie exchange when a session is resumed.
+ Clients MUST be prepared to do a cookie exchange with every
+ handshake.
+
+ If HelloVerifyRequest is used, the initial ClientHello and
+ HelloVerifyRequest are not included in the calculation of the
+ 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 result 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
+
+ In order to support message loss, reordering, and message
+ fragmentation, DTLS modifies the TLS 1.2 handshake header:
+
+ struct {
+ HandshakeType msg_type;
+ uint24 length;
+ uint16 message_seq; // New field
+ uint24 fragment_offset; // New field
+ uint24 fragment_length; // New field
+ select (HandshakeType) {
+ case hello_request: HelloRequest;
+ case client_hello: ClientHello;
+ case hello_verify_request: HelloVerifyRequest; // New type
+ case server_hello: ServerHello;
+ case certificate:Certificate;
+ case server_key_exchange: ServerKeyExchange;
+ case certificate_request: CertificateRequest;
+ case server_hello_done:ServerHelloDone;
+ case certificate_verify: CertificateVerify;
+ case client_key_exchange: ClientKeyExchange;
+ case finished: Finished;
+ } body;
+ } Handshake;
+
+ The first message each side transmits in each handshake always has
+ message_seq = 0. Whenever each new message is generated, the
+ message_seq value is incremented by one. Note that in the case of a
+
+
+
+Rescorla & Modadugu Standards Track [Page 18]
+
+RFC 6347 DTLS January 2012
+
+
+ rehandshake, this implies that the HelloRequest will have message_seq
+ = 0 and the ServerHello will have message_seq = 1. When a message is
+ retransmitted, the same message_seq value is used. For example:
+
+ Client Server
+ ------ ------
+ ClientHello (seq=0) ------>
+
+ X<-- HelloVerifyRequest (seq=0)
+ (lost)
+
+ [Timer Expires]
+
+ ClientHello (seq=0) ------>
+ (retransmit)
+
+ <------ HelloVerifyRequest (seq=0)
+
+ ClientHello (seq=1) ------>
+ (with cookie)
+
+ <------ ServerHello (seq=1)
+ <------ Certificate (seq=2)
+ <------ ServerHelloDone (seq=3)
+
+ [Rest of handshake]
+
+ Note, however, that from the perspective of the DTLS record layer,
+ the retransmission is a new record. This record will have a new
+ DTLSPlaintext.sequence_number value.
+
+ DTLS implementations maintain (at least notionally) a
+ next_receive_seq counter. This counter is initially set to zero.
+ When a message is received, if its sequence number matches
+ next_receive_seq, next_receive_seq is incremented and the message is
+ processed. If the sequence number is less than next_receive_seq, the
+ message MUST be discarded. If the sequence number is greater than
+ next_receive_seq, the implementation SHOULD queue the message but MAY
+ discard it. (This is a simple space/bandwidth tradeoff).
+
+4.2.3. Handshake Message Fragmentation and Reassembly
+
+ As noted in Section 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 2012
+
+
+ When transmitting the handshake message, the sender divides the
+ message into a series of N contiguous data ranges. These ranges MUST
+ NOT be larger than the maximum handshake fragment size and MUST
+ jointly contain the entire handshake message. The ranges SHOULD NOT
+ overlap. The sender then creates N handshake messages, all with the
+ same message_seq value as the original handshake message. Each new
+ message is labeled with the fragment_offset (the number of bytes
+ contained in previous fragments) and the fragment_length (the length
+ of this fragment). The length field in all messages is the same as
+ the length field of the original message. An unfragmented message is
+ a degenerate case with fragment_offset=0 and fragment_length=length.
+
+ When a DTLS implementation receives a handshake message fragment, it
+ MUST buffer it until it has the entire handshake message. DTLS
+ implementations MUST be able to handle overlapping fragment ranges.
+ This allows senders to retransmit handshake messages with smaller
+ fragment sizes if the PMTU estimate changes.
+
+ 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
+ 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
+ separate records.
+
+4.2.4. Timeout and Retransmission
+
+ DTLS messages are grouped into a series of message flights, according
+ to the diagrams below. Although each flight of messages may consist
+ of a number of messages, they should be viewed as monolithic for the
+ purpose of timeout and retransmission.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rescorla & Modadugu Standards Track [Page 20]
+
+RFC 6347 DTLS January 2012
+
+
+ Client Server
+ ------ ------
+
+ ClientHello --------> Flight 1
+
+ <------- HelloVerifyRequest Flight 2
+
+ ClientHello --------> Flight 3
+
+ ServerHello \
+ Certificate* \
+ ServerKeyExchange* Flight 4
+ CertificateRequest* /
+ <-------- ServerHelloDone /
+
+ Certificate* \
+ ClientKeyExchange \
+ CertificateVerify* Flight 5
+ [ChangeCipherSpec] /
+ 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
+
+
+ +-----------+
+ | PREPARING |
+ +---> | | <--------------------+
+ | | | |
+ | +-----------+ |
+ | | |
+ | | Buffer next flight |
+ | | |
+ | \|/ |
+ | +-----------+ |
+ | | | |
+ | | SENDING |<------------------+ |
+ | | | | | Send
+ | +-----------+ | | HelloRequest
+ Receive | | | |
+ next | | Send flight | | or
+ flight | +--------+ | |
+ | | | Set retransmit timer | | Receive
+ | | \|/ | | HelloRequest
+ | | +-----------+ | | Send
+ | | | | | | ClientHello
+ +--)--| WAITING |-------------------+ |
+ | | | | Timer expires | |
+ | | +-----------+ | |
+ | | | | |
+ | | | | |
+ | | +------------------------+ |
+ | | Read retransmit |
+ Receive | | |
+ last | | |
+ flight | | |
+ | | |
+ \|/\|/ |
+ |
+ +-----------+ |
+ | | |
+ | FINISHED | -------------------------------+
+ | |
+ +-----------+
+ | /|\
+ | |
+ | |
+ +---+
+
+ Read retransmit
+ Retransmit last flight
+
+ Figure 3. DTLS Timeout and Retransmission State Machine
+
+
+
+Rescorla & Modadugu Standards Track [Page 22]
+
+RFC 6347 DTLS January 2012
+
+
+ The state machine has three basic states.
+
+ In the PREPARING state, the implementation does whatever computations
+ are necessary to prepare the next flight of messages. It then
+ buffers them up for transmission (emptying the buffer first) and
+ enters the SENDING state.
+
+ In the SENDING state, the implementation transmits the buffered
+ flight of messages. Once the messages have been sent, the
+ implementation then enters the FINISHED state if this is the last
+ flight in the handshake. Or, if the implementation expects to
+ receive more messages, it sets a retransmit timer and then enters the
+ WAITING state.
+
+ There are three ways to exit the WAITING state:
+
+ 1. The retransmit timer expires: the implementation transitions to
+ the SENDING state, where it retransmits the flight, resets the
+ retransmit timer, and returns to the WAITING state.
+
+ 2. The implementation reads a retransmitted flight from the peer: the
+ implementation transitions to the SENDING state, where it
+ retransmits the flight, resets the retransmit timer, and returns
+ 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
+ and therefore suggests that part of one's previous flight was
+ lost.
+
+ 3. The implementation receives the next flight of messages: if this
+ is the final flight of messages, the implementation transitions to
+ FINISHED. If the implementation needs to send a new flight, it
+ transitions to the PREPARING state. Partial reads (whether
+ partial messages or only some of the messages in the flight) do
+ not cause state transitions or timer resets.
+
+ Because DTLS clients send the first message (ClientHello), they start
+ in the PREPARING state. DTLS servers start in the WAITING state, but
+ with empty buffers and no retransmit timer.
+
+ When the server desires a rehandshake, it transitions from the
+ FINISHED state to the PREPARING state to transmit the HelloRequest.
+ When the client receives a HelloRequest, it transitions from FINISHED
+ to PREPARING to transmit the ClientHello.
+
+ In addition, for at least twice the default MSL defined for [TCP],
+ 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 2012
+
+
+ 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], 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 Values
+
+ Though timer values are the choice of the implementation, mishandling
+ 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
+ a congested link. Implementations SHOULD use an initial timer value
+ of 1 second (the minimum defined in RFC 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 2012
+
+
+4.2.5. ChangeCipherSpec
+
+ As with TLS, the ChangeCipherSpec message is not technically a
+ handshake message but MUST be treated as part of the same flight as
+ the associated Finished message for the purposes of timeout and
+ retransmission. This creates a potential ambiguity because the order
+ of the ChangeCipherSpec cannot be established unambiguously with
+ respect to the handshake messages in case of message loss.
+
+ This is not a problem with any current TLS mode because the expected
+ set of handshake messages logically preceeding the ChangeCipherSpec
+ is predictable from the rest of the handshake state. However, future
+ modes MUST take care to avoid creating ambiguity.
+
+4.2.6. CertificateVerify and Finished Messages
+
+ CertificateVerify and Finished messages have the same format as in
+ TLS. Hash calculations include entire handshake messages, including
+ DTLS-specific fields: message_seq, fragment_offset, and
+ fragment_length. However, in order to remove sensitivity to
+ handshake message fragmentation, the Finished MAC MUST be computed as
+ if each handshake 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
+
+ Note that Alert messages are not retransmitted at all, even when they
+ occur in the context of a handshake. However, a DTLS implementation
+ which would ordinarily issue an alert SHOULD generate a new alert
+ message if the offending record is received again (e.g., as a
+ retransmitted handshake message). Implementations SHOULD detect when
+ a peer is persistently sending bad messages and terminate the local
+ connection state after such misbehavior is detected.
+
+4.2.8. Establishing New Associations with Existing Parameters
+
+ If a DTLS client-server pair is configured in such a way that
+ repeated connections happen on the same host/port quartet, then it is
+ possible that a client will silently abandon one connection and then
+ initiate another with the same parameters (e.g., after a reboot).
+ This will appear to the server as a new handshake with epoch=0. In
+ cases where a server believes it has an existing association on a
+ given host/port quartet and it receives an epoch=0 ClientHello, it
+ SHOULD proceed with a new handshake but MUST NOT destroy the existing
+ association until the client has demonstrated reachability either by
+ completing a cookie exchange or by completing a complete handshake
+
+
+
+Rescorla & Modadugu Standards Track [Page 25]
+
+RFC 6347 DTLS January 2012
+
+
+ including delivering a verifiable Finished message. After a correct
+ Finished message is received, the server MUST abandon the previous
+ association to avoid confusion between two valid associations with
+ overlapping epochs. The reachability requirement prevents
+ off-path/blind attackers from destroying associations merely by
+ sending forged ClientHellos.
+
+4.3. Summary of New Syntax
+
+ This section includes specifications for the data structures that
+ have changed between TLS 1.2 and DTLS 1.2. See [TLS12] for the
+ definition of this syntax.
+
+4.3.1. Record Layer
+
+ struct {
+ ContentType type;
+ ProtocolVersion version;
+ uint16 epoch; // New field
+ uint48 sequence_number; // New field
+ uint16 length;
+ opaque fragment[DTLSPlaintext.length];
+ } DTLSPlaintext;
+
+ struct {
+ ContentType type;
+ ProtocolVersion version;
+ uint16 epoch; // New field
+ uint48 sequence_number; // New field
+ uint16 length;
+ opaque fragment[DTLSCompressed.length];
+ } DTLSCompressed;
+
+ struct {
+ ContentType type;
+ ProtocolVersion version;
+ uint16 epoch; // New field
+ uint48 sequence_number; // New field
+ uint16 length;
+ select (CipherSpec.cipher_type) {
+ case block: GenericBlockCipher;
+ case aead: GenericAEADCipher; // New field
+ } fragment;
+ } DTLSCiphertext;
+
+
+
+
+
+
+
+Rescorla & Modadugu Standards Track [Page 26]
+
+RFC 6347 DTLS January 2012
+
+
+4.3.2. Handshake Protocol
+
+ enum {
+ hello_request(0), client_hello(1), server_hello(2),
+ hello_verify_request(3), // New field
+ certificate(11), server_key_exchange (12),
+ certificate_request(13), server_hello_done(14),
+ certificate_verify(15), client_key_exchange(16),
+ finished(20), (255) } HandshakeType;
+
+ struct {
+ HandshakeType msg_type;
+ uint24 length;
+ uint16 message_seq; // New field
+ uint24 fragment_offset; // New field
+ uint24 fragment_length; // New field
+ select (HandshakeType) {
+ case hello_request: HelloRequest;
+ case client_hello: ClientHello;
+ case server_hello: ServerHello;
+ case hello_verify_request: HelloVerifyRequest; // New field
+ case certificate:Certificate;
+ case server_key_exchange: ServerKeyExchange;
+ case certificate_request: CertificateRequest;
+ case server_hello_done:ServerHelloDone;
+ case certificate_verify: CertificateVerify;
+ case client_key_exchange: ClientKeyExchange;
+ case finished: Finished;
+ } body; } Handshake;
+
+ struct {
+ ProtocolVersion client_version;
+ Random random;
+ SessionID session_id;
+ opaque cookie<0..2^8-1>; // New field
+ CipherSuite cipher_suites<2..2^16-1>;
+ CompressionMethod compression_methods<1..2^8-1>; } ClientHello;
+
+ struct {
+ ProtocolVersion server_version;
+ opaque cookie<0..2^8-1>; } HelloVerifyRequest;
+
+5. Security Considerations
+
+ This document describes a variant of TLS 1.2; therefore, most of the
+ security considerations are the same as those of TLS 1.2 [TLS12],
+ described in Appendices D, E, and F.
+
+
+
+
+Rescorla & Modadugu Standards Track [Page 27]
+
+RFC 6347 DTLS January 2012
+
+
+ The primary additional security consideration raised by DTLS is that
+ of denial of service. DTLS includes a cookie exchange designed to
+ protect against denial of service. However, implementations that do
+ not use this cookie exchange are still vulnerable to DoS. In
+ particular, DTLS servers that do not use the cookie exchange may be
+ used as attack amplifiers even if they themselves are not
+ experiencing DoS. Therefore, DTLS servers SHOULD use the cookie
+ exchange unless there is good reason to believe that amplification is
+ not a threat in their environment. Clients MUST be prepared to do a
+ cookie exchange with every handshake.
+
+ Unlike TLS implementations, DTLS implementations SHOULD NOT respond
+ to invalid records by terminating the connection. See Section
+ 4.1.2.7 for details on this.
+
+6. Acknowledgments
+
+ The authors would like to thank Dan Boneh, Eu-Jin Goh, Russ Housley,
+ Constantine Sapuntzakis, and Hovav Shacham for discussions and
+ comments on the design of DTLS. Thanks to the anonymous NDSS
+ reviewers of our original NDSS paper on DTLS [DTLS] 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 Considerations
+
+ This document uses the same identifier space as TLS [TLS12], 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]
+
+RFC 6347 DTLS January 2012
+
+
+ 0x00,0x18 TLS_DH_anon_WITH_RC4_128_MD5 [RFC5246]
+ 0x00,0x20 TLS_KRB5_WITH_RC4_128_SHA [RFC2712]
+ 0x00,0x24 TLS_KRB5_WITH_RC4_128_MD5 [RFC2712]
+ 0x00,0x28 TLS_KRB5_EXPORT_WITH_RC4_40_SHA [RFC2712]
+ 0x00,0x2B TLS_KRB5_EXPORT_WITH_RC4_40_MD5 [RFC2712]
+ 0x00,0x8A TLS_PSK_WITH_RC4_128_SHA [RFC4279]
+ 0x00,0x8E TLS_DHE_PSK_WITH_RC4_128_SHA [RFC4279]
+ 0x00,0x92 TLS_RSA_PSK_WITH_RC4_128_SHA [RFC4279]
+ 0xC0,0x02 TLS_ECDH_ECDSA_WITH_RC4_128_SHA [RFC4492]
+ 0xC0,0x07 TLS_ECDHE_ECDSA_WITH_RC4_128_SHA [RFC4492]
+ 0xC0,0x0C TLS_ECDH_RSA_WITH_RC4_128_SHA [RFC4492]
+ 0xC0,0x11 TLS_ECDHE_RSA_WITH_RC4_128_SHA [RFC4492]
+ 0xC0,0x16 TLS_ECDH_anon_WITH_RC4_128_SHA [RFC4492]
+ 0xC0,0x33 TLS_ECDHE_PSK_WITH_RC4_128_SHA [RFC5489]
+
+ From the TLS Exporter Label Registry:
+
+ client EAP encryption [RFC5216]
+ ttls keying material [RFC5281]
+ ttls challenge [RFC5281]
+
+ This document defines a new handshake message, hello_verify_request,
+ whose value has been allocated from the TLS HandshakeType registry
+ defined in [TLS12]. The value "3" has been assigned by the IANA.
+
+8. Changes since DTLS 1.0
+
+ This document reflects the following changes since DTLS 1.0 [DTLS1].
+
+ - Updated to match TLS 1.2 [TLS12].
+
+ - Addition of AEAD Ciphers in Section 4.1.2.3 (tracking changes in
+ TLS 1.2.
+
+ - Clarifications regarding sequence numbers and epochs in Section
+ 4.1 and a clear procedure for dealing with state loss in Section
+ 4.2.8.
+
+ - Clarifications and more detailed rules regarding Path MTU issues
+ in Section 4.1.1.1. Clarification of the fragmentation text
+ throughout.
+
+ - Clarifications regarding handling of invalid records in Section
+ 4.1.2.7.
+
+ - A new paragraph describing handling of invalid cookies at the end
+ of Section 4.2.1.
+
+
+
+
+Rescorla & Modadugu Standards Track [Page 29]
+
+RFC 6347 DTLS January 2012
+
+
+ - Some new text describing how to avoid handshake deadlock
+ conditions at the end of Section 4.2.4.
+
+ - Some new text about CertificateVerify messages in Section 4.2.6.
+
+ - A prohibition on epoch wrapping in Section 4.1.
+
+ - Clarification of the IANA requirements and the explicit
+ requirement for a new IANA registration flag for each parameter.
+
+ - Added a record sequence number mirroring technique for handling
+ repeated ClientHello messages.
+
+ - Recommend a fixed version number for HelloVerifyRequest.
+
+ - Numerous editorial changes.
+
+9. References
+
+9.1. Normative References
+
+ [REQ] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
+ November 1990.
+
+ [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
+ Internet Protocol", RFC 4301, December 2005.
+
+ [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
+ Control Message Protocol (ICMPv6) for the Internet
+ Protocol Version 6 (IPv6) Specification", RFC 4443, March
+ 2006.
+
+ [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
+ Discovery", RFC 4821, March 2007.
+
+ [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
+ "Computing TCP's Retransmission Timer", RFC 6298, June
+ 2011.
+
+ [RSAGCM] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
+ Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
+ August 2008.
+
+ [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, September 1981.
+
+
+
+Rescorla & Modadugu Standards Track [Page 30]
+
+RFC 6347 DTLS January 2012
+
+
+ [TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+9.2. Informative References
+
+ [DCCP] Kohler, E., Handley, M., and S. Floyd, "Datagram
+ Congestion Control Protocol (DCCP)", RFC 4340, March
+ 2006.
+
+ [DCCPDTLS] Phelan, T., "Datagram Transport Layer Security (DTLS)
+ over the Datagram Congestion Control Protocol (DCCP)",
+ RFC 5238, May 2008.
+
+ [DTLS] Modadugu, N. and E. Rescorla, "The Design and
+ Implementation of Datagram TLS", Proceedings of ISOC NDSS
+ 2004, February 2004.
+
+ [DTLS1] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+ Security", RFC 4347, April 2006.
+
+ [ECCGCM] Rescorla, E., "TLS Elliptic Curve Cipher Suites with
+ SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289,
+ August 2008.
+
+ [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
+ 4303, December 2005.
+
+ [IANA] IANA, "Transport Layer Security (TLS) Parameters",
+ http://www.iana.org/assignments/tls-parameters.
+
+ [IKEv2] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
+ "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
+ 5996, September 2010.
+
+ [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
+ 4rev1", RFC 3501, March 2003.
+
+ [PHOTURIS] Karn, P. and W. Simpson, "Photuris: Session-Key
+ Management Protocol", RFC 2522, March 1999.
+
+ [POP] Myers, J. and M. Rose, "Post Office Protocol - Version
+ 3", STD 53, RFC 1939, May 1996.
+
+ [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+ A., Peterson, J., Sparks, R., Handley, M., and E.
+ Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+ June 2002.
+
+
+
+
+Rescorla & Modadugu Standards Track [Page 31]
+
+RFC 6347 DTLS January 2012
+
+
+ [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+ 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 Specifying the Use of IPsec
+ Version 2", BCP 146, RFC 5406, February 2009.
+
+Authors' Addresses
+
+ Eric Rescorla
+ RTFM, Inc.
+ 2064 Edgewood Drive
+ Palo Alto, CA 94303
+
+ EMail: ekr@rtfm.com
+
+
+ Nagendra Modadugu
+ Google, Inc.
+
+ EMail: nagendra@cs.stanford.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rescorla & Modadugu Standards Track [Page 32]
+