doc: Add RFC documents

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