<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> version="1.0" encoding="UTF-8"?>

<!-- [CS] updated by Chris 05/11/21 -->

<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.3 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc rfcedstyle="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc text-list-symbols="-o*+"?>
<?rfc docmapping="yes"?> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="pre5378Trust200902" docName="draft-ietf-tls-dtls13-43" category="std" number="9147" obsoletes="6347" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true"
sortRefs="true" symRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.5.0 -->
  <front>
    <title abbrev="DTLS 1.3">The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-tls-dtls13-43"/> name="RFC" value="9147"/>
    <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
      <organization>RTFM, Inc.</organization>
      <organization>Mozilla</organization>
      <address>
        <email>ekr@rtfm.com</email>
      </address>
    </author>
    <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
      <organization>Arm Limited</organization>
      <address>
        <email>hannes.tschofenig@arm.com</email>
      </address>
    </author>
    <author initials="N." surname="Modadugu" fullname="Nagendra Modadugu">
      <organization>Google, Inc.</organization>
      <address>
        <email>nagendra@cs.stanford.edu</email>
      </address>
    </author>
    <date year="2021" month="April" day="30"/> year="2022" month="March"/>
    <area>Security</area>
    <workgroup>TLS</workgroup>
    <keyword>Internet-Draft</keyword>

<keyword>Communication Security</keyword>

    <abstract>
      <t>This document specifies Version version 1.3 of the Datagram Transport Layer Security
(DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the
Internet in a way that is designed to prevent eavesdropping, tampering, and message
forgery.</t>
      <t>The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS)
1.3 protocol and provides equivalent security guarantees with the exception of order protection/non-replayability. protection / non-replayability.  Datagram semantics of the underlying transport are preserved by the DTLS protocol.</t>
      <t>This document obsoletes RFC 6347.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH</t>
      <t>The source for this draft is maintained in GitHub. Suggested changes
should be submitted as pull requests at https://github.com/tlswg/dtls13-spec.
Instructions are on that page as well. Editorial changes can be managed in GitHub,
but any substantive change should be discussed on the TLS mailing list.</t>
      <t>The primary goal of the TLS protocol is to establish an authenticated,
confidentiality
confidentiality- and integrity protected integrity-protected channel between two communicating peers.
The TLS protocol is composed of two layers:
the TLS Record Protocol record protocol and the TLS Handshake Protocol. handshake protocol. However, TLS must
run over a reliable transport channel - -- typically TCP <xref target="RFC0793" format="default"/>.</t>
<t>There are applications that use UDP <xref target="RFC0768" format="default"/> as a transport
and to offer communication
security protection for those applications the Datagram Transport Layer
Security (DTLS) protocol has been developed. developed to offer communication security protection
for those applications. 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.</t>
      <t>DTLS 1.0 <xref target="RFC4347" format="default"/> was originally defined as a delta from TLS 1.1 <xref target="RFC4346" format="default"/> format="default"/>, and
DTLS 1.2 <xref target="RFC6347" format="default"/> was defined as a series of deltas to TLS 1.2 <xref target="RFC5246" format="default"/>.  There
is no DTLS 1.1; that version number was skipped in order to harmonize version numbers
with TLS.  This specification describes the most current version of the DTLS protocol
as a delta from TLS 1.3 <xref target="TLS13" target="RFC8446" format="default"/>. It obsoletes DTLS 1.2.</t>
      <t>Implementations that speak both DTLS 1.2 and DTLS 1.3 can interoperate with those
that speak only DTLS 1.2 (using DTLS 1.2 of course), just as TLS 1.3 implementations
can interoperate with TLS 1.2 (see Appendix D of <xref target="TLS13" format="default"/> target="RFC8446" sectionFormat="of" section="D"/> for details).
While backwards compatibility with DTLS 1.0 is possible possible, the use of DTLS 1.0 is not
recommended
recommended, as explained in Section 3.1.2 of RFC 7525 <xref target="RFC7525" format="default"/> and sectionFormat="of" section="3.1.2"/>. <xref target="DEPRECATE" format="default"/>.</t> target="RFC8996"/> forbids the use of DTLS 1.0.
</t>
    </section>
    <section anchor="conventions-and-terminology" numbered="true" toc="default">
      <name>Conventions and Terminology</name>
       <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
       "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
       "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
       "<bcp14>SHOULD NOT</bcp14>",
       "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
       "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document
       are to be interpreted as described in BCP 14 BCP&nbsp;14
       <xref target="RFC2119" format="default"/> target="RFC2119"/> <xref target="RFC8174" format="default"/> target="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.</t>
      <t>The following terms are used:</t>
      <ul
      <dl spacing="normal">
        <li>client: The
        <dt>client:</dt><dd>The endpoint initiating the DTLS connection.</li>
        <li>association: Shared connection.</dd>
        <dt>association:</dt><dd>Shared state between two endpoints established with
a DTLS handshake.</li>
        <li>connection: Synonym handshake.</dd>
        <dt>connection:</dt><dd>Synonym for association.</li>
        <li>endpoint: Either association.</dd>
        <dt>endpoint:</dt><dd>Either the client or server of the connection.</li>
        <li>epoch: one connection.</dd>
        <dt>epoch:</dt><dd>One set of cryptographic keys used for encryption and decryption.</li>
        <li>handshake: An decryption.</dd>
        <dt>handshake:</dt><dd>An initial negotiation between client and server that establishes
the parameters of the connection.</li>
        <li>peer: An connection.</dd>
        <dt>peer:</dt><dd>An endpoint. When discussing a particular endpoint, "peer" refers to
the endpoint that is remote to the primary subject of discussion.</li>
        <li>receiver: An discussion.</dd>
        <dt>receiver:</dt><dd>An endpoint that is receiving records.</li>
        <li>sender: An records.</dd>
        <dt>sender:</dt><dd>An endpoint that is transmitting records.</li>
        <li>server: The records.</dd>
        <dt>server:</dt><dd>The endpoint which that did not initiate the DTLS connection.</li>
        <li>CID: Connection ID</li>
        <li>MSL: Maximum connection.</dd>
        <dt>CID:</dt><dd>Connection ID.</dd>
        <dt>MSL:</dt><dd>Maximum Segment Lifetime</li>
      </ul> Lifetime.</dd>
      </dl>
      <t>The reader is assumed to be familiar with <xref target="TLS13" target="RFC8446" format="default"/>.
As in TLS 1.3, the HelloRetryRequest has the same format as a ServerHello
message, but for convenience we use the term HelloRetryRequest throughout
this document as if it were a distinct message.</t>
      <t>DTLS 1.3 uses network byte order (big-endian) format for encoding messages
based on the encoding format defined in <xref target="TLS13" target="RFC8446" format="default"/> and earlier (D)TLS specifications.</t>
      <t>The reader is also assumed to be familiar with <xref target="I-D.ietf-tls-dtls-connection-id" format="default"/> target="RFC9146" format="default"/>,
as this document applies the CID functionality to DTLS 1.3.</t>
      <t>Figures in this document illustrate various combinations of the DTLS protocol exchanges exchanges, and the symbols have the following meaning:</t>
      <ul spacing="normal">
        <li>'+'  indicates
      <dl spacing="normal" indent="6">
        <dt>'+'</dt><dd>indicates noteworthy extensions sent in the previously noted message.</li>
        <li>'*'  indicates message.</dd>
        <dt>'*'</dt><dd>indicates optional or situation-dependent messages/extensions that are not always sent.</li>
        <li>'{}' indicates sent.</dd>
        <dt>'{}'</dt><dd>indicates messages protected using keys derived from a [sender]_handshake_traffic_secret.</li>
        <li>'[]' indicates [sender]_handshake_traffic_secret.</dd>
        <dt>'[]'</dt><dd>indicates messages protected using keys derived from traffic_secret_N.</li>
      </ul> traffic_secret_N.</dd>
      </dl>
    </section>
    <section anchor="dtls-rational" numbered="true" toc="default">
      <name>DTLS Design Rationale and Overview</name>
      <t>The basic design philosophy of DTLS is to construct "TLS over datagram transport".
Datagram transport does not require neither requires nor provide provides reliable or in-order delivery of data.
The DTLS protocol preserves this property for application data.
Applications,
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 reordered data traffic. Note that while
low-latency streaming and gaming use DTLS to protect data (e.g. (e.g., for
protection of a WebRTC data channel), telephony utilizes DTLS for
key establishment, establishment and the Secure Real-time Transport Protocol (SRTP) for
protection of data <xref target="RFC5763" format="default"/>.</t>
      <t>TLS cannot be used directly over datagram transports for the following five four reasons:</t>
      <ol spacing="normal" type="1"><li>TLS relies on an implicit sequence number on records.  If a record is not
received, then the recipient will use the wrong sequence number when
attempting to remove record protection from subsequent records. DTLS solves
this problem by adding sequence numbers to records.</li>
        <li>The TLS handshake is a lock-step cryptographic protocol.  Messages
must be transmitted and received in a defined order; any other
order is an error.  The DTLS handshake includes message sequence
numbers to enable fragmented message reassembly and in-order
delivery in case datagrams are lost or reordered.</li>
        <li>During the handshake, messages are implicitly acknowledged by other handshake
messages. Some handshake messages, such as the NewSessionTicket message, do
not result in any direct response that would allow the sender to detect loss.
DTLS adds an acknowledgment message to enable better loss recovery.</li>
        <li>Handshake messages are potentially larger than can be contained in a single
datagram.  DTLS adds fields to handshake messages to support fragmentation
and reassembly.</li>
        <li>Datagram transport protocols, like UDP, protocols are susceptible to abusive behavior
effecting denial of service denial-of-service (DoS) attacks against nonparticipants.  DTLS adds a
return-routability check and DTLS 1.3 uses the TLS 1.3 HelloRetryRequest message
(see <xref target="dos" format="default"/> for details).</li>
      </ol>
      <section anchor="packet-loss" numbered="true" toc="default">
        <name>Packet Loss</name>
        <t>DTLS uses a simple retransmission timer to handle packet loss.
<xref target="dtls-retransmission" format="default"/> demonstrates the basic concept, using the first
phase of the DTLS handshake:</t>
        <figure anchor="dtls-retransmission">
          <name>DTLS retransmission example</name> Retransmission Example</name>
          <artwork name="" type="" type="ascii-art" align="left" alt=""><![CDATA[
         Client                                   Server
         ------                                   ------
         ClientHello           ------>

                                 X<-- HelloRetryRequest
                                                  (lost)

         [Timer Expires]

         ClientHello           ------>
         (retransmit)
]]></artwork>
        </figure>
        <t>Once the client has transmitted the ClientHello message, it expects
to see a HelloRetryRequest or a ServerHello from the server. However, if the
timer expires, the client knows that either the
ClientHello or the response from the server has been lost, which
causes the the client
to retransmit the ClientHello. When the server receives the retransmission,
it knows to retransmit its HelloRetryRequest or ServerHello.</t>
        <t>The server also maintains a retransmission timer for messages it
sends (other than HelloRetryRequest) and retransmits when that timer expires. Not
applying retransmissions to the HelloRetryRequest avoids the need to
create state on the server.  The HelloRetryRequest is designed to be
small enough that it will not itself be fragmented, thus avoiding
concerns about interleaving multiple HelloRetryRequests.</t>
        <t>For more detail on timeouts and retransmission,
see <xref target="timeout-retransmissions" format="default"/>.</t>
      </section>
      <section anchor="reordering" numbered="true" toc="default">
        <name>Reordering</name>
        <t>In DTLS, each handshake message is assigned a specific sequence
number.  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.</t>
      </section>
      <section anchor="fragmentation" numbered="true" toc="default">
        <name>Fragmentation</name>
        <t>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 less than 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 UDP datagram
(see <xref target="pmtu-issues" format="default"/> for guidance). 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.</t>
      </section>
      <section anchor="replay-detection" numbered="true" toc="default">
        <name>Replay Detection</name>
        <t>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, malicious but can also occur due to routing errors.
Applications may conceivably detect duplicate packets and accordingly
modify their data transmission strategy.</t>
      </section>
    </section>
    <section anchor="the-dtls-record-layer" numbered="true" toc="default">
      <name>The DTLS Record Layer</name>
      <t>The DTLS 1.3 record layer is different from the TLS 1.3 record layer and
also different from the DTLS 1.2 record layer.</t>
      <ol spacing="normal" type="1"><li>The DTLSCiphertext structure omits the superfluous version number and
type fields.</li>
        <li>DTLS adds an epoch and sequence number to the TLS record header.
This sequence number allows the recipient to correctly decrypt and verify the DTLS MAC. records.
However, the number of bits used for the epoch and sequence number fields in
the DTLSCiphertext structure have has been reduced from those in previous
        versions.</li>
        <li>
The DTLS epoch serialized in DTLSPlaintext is 2 octets long for compatibility
   with DTLS 1.2. However, this value is set as the least significant 2 octets
   of the connection epoch, which is an 8 octet counter incremented on every
   KeyUpdate. See <xref target="sequence-number-and-epoch"/> for details. The sequence number is set to
   be the low order 48 bits of the 64 bit sequence number. Plaintext records
   <bcp14>MUST NOT</bcp14> be sent with sequence numbers that would exceed 2^48-1, so the
   upper 16 bits will always be 0.
        </li>
        <li>The DTLSCiphertext structure has a variable length variable-length header.</li>
      </ol>
      <t>DTLSPlaintext records are used to send unprotected records and DTLSCiphertext
records are used to send protected records.</t>
      <t>The DTLS record formats are shown below. Unless explicitly stated the
meaning of the fields is unchanged from previous TLS / DTLS TLS/DTLS versions.</t>

<!-- [rfced] 8/31/2021  [Hannes] I will do this in a second pass.

Sections 4 and subsequent:  In the XML file, please
review the instances of sourcecode with type set to
"tls-presentation", and let us know if changes are needed. -->

      <figure anchor="dtls-record">
        <name>DTLS 1.3 Record Formats</name>
        <artwork
<sourcecode name="" type="" align="left" alt=""><![CDATA[ type="tls-presentation"><![CDATA[
    struct {
        ContentType type;
        ProtocolVersion legacy_record_version;
        uint16 epoch = 0
        uint48 sequence_number;
        uint16 length;
        opaque fragment[DTLSPlaintext.length];
    } DTLSPlaintext;

    struct {
         opaque content[DTLSPlaintext.length];
         ContentType type;
         uint8 zeros[length_of_padding];
    } DTLSInnerPlaintext;

    struct {
        opaque unified_hdr[variable];
        opaque encrypted_record[length];
    } DTLSCiphertext;
]]></artwork>
]]></sourcecode>

      </figure>
      <dl newline="false" spacing="normal">
        <dt>legacy_record_version</dt>
        <dt>legacy_record_version:</dt>
        <dd>
  This value MUST <bcp14>MUST</bcp14> be set to {254, 253} for all records other
than the initial ClientHello (i.e., one not generated after a HelloRetryRequest),
where it may also be {254, 255} for compatibility purposes.
        It MUST <bcp14>MUST</bcp14> be ignored for all purposes. See <xref target="TLS13" format="default"/>; Appendix D.1 target="RFC8446" sectionFormat="comma" section="D.1"/> for the rationale for this.</dd>
        <dt>epoch:</dt>
        <dd>The least significant 2 bytes of the connection epoch value.</dd>

<dt>unified_hdr:</dt>
<dd>
The unified header (unified_hdr) is a structure of variable length, as shown in <xref target="cid_hdr" format="default"/>.</dd>
        <dt>encrypted_record:</dt>
        <dd>
  The AEAD-encrypted encrypted form of the serialized DTLSInnerPlaintext structure.</dd>
      </dl>
      <figure anchor="cid_hdr">
        <name>DTLS 1.3 Unified Header</name>
        <artwork name="" type="" type="ascii-art" align="left" alt=""><![CDATA[
    0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |0|0|1|C|S|L|E E|
    +-+-+-+-+-+-+-+-+
    | Connection ID |   Legend:
    | (if any,      |
    /  length as    /   C   - Connection ID (CID) present
    |  negotiated)  |   S   - Sequence number length
    +-+-+-+-+-+-+-+-+   L   - Length present
    |  8 or 16 bit  |   E   - Epoch
    |Sequence Number|
    +-+-+-+-+-+-+-+-+
    | 16 bit Length |
    | (if present)  |
    +-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
      <dl newline="false" spacing="normal">
        <dt>Fixed Bits:</dt>
        <dd>
  The three high bits of the first byte of the unified header are set to
001. This ensures that the value will fit within the DTLS region when
multiplexing is performed as described in <xref target="RFC7983" format="default"/>. It also ensures
that distinguishing encrypted DTLS 1.3 records from encrypted DTLS 1.2
records is possible when they are carried on the same host/port quartet;
such multiplexing is only possible when CIDs <xref target="I-D.ietf-tls-dtls-connection-id" target="RFC9146" format="default"/>
are in use, in which case DTLS 1.2 records will have the content type tls12_cid (25).</dd>
        <dt>C:</dt>
        <dd>
  The C bit (0x10) is set if the Connection ID is present.</dd>
        <dt>S:</dt>
        <dd>
  The S bit (0x08) indicates the size of the sequence number.
0 means an 8-bit sequence number, 1 means 16-bit.
 Implementations MAY <bcp14>MAY</bcp14> mix sequence numbers of different lengths
 on the same connection.</dd>
        <dt>L:</dt>
        <dd>
  The L bit (0x04) is set if the length is present.</dd>
        <dt>E:</dt>
        <dd>
  The two low bits (0x03) include the low order low-order two bits of the epoch.</dd>
        <dt>Connection ID:</dt>
        <dd>
  Variable length
  Variable-length CID. The CID functionality
is described in <xref target="I-D.ietf-tls-dtls-connection-id" target="RFC9146" format="default"/>. An example
can be found in <xref target="connection-id-example" format="default"/>.</dd>
        <dt>Sequence Number:</dt>
        <dd>
  The low order low-order 8 or 16 bits of the record sequence number.  This value is 16
bits if the S bit is set to 1, and 8 bits if the S bit is 0.</dd>
        <dt>Length:</dt>
        <dd>
  Identical to the length field in a TLS 1.3 record.</dd>
      </dl>
      <t>As with previous versions of DTLS, multiple DTLSPlaintext
and DTLSCiphertext records can be included in the same
underlying transport datagram.</t>
      <t><xref target="hdr_examples" format="default"/> illustrates different record headers.</t>
      <figure anchor="hdr_examples">
        <name>DTLS 1.3 Header Examples</name>
        <artwork name="" type="" type="ascii-art" align="left" alt=""><![CDATA[
 0 1 2 3 4 5 6 7       0 1 2 3 4 5 6 7       0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
| Content Type  |     |0|0|1|1|1|1|E E|     |0|0|1|0|0|0|E E|
+-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
|   16 bit      |     |               |     |8-bit     |8 bit Seq. No. |
|   Version     |     / Connection ID /     +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+     |               |     |               |
|   16 bit      |     +-+-+-+-+-+-+-+-+     |   Encrypted   |
|    Epoch      |     |    16 bit     |     /   Record      /
+-+-+-+-+-+-+-+-+     |Sequence Number|     |               |
|               |     +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
|               |     |   16 bit      |
|   48 bit      |     |   Length      |       DTLSCiphertext
|Sequence Number|     +-+-+-+-+-+-+-+-+         Structure
|               |     |               |         (minimal)
|               |     |  Encrypted    |
+-+-+-+-+-+-+-+-+     /  Record       /
|    16 bit     |     |               |
|    Length     |     +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
|               |      DTLSCiphertext
|               |        Structure
/   Fragment    /          (full)
|               |
+-+-+-+-+-+-+-+-+

 DTLSPlaintext
   Structure
]]></artwork>
      </figure>
      <t>The length field MAY <bcp14>MAY</bcp14> be omitted by clearing the L bit, which means that the
record consumes the entire rest of the datagram in the lower
level transport. In this case case, it is not possible to have multiple
DTLSCiphertext format records without length fields in the same datagram.
Omitting the length field MUST <bcp14>MUST</bcp14> only be used for the last record in a
datagram. Implementations MAY <bcp14>MAY</bcp14> mix records with and without length
fields on the same connection.</t>
      <t>If a Connection ID is negotiated, then it MUST <bcp14>MUST</bcp14> be contained in all
datagrams. Sending implementations MUST NOT <bcp14>MUST NOT</bcp14> mix records from multiple DTLS associations
in the same datagram. If the second or later record has a connection
ID which does not correspond to the same association used
for previous records, the rest of the datagram MUST <bcp14>MUST</bcp14> be discarded.</t>
      <t>When expanded, the epoch and sequence number can be combined into an
unpacked RecordNumber structure, as shown below:</t>
      <artwork
<sourcecode name="" type="" align="left" alt=""><![CDATA[ type="tls-presentation"><![CDATA[
    struct {
        uint16
        uint64 epoch;
        uint48
        uint64 sequence_number;
    } RecordNumber;
]]></artwork>
]]></sourcecode>

      <t>This 64-bit 128-bit value is used in the ACK message as well as in the "record_sequence_number"
input to the AEAD function.</t>
      <t>The Authenticated Encryption with Associated Data (AEAD) function.
      The entire header value shown in <xref target="hdr_examples" format="default"/> (but prior to record number
encryption,
encryption; see <xref target="rne" format="default"/>) is used as as the additional data value for the AEAD
function. For instance, if the minimal variant is used,
the AAD Associated Data (AD) is 2 octets long. Note that this design is different from the additional data
calculation for DTLS 1.2 and for DTLS 1.2 with Connection ID.</t> IDs.
In DTLS 1.3 the 64-bit sequence_number is used as the sequence number for
the AEAD computation; unlike DTLS 1.2, the epoch is not included.
</t>
      <section anchor="demultiplexing-dtls-records" numbered="true" toc="default">
        <name>Demultiplexing DTLS Records</name>
        <t>DTLS 1.3 uses
        <t>
          DTLS 1.3's header format is more complicated to demux than
DTLS 1.2, which always carried the content type as the first
byte. As described in <xref target="demux" format="default"/>, the first byte determines how an incoming
DTLS record is demultiplexed. The first 3 bits of the first byte
distinguish a variable length DTLS 1.3 encrypted record format from record types used in
previous DTLS versions and hence plaintext DTLS 1.3 record types. Hence, the
demultiplexing process is more complex since more header formats
need
range 32 (0b0010 0000) to 63 (0b0011 1111) needs to be distinguished. excluded
from future allocations by IANA to avoid problems while demultiplexing;
see <xref target="iana-considerations" format="default"/>.
Implementations can demultiplex DTLS 1.3 records
by examining the first byte as follows:</t> follows:
</t>
        <ul spacing="normal">
          <li>If the first byte is alert(21), handshake(22), or ack(proposed, 26),
the record MUST <bcp14>MUST</bcp14> be interpreted as a DTLSPlaintext record.</li>
          <li>If the first byte is any other value, then receivers
MUST
<bcp14>MUST</bcp14> check to see if the leading bits of the first byte are
001. If so, the implementation MUST <bcp14>MUST</bcp14> process the record as
DTLSCiphertext; the true content type will be inside the
protected portion.</li>
          <li>Otherwise, the record MUST <bcp14>MUST</bcp14> be rejected as if it had failed
deprotection, as described in <xref target="handling-invalid-records" format="default"/>.</li>
        </ul>
        <t><xref target="demux" format="default"/> shows this demultiplexing procedure graphically graphically,
taking DTLS 1.3 and earlier versions of DTLS into account.</t>
        <figure anchor="demux">
          <name>Demultiplexing DTLS 1.2 and DTLS 1.3 Records</name>
          <artwork name="" type="" type="ascii-art" align="left" alt=""><![CDATA[
             +----------------+
             | Outer Content  |
             |   Type (OCT)   |
             |                |
             |   OCT == 20   -+--> ChangeCipherSpec (DTLS <1.3)
             |   OCT == 21   -+--> Alert (Plaintext)
             |   OCT == 22   -+--> Handshake DTLSHandshake (Plaintext)
             |   OCT == 23   -+--> Application Data (DTLS <1.3)
             |   OCT == 24   -+--> Heartbeat (DTLS <1.3)
packet  -->  |   OCT == 25   -+--> DTLSCipherText DTLSCiphertext with CID (DTLS 1.2)
             |   OCT == 26   -+--> ACK (DTLS 1.3, Plaintext)
             |                |
             |                |   /+----------------+\
             | 31 < OCT < 64 -+--> |DTLS Ciphertext |DTLSCiphertext  |
             |                |    |(header bits    |
             |      else      |    | start with 001)|
             |       |        |   /+-------+--------+\
             +-------+--------+            |
                     |                     |
                     v          Decryption |
               +---------+          +------+
               |  Reject |          |
               +---------+          v
                            +----------------+
                            | Decrypted      |
                            | Content Type   |
                            | (DCT)          |
                            |                |
                            |     DCT == 21 -+--> Alert
                            |     DCT == 22 -+--> Handshake DTLSHandshake
                            |     DCT == 23 -+--> Application Data
                            |     DCT == 24 -+--> Heartbeat
                            |     DCT == 26 -+--> ACK
                            |                |     else ------+--> Error
                            +----------------+
]]></artwork>
        </figure>
        <t>Note: The optimized DTLS header format shown in <xref target="cid_hdr" format="default"/>, which
does not carry the Content Type in the Unified Header format, requires
a different demultilexing strategy compared to what was used in previous
DTLS versions where the Content Type was conveyed in every record.
As described in <xref target="demux" format="default"/>, the first byte determines how an incoming
DTLS record is demultiplexed. The first 3 bits of the first byte
distinguish a DTLS 1.3 encrypted record from record types used in
previous DTLS versions and plaintext DTLS 1.3 record types. Hence, the
range 32 (0b0010 0000) to 63 (0b0011 1111) needs to be excluded
from future allocations by IANA to avoid problems while demultiplexing;
see <xref target="iana-considerations" format="default"/>.</t>
      </section>
      <section anchor="sequence-number-and-epoch" numbered="true" toc="default">
        <name>Sequence Number and Epoch</name>
        <t>DTLS uses an explicit or partly 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.</t>
        <t>The epoch number is initially zero and is incremented each time
keying material changes and a sender aims to rekey. More details
are provided in <xref target="dtls-epoch" format="default"/>.</t>
        <section anchor="processing-guidelines" numbered="true" toc="default">
          <name>Processing Guidelines</name>
          <t>Because DTLS records could be reordered, a record from epoch
M may be received after epoch N (where N &gt; M) has begun.
Implementations SHOULD <bcp14>SHOULD</bcp14> discard records from earlier epochs, epochs but
MAY
<bcp14>MAY</bcp14> choose to
retain keying material from previous epochs for up to the default MSL
specified for TCP <xref target="RFC0793" format="default"/> to allow for packet reordering.  (Note that
the intention here is that implementers use the current guidance from
the IETF for MSL, as specified in <xref target="RFC0793" format="default"/> or successors,
not that they attempt to interrogate the MSL that
the system TCP stack is using.)</t>
          <t>Conversely, it is possible for records that are protected with the
new epoch 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 <bcp14>MAY</bcp14> either buffer
or discard such records, though when DTLS is used over reliable
transports (e.g., SCTP <xref target="RFC4960" format="default"/>), they SHOULD <bcp14>SHOULD</bcp14> be buffered and
processed once the handshake completes.  Note that TLS's restrictions
on when records may be sent still apply, and the receiver treats the
records as if they were sent in the right order.</t>
          <t>Implementations MUST <bcp14>MUST</bcp14> send retransmissions of lost messages using the same
epoch and keying material as the original transmission.</t>
          <t>Implementations MUST <bcp14>MUST</bcp14> either abandon an association or re-key rekey prior to
allowing the sequence number to wrap.</t>
          <t>Implementations MUST NOT <bcp14>MUST NOT</bcp14> allow the epoch to wrap, but instead MUST <bcp14>MUST</bcp14>
establish a new association, terminating the old association.</t>
        </section>
        <section anchor="reconstructing" numbered="true" toc="default">
          <name>Reconstructing the Sequence Number and Epoch</name>
          <t>When receiving protected DTLS records, the recipient does not
have a full epoch or sequence number value in the record and so there is some
opportunity for ambiguity.  Because the full epoch and sequence number
are
is used to compute the per-record nonce, nonce and the epoch determines
the keys, failure to reconstruct these
values leads to failure to deprotect the record, and so implementations
MAY
<bcp14>MAY</bcp14> use a mechanism of their choice to determine the full values.
This section provides an algorithm which is comparatively simple
and which implementations are RECOMMENDED <bcp14>RECOMMENDED</bcp14> to follow.</t>
          <t>If the epoch bits match those of the current epoch, then
implementations SHOULD <bcp14>SHOULD</bcp14> reconstruct the sequence number by computing
the full sequence number which is numerically closest to one plus the
sequence number of the highest successfully deprotected record in the
current epoch.</t>
          <t>During the handshake phase, the epoch bits unambiguously indicate the
correct key to use. After the
handshake is complete, if the epoch bits do not match those from the
current epoch epoch, implementations SHOULD <bcp14>SHOULD</bcp14> use the most recent past epoch
which has matching bits, and then reconstruct the sequence number for
that epoch as described above.</t>
        </section>
        <section anchor="rne" numbered="true" toc="default">
          <name>Record Number Encryption</name>
          <t>In DTLS 1.3, when records are encrypted, record sequence numbers are
also encrypted. The basic pattern is that the underlying encryption
algorithm used with the AEAD algorithm is used to generate a mask
which is then XORed with the sequence number.</t>
          <t>When the AEAD is based on AES, then the Mask mask is generated by
computing AES-ECB on the first 16 bytes of the ciphertext:</t>
          <artwork name="" type="" type="ascii-art" align="left" alt=""><![CDATA[
  Mask = AES-ECB(sn_key, Ciphertext[0..15])
]]></artwork>
          <t>When the AEAD is based on ChaCha20, then the mask is generated
by treating the first 4 bytes of the ciphertext as the block
counter and the next 12 bytes as the nonce, passing them to the ChaCha20
block function (Section 2.3 of <xref target="CHACHA" format="default"/>):</t> (<xref target="RFC8439" sectionFormat="of" section="2.3"/>):</t>
          <artwork name="" type="" type="ascii-art" align="left" alt=""><![CDATA[
  Mask = ChaCha20(sn_key, Ciphertext[0..3], Ciphertext[4..15])
]]></artwork>
          <t>The sn_key is computed as follows:</t>
          <artwork name="" type="" type="ascii-art" align="left" alt=""><![CDATA[
  [sender]_sn_key = HKDF-Expand-Label(Secret, "sn" , "sn", "", key_length)
]]></artwork>

          <t>[sender] denotes the sending side. The per-epoch Secret value to be used is described
in Section 7.3 of <xref target="TLS13" format="default"/>. target="RFC8446" sectionFormat="of" section="7.3"/>. Note that a new key is used for each epoch: because the epoch is sent in the clear, this does not result in ambiguity.</t>
          <t>The encrypted sequence number is computed by XORing the leading
bytes of the Mask mask with the on-the-wire representation of the
sequence number. Decryption is accomplished by the same process.</t>
          <t>This procedure requires the ciphertext length to be at least 16 bytes. Receivers
MUST
<bcp14>MUST</bcp14> reject shorter records as if they had failed deprotection, as described in
<xref target="handling-invalid-records" format="default"/>. Senders MUST <bcp14>MUST</bcp14> pad short plaintexts out (using the
conventional record padding mechanism) in order to make a suitable-length
ciphertext. Note that most of the DTLS AEAD algorithms have a 16-byte 16 byte authentication
tag and need no padding. However, some algorithms algorithms, such as
TLS_AES_128_CCM_8_SHA256
TLS_AES_128_CCM_8_SHA256, have a shorter authentication tag and may require padding
for short inputs.</t>
          <t>Future cipher suites, which are not based on AES or ChaCha20, MUST <bcp14>MUST</bcp14> define
their own record sequence number encryption in order to be used with
DTLS.</t>
          <t>Note that sequence number encryption is only applied to the DTLSCiphertext
structure and not to the DTLSPlaintext structure, which even though it also contains a
sequence number.</t>
        </section>
      </section>
      <section anchor="transport-layer-mapping" numbered="true" toc="default">
        <name>Transport Layer Mapping</name>
        <t>DTLS messages MAY <bcp14>MAY</bcp14> be fragmented into multiple DTLS records.
Each DTLS record MUST <bcp14>MUST</bcp14> fit within a single datagram.  In order to
avoid IP fragmentation, clients of the DTLS record layer SHOULD <bcp14>SHOULD</bcp14>
attempt to size records so that they fit within any Path MTU (PMTU) estimates
obtained from the record layer. For more information about PMTU issues issues,
see <xref target="pmtu-issues" format="default"/>.</t>
        <t>Multiple DTLS records MAY <bcp14>MAY</bcp14> be placed in a single datagram.  Records are encoded
consecutively.  The length field from DTLS records containing that field can be
used to determine the boundaries between records.  The final record in a
datagram can omit the length field.  The first byte of the datagram payload MUST <bcp14>MUST</bcp14>
be the beginning of a record.  Records MUST NOT <bcp14>MUST NOT</bcp14> span datagrams.</t>
        <t>DTLS records without CIDs do not contain any association
identifiers
identifiers, and applications must arrange to multiplex between associations.
With UDP, the host/port number is used to look up the appropriate security
association for incoming records without CIDs.</t>
        <t>Some transports, such as DCCP <xref target="RFC4340" format="default"/>, 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.</t>
        <t>Some transports 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. <xref target="RFC5238" format="default"/>
defines a mapping of DTLS to DCCP that takes these issues into account.</t>
      </section>
      <section anchor="pmtu-issues" numbered="true" toc="default">
        <name>PMTU Issues</name>
        <t>In general, DTLS's philosophy is to leave PMTU discovery to the application.
However, DTLS cannot completely ignore the PMTU for three reasons:</t>
        <ul spacing="normal">
          <li>The DTLS record framing expands the datagram size, thus lowering
the effective PMTU from the application's perspective.</li>
          <li>In some implementations, the application may not directly talk to
the network, in which case the DTLS stack may absorb ICMP
<xref target="RFC1191" format="default"/>
"Datagram Too Big" indications or ICMPv6 <xref target="RFC4443" target="RFC1191" format="default"/> or ICMPv6
"Packet Too Big" indications.</li> indications <xref target="RFC4443" format="default"/>.</li>
          <li>The DTLS handshake messages can exceed the PMTU.</li>
        </ul>
        <t>In order to deal with the first two issues, the DTLS record layer
SHOULD
<bcp14>SHOULD</bcp14> behave as described below.</t>
        <t>If PMTU estimates are available from the underlying transport
protocol, they should be made available to upper layer
protocols. In particular:</t>
        <ul spacing="normal">
          <li>For DTLS over UDP, the upper layer protocol SHOULD <bcp14>SHOULD</bcp14> be allowed to
obtain the PMTU estimate maintained in the IP layer.</li>
          <li>For DTLS over DCCP, the upper layer protocol SHOULD <bcp14>SHOULD</bcp14> be allowed to
obtain the current estimate of the PMTU.</li>
          <li>For DTLS over TCP or SCTP, which automatically fragment and
reassemble datagrams, there is no PMTU limitation.  However, the
upper layer protocol MUST NOT <bcp14>MUST NOT</bcp14> write any record that exceeds the
maximum record size of 2^14 bytes.</li>
        </ul>
        <t>The DTLS record layer SHOULD <bcp14>SHOULD</bcp14> also allow the upper layer protocol to
discover the amount of record expansion expected by the DTLS
processing; alternately alternately, it MAY <bcp14>MAY</bcp14> report PMTU estimates minus the
estimated expansion from the transport layer and DTLS record
framing.</t>
        <t>Note that DTLS does not defend against spoofed ICMP messages;
implementations SHOULD <bcp14>SHOULD</bcp14> ignore any such messages that indicate
PMTUs below the IPv4 and IPv6 minimums of 576 and 1280 bytes bytes,
respectively.</t>
        <t>If there is a transport protocol indication that the PMTU was exceeded
(either via ICMP or via a
refusal to send the datagram as in Section 14 of <xref target="RFC4340" format="default"/>), sectionFormat="of" section="14"/>), then the
DTLS record layer MUST <bcp14>MUST</bcp14> inform the upper layer protocol of the error.</t>
        <t>The DTLS record layer SHOULD NOT <bcp14>SHOULD NOT</bcp14> interfere with upper layer protocols
performing PMTU discovery, whether via <xref target="RFC1191" format="default"/> and <xref target="RFC4821" format="default"/> for
IPv4 or via <xref target="RFC8201" format="default"/> for IPv6.  In particular:</t>
        <ul spacing="normal">
          <li>Where allowed by the underlying transport protocol, the upper
layer protocol SHOULD <bcp14>SHOULD</bcp14> be allowed to set the state of the DF Don't Fragment (DF) bit
(in IPv4) or prohibit local fragmentation (in IPv6).</li>
          <li>If the underlying transport protocol allows the application to
request PMTU probing (e.g., DCCP), the DTLS record layer SHOULD <bcp14>SHOULD</bcp14>
honor this request.</li>
        </ul>
        <t>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 <bcp14>SHOULD</bcp14> follow the following rules:</t>
        <ul spacing="normal">
          <li>If the DTLS record layer informs the DTLS handshake layer that a
message is too big, the handshake layer SHOULD <bcp14>SHOULD</bcp14> immediately attempt to fragment
the message, using any existing information about the PMTU.</li>
          <li>If repeated retransmissions do not result in a response, and the
PMTU is unknown, subsequent retransmissions SHOULD <bcp14>SHOULD</bcp14> back off to a
smaller record size, fragmenting the handshake message as
appropriate.  This specification does not specify an exact number of
retransmits to attempt before backing off, but 2-3 seems
appropriate.</li>
        </ul>
      </section>
      <section anchor="record-payload-protection" numbered="true" toc="default">
        <name>Record Payload Protection</name>
        <t>Like TLS, DTLS transmits data as a series of protected records.  The
rest of this section describes the details of that format.</t>
        <section anchor="anti-replay" numbered="true" toc="default">
          <name>Anti-Replay</name>
          <t>Each DTLS record contains a sequence number to provide replay protection.
Sequence number verification SHOULD <bcp14>SHOULD</bcp14> be performed using the following
sliding window procedure, borrowed from Section 3.4.3 of <xref target="RFC4303" format="default"/>. sectionFormat="of" section="3.4.3"/>.
Because each epoch resets the sequence number space, a separate sliding
window is needed for each epoch.</t>
          <t>The received record counter for an epoch MUST <bcp14>MUST</bcp14> be initialized to
zero when that epoch is first used. For each received record, the
receiver MUST <bcp14>MUST</bcp14> verify that the record contains a sequence number that
does not duplicate the sequence number of any other record received
in that epoch during the lifetime of the association.
This check SHOULD <bcp14>SHOULD</bcp14> happen after
deprotecting the record; otherwise otherwise, the record discard might itself
serve as a timing channel for the record number. Note that computing
the full record number from the partial is still a potential timing
channel for the record number, though a less powerful one than whether
the record was deprotected.</t>
          <t>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.) The receiver SHOULD <bcp14>SHOULD</bcp14> pick a window large enough to handle
any plausible reordering, which depends on the data rate.
(The receiver does not notify the sender of the window
size.)</t>
          <t>The "right" edge of the window represents the highest validated
sequence number value received in the epoch.  Records that contain
sequence numbers lower than the "left" edge of the window are
rejected.  Records falling within the window are checked against a
list of received records 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
<xref target="RFC4303" format="default"/>. sectionFormat="of" section="3.4.3"/>. If the received record falls within the
window and is new, or if the record is to the right of the window,
then the record is new.</t> new.
</t>
          <t>The window MUST NOT <bcp14>MUST NOT</bcp14> be updated due to a received record until the that record has been deprotected
successfully.</t>
        </section>
        <section anchor="handling-invalid-records" numbered="true" toc="default">
          <name>Handling Invalid Records</name>
          <t>Unlike TLS, DTLS is resilient in the face of invalid records (e.g.,
invalid formatting, length, MAC, etc.).  In general, invalid records
SHOULD
<bcp14>SHOULD</bcp14> be silently discarded, thus preserving the association;
however, an error MAY <bcp14>MAY</bcp14> be logged for diagnostic purposes.
Implementations which choose to generate an alert instead, MUST instead <bcp14>MUST</bcp14>
generate fatal 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)
DoS attacks because UDP forgery is so easy.
Thus, generating fatal alerts is NOT RECOMMENDED <bcp14>NOT RECOMMENDED</bcp14> for such transports, both
to increase the reliability of DTLS service and to avoid the risk
of spoofing attacks sending traffic to unrelated third parties.</t>
          <t>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.</t>
          <t>Note that because invalid records are rejected at a layer lower than
the handshake state machine, they do not affect pending
retransmission timers.</t>
        </section>
        <section anchor="aead-limits" numbered="true" toc="default">
          <name>AEAD Limits</name>
          <t>Section 5.5 of TLS <xref target="TLS13" format="default"/>
          <t><xref target="RFC8446" sectionFormat="of" section="5.5"/> defines limits on the number of records that can
be protected using the same keys. These limits are specific to an AEAD
algorithm,
algorithm and apply equally to DTLS. Implementations SHOULD NOT <bcp14>SHOULD NOT</bcp14> protect more
records than allowed by the limit specified for the negotiated AEAD.
Implementations SHOULD <bcp14>SHOULD</bcp14> initiate a key update before reaching this limit.</t>
          <t><xref target="TLS13" target="RFC8446" format="default"/> does not specify a limit for AEAD_AES_128_CCM, but the analysis in
<xref target="ccm-bounds" format="default"/> shows that a limit of 2^23 packets can be used to obtain the
same confidentiality protection as the limits specified in TLS.</t>
          <t>The usage limits defined in TLS 1.3 exist for protection against attacks
on confidentiality and apply to successful applications of AEAD protection. The
integrity protections in authenticated encryption also depend on limiting the
number of attempts to forge packets. TLS achieves this by closing connections
after any record fails an authentication check. In comparison, DTLS ignores any
packet that cannot be authenticated, allowing multiple forgery attempts.</t>
          <t>Implementations MUST <bcp14>MUST</bcp14> count the number of received packets that fail
authentication with each key. If the number of packets that fail authentication
exceed
exceeds a limit that is specific to the AEAD in use, an implementation SHOULD <bcp14>SHOULD</bcp14>
immediately close the connection. Implementations SHOULD <bcp14>SHOULD</bcp14> initiate a key update
with update_requested before reaching this limit. Once a key update has been
initiated, the previous keys can be dropped when the limit is reached rather
than closing the connection. Applying a limit reduces the probability that an
attacker is able to successfully forge a packet; see <xref target="AEBounds" format="default"/> and
<xref target="ROBUST" format="default"/>.</t>
          <t>For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305, the limit
on the number of records that fail authentication is 2^36. Note that the
analysis in <xref target="AEBounds" format="default"/> supports a higher limit for the  AEAD_AES_128_GCM and
AEAD_AES_256_GCM, but this specification recommends a lower limit. For
AEAD_AES_128_CCM, the limit on the number of records that fail authentication
is 2^23.5; see <xref target="ccm-bounds" format="default"/>.</t>
          <t>The AEAD_AES_128_CCM_8 AEAD, as used in TLS_AES_128_CCM_8_SHA256, does not have a
limit on the number of records that fail authentication that both limits the
probability of forgery by the same amount and does not expose implementations
to the risk of denial of service; see <xref target="ccm-short" format="default"/>. Therefore,
TLS_AES_128_CCM_8_SHA256 MUST NOT <bcp14>MUST NOT</bcp14> be used in DTLS without additional safeguards
against forgery. Implementations MUST <bcp14>MUST</bcp14> set usage limits for AEAD_AES_128_CCM_8
based on an understanding of any additional forgery protections that are used.</t>

<!-- [IANA FLAG] This "Any TLS cipher suite that is" sentence also
appears in the IANA Cons. section. -->

          <t>Any TLS cipher suite that is specified for use with DTLS MUST <bcp14>MUST</bcp14> define limits on
the use of the associated AEAD function that preserves margins for both
confidentiality and integrity. That is, limits MUST <bcp14>MUST</bcp14> be specified for the number
of packets that can be authenticated and for the number of packets that can fail
authentication before a key update is required. Providing a reference to any analysis upon which values are
based - -- and any assumptions used in that analysis - -- allows limits to be adapted
to varying usage conditions.</t>
        </section>
      </section>
    </section>
    <section anchor="dtls" numbered="true" toc="default">
      <name>The DTLS Handshake Protocol</name>
      <t>DTLS 1.3 re-uses reuses the TLS 1.3 handshake messages and flows, with
the following changes:</t>
      <ol spacing="normal" type="1"><li>To handle message loss, reordering, and fragmentation fragmentation, modifications to
the handshake header are necessary.</li>
        <li>Retransmission timers are introduced to handle message loss.</li>
        <li>A new ACK content type has been added for reliable message delivery of handshake messages.</li>
      </ol>
      <t>Note that
      <t>
In addition, DTLS reuses TLS 1.3 already supports a cookie extension, which is used 1.3's "cookie" extension to
prevent denial-of-service attacks. provide a return-routability
check as part of connection establishment. This is an important DoS
prevention mechanism is
described in more detail below since for UDP-based protocols are more vulnerable
to amplification attacks than a connection-oriented transport like protocols, unlike TCP-based protocols, for which
TCP
that performs establishes return-routability checks as part of the connection establishment.</t> establishment.
      </t>
      <t>DTLS implementations do not use the TLS 1.3 "compatibility mode" described in
Section D.4 of
<xref target="TLS13" format="default"/>. target="RFC8446" sectionFormat="of" section="D.4"/>.  DTLS servers MUST NOT <bcp14>MUST NOT</bcp14> echo the
"legacy_session_id" value from the client and endpoints MUST NOT <bcp14>MUST NOT</bcp14> send ChangeCipherSpec
messages.</t>
      <t>With these exceptions, the DTLS message formats, flows, and logic are
the same as those of TLS 1.3.</t>
      <section anchor="dos" numbered="true" toc="default">
        <name>Denial-of-Service Countermeasures</name>
        <t>Datagram security protocols are extremely susceptible to a variety of
DoS attacks.  Two attacks are of particular concern:</t>
        <ol spacing="normal" type="1"><li>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.</li>
          <li>An attacker can use the server as an amplifier by sending
connection initiation messages with a forged source address that belongs to a
victim.  The server then sends its response to the victim
machine, thus flooding it. Depending on the selected
parameters
parameters, this response message can be quite large, as
is the case for a Certificate message.</li>
        </ol>
        <t>In order to counter both of these attacks, DTLS borrows the stateless
cookie technique used by Photuris <xref target="RFC2522" format="default"/> and IKE <xref target="RFC7296" format="default"/>.  When
the client sends its ClientHello message to the server, the server
MAY
<bcp14>MAY</bcp14> respond with a HelloRetryRequest message. The HelloRetryRequest message,
as well as the cookie "cookie" extension, is defined in TLS 1.3.
The HelloRetryRequest message contains a stateless cookie (see
<xref target="TLS13" format="default"/>; Section 4.2.2). target="RFC8446" sectionFormat="comma" section="4.2.2"/>).
The client MUST <bcp14>MUST</bcp14> send a new ClientHello
with the cookie added as an extension.  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.</t>
        <t>The DTLS 1.3 specification changes how cookies are exchanged
compared to DTLS 1.2. DTLS 1.3 re-uses reuses the HelloRetryRequest message
and conveys the cookie to the client via an extension. The client
receiving the cookie uses the same extension to place
the cookie subsequently into a ClientHello message.
DTLS 1.2 1.2, on the other hand hand, used a separate message, namely the HelloVerifyRequest,
to pass a cookie to the client and did not utilize the extension mechanism.
For backwards compatibility reasons, the cookie field in the ClientHello
is present in DTLS 1.3 but is ignored by a DTLS 1.3 compliant 1.3-compliant server
implementation.</t>
        <t>The exchange is shown in <xref target="dtls-cookie-exchange" format="default"/>. Note that
the figure focuses on the cookie exchange; all other extensions
are omitted.</t>
        <figure anchor="dtls-cookie-exchange">
          <name>DTLS exchange Exchange with HelloRetryRequest containing Containing the "cookie" extension</name> Extension</name>
          <artwork name="" type="" type="ascii-art" align="left" alt=""><![CDATA[
      Client                                   Server
      ------                                   ------
      ClientHello           ------>

                            <----- HelloRetryRequest
                                    + cookie

      ClientHello           ------>
       + cookie

      [Rest of handshake]
]]></artwork>
        </figure>
        <t>The cookie "cookie" extension is defined in Section 4.2.2 of <xref target="TLS13" format="default"/>. target="RFC8446" sectionFormat="of" section="4.2.2"/>. When sending the
initial ClientHello, the client does not have a cookie yet. In this case,
the cookie "cookie" extension is omitted and the legacy_cookie field in the ClientHello
message MUST <bcp14>MUST</bcp14> be set to a zero-length vector (i.e., a zero-valued single byte length field).</t>
        <t>When responding to a HelloRetryRequest, the client MUST <bcp14>MUST</bcp14> create a new
ClientHello message following the description in Section 4.1.2 of <xref target="TLS13" format="default"/>.</t> target="RFC8446" sectionFormat="of" section="4.1.2"/>.</t>
        <t>If the HelloRetryRequest message is used, the initial ClientHello and
the HelloRetryRequest are included in the calculation of the
transcript hash. The computation of the
message hash for the HelloRetryRequest is done according to the description
in Section 4.4.1 of <xref target="TLS13" format="default"/>.</t> target="RFC8446" sectionFormat="of" section="4.4.1"/>.</t>
        <t>The handshake transcript is not reset with the second ClientHello ClientHello,
and a stateless server-cookie implementation requires the content or hash
of the initial ClientHello (and HelloRetryRequest)
to be stored in the cookie. The initial ClientHello is included in the
handshake transcript as a synthetic "message_hash" message, so only the hash
value is needed for the handshake to complete, though the complete
HelloRetryRequest contents are needed.</t>
        <t>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. If the client's apparent IP address is embedded
in the cookie, this prevents an attacker from generating an acceptable
ClientHello apparently from another user.</t>
        <t>One potential attack on this scheme is for the attacker to collect a
number of cookies from different addresses where it controls endpoints
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 to allow legitimate clients to
handshake through the transition (e.g., a client 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.  <xref target="RFC7296" format="default"/> suggests adding a key
identifier to cookies to detect this case. An alternative approach is
simply to try verifying with both secrets. It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that
servers implement a key rotation scheme that allows the server
to manage keys with overlapping lifetime.</t> lifetimes.
</t>
        <t>Alternatively, the server can store timestamps in the cookie and
reject cookies that were generated outside a certain
interval of time.</t>
        <t>DTLS servers SHOULD <bcp14>SHOULD</bcp14> 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, e.g., where
ICE <xref target="RFC8445" format="default"/> has been used to establish bidirectional connectivity,
the server MAY <bcp14>MAY</bcp14> be
configured not to perform a cookie exchange.  The default SHOULD <bcp14>SHOULD</bcp14> be
that the exchange is performed, however.  In addition, the server MAY <bcp14>MAY</bcp14>
choose not to do a cookie exchange when a session is resumed or, more
generically, when the DTLS handshake uses a PSK-based key exchange
and the IP address matches one associated with the PSK.
Servers which process 0-RTT requests and send 0.5-RTT responses without a cookie exchange risk being used in an amplification attack if the size of outgoing messages greatly exceeds the size of those that are received.
A server SHOULD <bcp14>SHOULD</bcp14> limit the amount of data it sends toward a client address
to three times the amount of data sent by the client before
it verifies that the client is able to receive data at that address.
A client address is valid after a cookie exchange or handshake completion.
Clients MUST <bcp14>MUST</bcp14> be prepared to do a cookie exchange with every
handshake. Note that cookies are only valid for the existing
handshake and cannot be stored for future handshakes.</t>
        <t>If a server receives a ClientHello with an invalid cookie, it
MUST
<bcp14>MUST</bcp14> terminate the handshake with an "illegal_parameter" alert.
This allows the client to restart the connection from
scratch without a cookie.</t>
        <t>As described in Section 4.1.4 of <xref target="TLS13" format="default"/>, target="RFC8446" sectionFormat="of" section="4.1.4"/>, clients MUST <bcp14>MUST</bcp14>
abort the handshake with an "unexpected_message" alert in response
to any second HelloRetryRequest which was sent in the same connection
(i.e., where the ClientHello was itself in response to a HelloRetryRequest).</t>
        <t>DTLS clients which do not want to receive a Connection ID SHOULD <bcp14>SHOULD</bcp14>
still offer the "connection_id" extension <xref target="RFC9146" format="default"/> unless
there is an application profile to the contrary. This permits
a server which wants to receive a CID to negotiate one.</t>
      </section>
      <section anchor="dtls-handshake-message-format" numbered="true" toc="default">
        <name>DTLS Handshake Message Format</name>
        <t>In order
        <t>DTLS uses the same Handshake messages as TLS 1.3. However,
prior to transmission they are converted to DTLSHandshake
messages, which contain extra data needed to support
message loss, reordering, and message
fragmentation, DTLS modifies the TLS 1.3 handshake header:</t>
        <artwork fragmentation.</t>

<sourcecode name="" type="" align="left" alt=""><![CDATA[ type="tls-presentation"><![CDATA[
    enum {
        client_hello(1),
        server_hello(2),
        new_session_ticket(4),
        end_of_early_data(5),
        encrypted_extensions(8),
        request_connection_id(9),           /* New */
        new_connection_id(10),              /* New */
        certificate(11),
        certificate_request(13),
        certificate_verify(15),
        finished(20),
        key_update(24),
        message_hash(254),
        (255)
    } HandshakeType;
]]></sourcecode>

<sourcecode name="" type="tls-presentation"><![CDATA[
    struct {
        HandshakeType msg_type;    /* handshake type */
        uint24 length;             /* bytes in message */
        uint16 message_seq;        /* DTLS-required field */
        uint24 fragment_offset;    /* DTLS-required field */
        uint24 fragment_length;    /* DTLS-required field */
        select (msg_type) {
            case client_hello:          ClientHello;
            case server_hello:          ServerHello;
            case end_of_early_data:     EndOfEarlyData;
            case encrypted_extensions:  EncryptedExtensions;
            case certificate_request:   CertificateRequest;
            case certificate:           Certificate;
            case certificate_verify:    CertificateVerify;
            case finished:              Finished;
            case new_session_ticket:    NewSessionTicket;
            case key_update:            KeyUpdate;
            case request_connection_id: RequestConnectionId;
            case new_connection_id:     NewConnectionId;
        } body;
    } Handshake;
]]></artwork> DTLSHandshake;
]]></sourcecode>

<t>
  In DTLS 1.3, the message transcript is computed over the original
TLS 1.3-style Handshake messages without the message_seq,
fragment_offset, and fragment_length values. Note that this is
a change from DTLS 1.2 where those values were included
in the transcript.
</t>
        <t>The first message each side transmits in each association always has
message_seq = 0.  Whenever a new message is generated, the
message_seq value is incremented by one. When a message is
retransmitted, the old message_seq value is re-used, reused, i.e., not
incremented. From the perspective of the DTLS record layer, the retransmission is
a new record.  This record will have a new
DTLSPlaintext.sequence_number value.</t>
        <t>Note:
        <t indent="3">Note: In DTLS 1.2 1.2, the message_seq was reset to zero in case of a
rehandshake (i.e., renegotiation). On the surface, a rehandshake in DTLS 1.2
shares similarities with a post-handshake message exchange in DTLS 1.3. However,
in DTLS 1.3 the message_seq is not reset reset, to allow distinguishing a
retransmission from a previously sent post-handshake message from a newly
sent post-handshake message.</t>
        <t>DTLS implementations maintain (at least notionally) a
next_receive_seq counter.  This counter is initially set to zero.
When a handshake message is received, if its message_seq value 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 <bcp14>MUST</bcp14> be discarded.  If the sequence number is greater than
next_receive_seq, the implementation SHOULD <bcp14>SHOULD</bcp14> queue the message but MAY <bcp14>MAY</bcp14>
discard it.  (This is a simple space/bandwidth tradeoff).</t> trade-off).</t>
        <t>In addition to the handshake messages that are deprecated by the TLS 1.3
specification, DTLS 1.3 furthermore deprecates the HelloVerifyRequest message
originally defined in DTLS 1.0. DTLS 1.3-compliant implements MUST NOT implementations <bcp14>MUST NOT</bcp14>
use the HelloVerifyRequest to execute a return-routability check. A
dual-stack DTLS 1.2/DTLS 1.2 / DTLS 1.3 client MUST, <bcp14>MUST</bcp14>, however, be prepared to
interact with a DTLS 1.2 server.</t>
      </section>
      <section anchor="clienthello-message" numbered="true" toc="default">
        <name>ClientHello Message</name>
        <t>The format of the ClientHello used by a DTLS 1.3 client differs from the
TLS 1.3 ClientHello format format, as shown below.</t>
        <artwork
<sourcecode name="" type="" align="left" alt=""><![CDATA[ type="tls-presentation"><![CDATA[
    uint16 ProtocolVersion;
    opaque Random[32];

    uint8 CipherSuite[2];    /* Cryptographic suite selector */

    struct {
        ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2
        Random random;
        opaque legacy_session_id<0..32>;
        opaque legacy_cookie<0..2^8-1>;                  // DTLS
        CipherSuite cipher_suites<2..2^16-2>;
        opaque legacy_compression_methods<1..2^8-1>;
        Extension extensions<8..2^16-1>;
    } ClientHello;
]]></artwork>
]]></sourcecode>

        <dl newline="false" spacing="normal">
          <dt>legacy_version:</dt>
          <dd>
  In previous versions of DTLS, this field was used for version
negotiation and represented the highest version number supported by
the client. Experience has shown that many servers do not properly
implement version negotiation, leading to "version intolerance" in
which the server rejects an otherwise acceptable ClientHello with a
version number higher than it supports. In DTLS 1.3, the client
indicates its version preferences in the "supported_versions"
extension (see Section 4.2.1 of <xref target="TLS13" format="default"/>) target="RFC8446" sectionFormat="of" section="4.2.1"/>) and the
legacy_version field MUST <bcp14>MUST</bcp14> be set to {254, 253}, which was the version
number for DTLS 1.2. The supported_versions entries for DTLS 1.0 and DTLS 1.2 are
0xfeff and 0xfefd (to match the wire versions). The value 0xfefc is used
to indicate DTLS 1.3.</dd>
          <dt>random:</dt>
          <dd>
  Same as for TLS 1.3, except that the downgrade sentinels described
in Section 4.1.3 of <xref target="TLS13" format="default"/> target="RFC8446" sectionFormat="of" section="4.1.3"/> when TLS 1.2
and TLS 1.1 and below are negotiated apply to DTLS 1.2 and DTLS 1.0 respectively.</dd> 1.0, respectively.
</dd>
          <dt>legacy_session_id:</dt>
          <dd>
  Versions of TLS and DTLS before version 1.3 supported a "session resumption"
feature
feature, which has been merged with pre-shared keys (PSK) in version 1.3.  A client
which has a cached session ID set by a pre-DTLS 1.3 server SHOULD <bcp14>SHOULD</bcp14> set this
field to that value. Otherwise, it MUST <bcp14>MUST</bcp14> be set as a zero-length vector
(i.e., a zero-valued single byte length field).</dd>
          <dt>legacy_cookie:</dt>
          <dd>
  A DTLS 1.3-only client MUST <bcp14>MUST</bcp14> set the legacy_cookie field to zero length.
If a DTLS 1.3 ClientHello is received with any other value in this field,
the server MUST <bcp14>MUST</bcp14> abort the handshake with an "illegal_parameter" alert.</dd>
          <dt>cipher_suites:</dt>
          <dd>
  Same as for TLS 1.3; only suites with DTLS-OK=Y may be used.</dd>
          <dt>legacy_compression_methods:</dt>
          <dd>
  Same as for TLS 1.3.</dd>
          <dt>extensions:</dt>
          <dd>
  Same as for TLS 1.3.</dd>
        </dl>
      </section>
      <section anchor="serverhello-message" numbered="true" toc="default">
        <name>ServerHello Message</name>
        <t>The DTLS 1.3 ServerHello message is the same as the TLS 1.3
ServerHello message, except that the legacy_version field
is set to 0xfefd, indicating DTLS 1.2.</t>
      </section>
      <section anchor="handshake-message-fragmentation-and-reassembly" numbered="true" toc="default">
        <name>Handshake Message Fragmentation and Reassembly</name>
        <t>As described in <xref target="transport-layer-mapping" format="default"/> format="default"/>, one or more handshake
messages may be carried in a single datagram. However, handshake messages are
potentially bigger than the size allowed by the underlying datagram transport.
DTLS provides a mechanism for fragmenting a handshake message over a
number of records, each of which can be transmitted in separate datagrams, thus
avoiding IP fragmentation.</t>
        <t>When transmitting the handshake message, the sender divides the
message into a series of N contiguous data ranges. The ranges MUST NOT <bcp14>MUST NOT</bcp14>
overlap.  The sender then creates N handshake DTLSHandshake messages, all with the
same message_seq value as the original handshake DTLSHandshake 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.
Each handshake message fragment that is placed into a record
MUST
<bcp14>MUST</bcp14> be delivered in a single UDP datagram.</t>
        <t>When a DTLS implementation receives a handshake message fragment corresponding
to the next expected handshake message sequence number, it
MUST buffer
<bcp14>MUST</bcp14> process it, either by buffering it until it has the entire
handshake message or by processing any in-order portions of the message.
The transcript consists of complete TLS Handshake messages (reassembled
as necessary). Note that this requires removing the message_seq,
fragment_offset, and fragment_length fields to create the Handshake
structure.
        </t>
        <t>
DTLS
implementations MUST <bcp14>MUST</bcp14> be able to handle overlapping fragment ranges.
This allows senders to retransmit handshake messages with smaller
fragment sizes if the PMTU estimate changes. Senders MUST NOT <bcp14>MUST NOT</bcp14> change
handshake message bytes upon retransmission. Receivers MAY <bcp14>MAY</bcp14> check
that retransmitted bytes are identical and SHOULD <bcp14>SHOULD</bcp14> abort the handshake
with an "illegal_parameter" alert if the value of a byte changes.</t>
        <t>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 handshake messages into the same datagram: in the same record or in
separate records.</t>
      </section>
      <section anchor="end-of-early-data" numbered="true" toc="default">
        <name>End Of Early Data</name>
        <name>EndOfEarlyData Message</name>

        <t>The DTLS 1.3 handshake has one important difference from the
TLS 1.3 handshake: the EndOfEarlyData message is omitted both
from the wire and the handshake transcript: because transcript. Because DTLS
records have epochs, EndOfEarlyData is not necessary to determine
when the early data is complete, and because DTLS is lossy,
attackers can trivially mount the deletion attacks that EndOfEarlyData
prevents in TLS. Servers SHOULD NOT <bcp14>SHOULD NOT</bcp14> accept records from epoch 1 indefinitely once they are able to process records from epoch 3. Though reordering of IP packets can result in records from epoch 1 arriving after records from epoch 3, this is not likely to persist for very long relative to the round trip time. Servers could discard epoch 1  keys after the first epoch 3 data arrives, or retain keys for processing epoch 1 data for a short period.
(See <xref target="dtls-epoch" format="default"/> for the definitions of each epoch.)</t>
      </section>
      <section anchor="dtls-handshake-flights" numbered="true" toc="default">
        <name>DTLS Handshake Flights</name>
        <t>DTLS handshake messages are grouped into a series of message flights. A flight starts with the
handshake message transmission of one peer and ends with the expected response from the
other peer. <xref target="tab-flights" format="default"/> contains a complete list of message combinations that constitute flights.</t>
        <table anchor="tab-flights" align="center">
          <name>Flight Handshake Message Combinations.</name> Combinations</name>
          <thead>
            <tr>
              <th align="left">Note</th>
              <th align="left">Client</th>
              <th align="left">Server</th>
              <th align="left">Handshake Messages</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">&nbsp;</td>
              <td align="left">x</td>
              <td align="left">&nbsp;</td>
              <td align="left">ClientHello</td>
            </tr>
            <tr>
              <td align="left">&nbsp;</td>
              <td align="left">&nbsp;</td>
              <td align="left">x</td>
              <td align="left">HelloRetryRequest</td>
            </tr>
            <tr>
              <td align="left">&nbsp;</td>
              <td align="left">&nbsp;</td>
              <td align="left">x</td>
              <td align="left">ServerHello, EncryptedExtensions, CertificateRequest, Certificate, CertificateVerify, Finished</td>
            </tr>
            <tr>
              <td align="left">1</td>
              <td align="left">x</td>
              <td align="left">&nbsp;</td>
              <td align="left">Certificate, CertificateVerify, Finished</td>
            </tr>
            <tr>
              <td align="left">1</td>
              <td align="left">&nbsp;</td>
              <td align="left">x</td>
              <td align="left">NewSessionTicket</td>
            </tr>
          </tbody>
        </table>
        <t>Remarks:</t>
        <ul spacing="normal">
          <li>
            <xref target="tab-flights" format="default"/> does not highlight any of the optional messages.</li>
          <li>Regarding note (1): When a handshake flight is sent without any expected response, as it is the case with
 the client's final flight or with the NewSessionTicket message, the flight must be
 acknowledged with an ACK message.</li>
        </ul>
        <t>Below are several example message exchange exchanges illustrating the flight concept.
The notational conventions from <xref target="TLS13" target="RFC8446" format="default"/> are used.</t>
        <figure anchor="dtls-full">
          <name>Message flights Flights for a full Full DTLS Handshake (with cookie exchange)</name> Cookie Exchange)</name>
          <artwork name="" type="" type="ascii-art" align="left" alt=""><![CDATA[
Client                                            Server

                                                           +--------+
 ClientHello                                               | Flight |
                       -------->                           +--------+

                                                           +--------+
                       <--------        HelloRetryRequest  | Flight |
                                         + cookie          +--------+

                                                           +--------+
ClientHello                                                | Flight |
 + cookie              -------->                           +--------+

                                              ServerHello
                                    {EncryptedExtensions}  +--------+
                                    {CertificateRequest*}  | Flight |
                                           {Certificate*}  +--------+
                                     {CertificateVerify*}
                                               {Finished}
                       <--------      [Application Data*]

 {Certificate*}                                            +--------+
 {CertificateVerify*}                                      | Flight |
 {Finished}            -------->                           +--------+
 [Application Data]
                                                           +--------+
                       <--------                    [ACK]  | Flight |
                                      [Application Data*]  +--------+

 [Application Data]    <------->      [Application Data]
]]></artwork>
        </figure>
        <figure anchor="dtls-psk">
          <name>Message flights Flights for resumption Resumption and PSK handshake Handshake (without cookie exchange)</name> Cookie Exchange)</name>
          <artwork name="" type="" type="ascii-art" align="left" alt=""><![CDATA[
 ClientHello                                              +--------+
  + pre_shared_key                                        | Flight |
  + psk_key_exchange_modes                                +--------+
  + key_share*         -------->

                                             ServerHello
                                        + pre_shared_key  +--------+
                                            + key_share*  | Flight |
                                   {EncryptedExtensions}  +--------+
                       <--------              {Finished}
                                     [Application Data*]
                                                          +--------+
 {Finished}            -------->                          | Flight |
 [Application Data*]                                      +--------+

                                                          +--------+
                       <--------                   [ACK]  | Flight |
                                     [Application Data*]  +--------+

 [Application Data]    <------->      [Application Data]
]]></artwork>
        </figure>
        <figure anchor="dtls-zero-rtt">
          <name>Message flights Flights for the Zero-RTT handshake</name> Handshake</name>
          <artwork name="" type="" type="ascii-art" align="left" alt=""><![CDATA[
Client                                            Server

 ClientHello
  + early_data
  + psk_key_exchange_modes                                +--------+
  + key_share*                                            | Flight |
  + pre_shared_key                                        +--------+
 (Application Data*)     -------->

                                             ServerHello
                                        + pre_shared_key
                                            + key_share*  +--------+
                                   {EncryptedExtensions}  | Flight |
                                              {Finished}  +--------+
                       <--------     [Application Data*]

                                                          +--------+
 {Finished}            -------->                          | Flight |
 [Application Data*]                                      +--------+

                                                          +--------+
                       <--------                   [ACK]  | Flight |
                                     [Application Data*]  +--------+

 [Application Data]    <------->      [Application Data]
]]></artwork>
        </figure>
        <figure anchor="dtls-post-handshake-ticket">
          <name>Message flights Flights for the NewSessionTicket message</name> Message</name>
          <artwork name="" type="" type="ascii-art" align="left" alt=""><![CDATA[
Client                                            Server

                                                          +--------+
                       <--------       [NewSessionTicket] | Flight |
                                                          +--------+

                                                          +--------+
[ACK]                  -------->                          | Flight |
                                                          +--------+
]]></artwork>
        </figure>
        <t>KeyUpdate, NewConnectionId NewConnectionId, and RequestConnectionId follow a similar pattern
to NewSessionTicket: a single message sent by one side
followed by an ACK by the other.</t>
      </section>
      <section anchor="timeout-retransmissions" numbered="true" toc="default">
        <name>Timeout and Retransmission</name>
        <section anchor="state-machine" numbered="true" toc="default">
          <name>State Machine</name>
          <t>DTLS uses a simple timeout and retransmission scheme with the
state machine shown in <xref target="dtls-timeout-state-machine" format="default"/>.</t>
          <figure anchor="dtls-timeout-state-machine">
            <name>DTLS timeout Timeout and retransmission state machine</name> Retransmission State Machine</name>
            <artwork name="" type="" type="ascii-art" align="left" alt=""><![CDATA[
                             +-----------+
                             | PREPARING |
                +----------> |           |
                |            |           |
                |            +-----------+
                |                  |
                |                  | Buffer next flight
                |                  |
                |                 \|/
                |            +-----------+
                |            |           |
                |            |  SENDING  |<------------------+
                |            |           |                   |
                |            +-----------+                   |
        Receive |                  |                         |
           next |                  | Send flight or partial  |
         flight |                  | flight                  |
                |                  |                         |
                |                  | Set retransmit timer    |
                |                 \|/                        |
                |            +-----------+                   |
                |            |           |                   |
                +------------|  WAITING  |-------------------+
                |     +----->|           |   Timer expires   |
                |     |      +-----------+                   |
                |     |          |  |   |                    |
                |     |          |  |   |                    |
                |     +----------+  |   +--------------------+
                |    Receive record |   Read retransmit or ACK
        Receive |  (Maybe Send ACK) |
           last |                   |
         flight |                   | Receive ACK
                |                   | for last flight
               \|/                  |
                                    |
            +-----------+           |
            |           | <---------+
            | FINISHED  |
            |           |
            +-----------+
                |  /|\
                |   |
                |   |
                +---+

          Server read retransmit
              Retransmit ACK
]]></artwork>
          </figure>
          <t>The state machine has four basic states: PREPARING, SENDING, WAITING,
and FINISHED.</t>
          <t>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 transmission
buffer first) and enters the SENDING state.</t>
          <t>In the SENDING state, the implementation transmits the buffered
flight of messages. If the implementation has received one or more
ACKs (see <xref target="ack-msg" format="default"/>) from the peer, then it SHOULD <bcp14>SHOULD</bcp14> omit any messages or
message fragments which have already been ACKed. acknowledged. Once the messages
have been sent, the implementation then sets a retransmit timer
and enters the WAITING state.</t>
          <t>There are four ways to exit the WAITING state:</t>
          <ol spacing="normal" type="1"><li>The retransmit timer expires: the implementation transitions to
the SENDING state, where it retransmits the flight, adjusts and re-arms the
retransmit timer (see <xref target="timer-values" format="default"/>), and returns to the WAITING state.</li>
            <li>The implementation reads an ACK from the peer: upon receiving
an ACK for a partial flight (as mentioned in <xref target="sending-acks" format="default"/>),
the implementation transitions
to the SENDING state, where it retransmits the unacked unacknowledged portion
of the flight, adjusts and re-arms the retransmit timer, and returns to the
WAITING state.
 Upon receiving an ACK for a complete flight,
the implementation cancels all retransmissions and either
remains in WAITING, or, if the ACK was for the final flight,
transitions to FINISHED.</li>
<li>The implementation reads a retransmitted flight from the peer: peer
when none of the messages that it sent in response to that flight
   have been acknowledged: the
implementation transitions to the SENDING state, where it
retransmits the flight, adjusts and re-arms 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.</li>
            <li>The implementation receives some or all of 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) may also trigger the implementation to send an ACK, as
described in <xref target="sending-acks" format="default"/>.</li>
          </ol>
          <t>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.</t>
          <t>In addition, for at least twice the default MSL defined for <xref target="RFC0793" format="default"/>,
when in the FINISHED state, the server MUST <bcp14>MUST</bcp14> respond to retransmission
of the client's final flight with a retransmit of its ACK.</t>
          <t>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 <bcp14>MUST</bcp14> either
discard or buffer all application data records for epoch 3 and
above until they have received the Finished message from the
peer. Implementations MAY <bcp14>MAY</bcp14> 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.</t>
        </section>
        <section anchor="timer-values" numbered="true" toc="default">
          <name>Timer Values</name>
          <t>The configuration of timer settings varies with implementations, and certain
deployment environments require timer value adjustments. Mishandling
of the timer can lead to serious congestion problems, problems -- for example example, if
many instances of a DTLS time out early and retransmit too quickly on
a congested link.</t>
          <t>Unless implementations have deployment-specific and/or external information about the round trip time,
implementations SHOULD <bcp14>SHOULD</bcp14> use an initial timer value of 1000 ms and double
the value at each retransmission, up to no less than 60 seconds (the maximum as specified in
RFC 6298 <xref target="RFC6298" format="default"/> maximum). Application specific format="default"/>). Application-specific profiles MAY <bcp14>MAY</bcp14>
recommend shorter or longer timer values. For instance:</t>
          <ul spacing="normal">
            <li>Profiles for specific deployment environments, such as in low-power,
multi-hop mesh scenarios as used in some Internet of Things (IoT) networks,
MAY
<bcp14>MAY</bcp14> specify longer timeouts. See <xref target="I-D.ietf-uta-tls13-iot-profile" format="default"/> for
more information about one such DTLS 1.3 IoT profile.</li>
            <li>Real-time protocols MAY <bcp14>MAY</bcp14> specify shorter timeouts. It is RECOMMENDED <bcp14>RECOMMENDED</bcp14>
that for DTLS-SRTP <xref target="RFC5764" format="default"/>, a default timeout of
400ms
400 ms be used; because customer experience degrades with one-way latencies
of greater than 200ms, 200 ms, real-time deployments are less likely
to have long latencies.</li>
          </ul>
          <t>In settings where there is external information (for instance instance, from an ICE <xref target="RFC8445" format="default"/> handshake, or from previous connections to the same server)
about the RTT, implementations SHOULD <bcp14>SHOULD</bcp14> use 1.5 times that RTT estimate
as the retransmit timer.</t>
          <t>Implementations SHOULD <bcp14>SHOULD</bcp14> retain the current timer value until a
message is transmitted and acknowledged without having to
be retransmitted, at which time the value SHOULD <bcp14>SHOULD</bcp14> be adjusted
to 1.5 times the measured round trip time for that
message. After a long period of idleness, no less
than 10 times the current timer value, implementations MAY <bcp14>MAY</bcp14> reset the
timer to the initial value.</t>
          <t>Note that because retransmission is for the handshake and not dataflow, the effect on
congestion of shorter timeouts is smaller than in generic protocols
such as TCP or QUIC. Experience with DTLS 1.2, which uses a
simpler "retransmit everything on timeout" approach, has not shown
serious congestion problems in practice.</t>
        </section>
        <section anchor="large-flight-sizes" numbered="true" toc="default">
          <name>Large Flight Sizes</name>
          <t>DTLS does not have any built-in congestion control or rate control;
in general general, this is not an issue because messages tend to be small.
However, in principle, some messages - -- especially Certificate - -- can
be quite large. If all the messages in a large flight are sent
at once, this can result in network congestion. A better strategy
is to send out only part of the flight, sending more when
messages are acknowledged. Several extensions have been standardized
to reduce the size of the certificate message, Certificate message -- for example example,
the cached information "cached_info" extension <xref target="RFC7924" format="default"/>, format="default"/>; certificate
compression <xref target="RFC8879" format="default"/> format="default"/>; and <xref target="RFC6066" format="default"/>, which defines the "client_certificate_url"
extension allowing DTLS clients to send a sequence of Uniform
Resource Locators (URLs) instead of the client certificate.</t>
          <t>DTLS stacks SHOULD NOT <bcp14>SHOULD NOT</bcp14> send more than 10 records in a single transmission.</t>
        </section>
        <section anchor="state-machine-duplication" numbered="true" toc="default">
          <name>State machine duplication Machine Duplication for post-handshake messages</name> Post-Handshake Messages</name>
          <t>DTLS 1.3 makes use of the following categories of post-handshake messages:</t>
          <ol spacing="normal" type="1"><li>NewSessionTicket</li>
            <li>KeyUpdate</li>
            <li>NewConnectionId</li>
            <li>RequestConnectionId</li>
            <li>Post-handshake client authentication</li>
          </ol>
          <t>Messages of each category can be sent independently, and reliability is established
via independent state machines machines, each of which behaves as described in <xref target="state-machine" format="default"/>.
For example, if a server sends a NewSessionTicket and a CertificateRequest message,
two independent state machines will be created.</t>
          <t>As explained in the corresponding sections, sending
          <t>Sending multiple instances of messages of
a given category without having completed earlier transmissions is allowed for some
categories, but not for others.
 Specifically, a server MAY <bcp14>MAY</bcp14> send multiple NewSessionTicket
messages at once without awaiting ACKs for earlier NewSessionTicket messages first. Likewise, a
server MAY <bcp14>MAY</bcp14> send multiple CertificateRequest messages at once without having completed
earlier client authentication requests before. In contrast, implementations MUST NOT <bcp14>MUST NOT</bcp14>
send KeyUpdate, NewConnectionId NewConnectionId, or RequestConnectionId messages if an earlier message
of the same type has not yet been acknowledged.</t>
          <t>Note:
          <t indent="3">Note: Except for post-handshake client authentication, which involves handshake messages
in both directions, post-handshake messages are single-flight, and their respective state
machines on the sender side reduce to waiting for an ACK and retransmitting the original
message. In particular, note that a RequestConnectionId message does not force the receiver
to send a NewConnectionId message in reply, and both messages are therefore treated
independently.</t>
          <t>Creating and correctly updating multiple state machines requires feedback from the handshake
logic to the state machine layer, indicating which message belongs to which state machine.
For example, if a server sends multiple CertificateRequest messages and receives a Certificate
message in response, the corresponding state machine can only be determined after inspecting the
certificate_request_context field. Similarly, a server sending a single CertificateRequest
and receiving a NewConnectionId message in response can only decide that the NewConnectionId
message should be treated through an independent state machine after inspecting the handshake
message type.</t>
        </section>
      </section>
      <section anchor="certificateverify-and-finished-messages" numbered="true" toc="default">
        <name>CertificateVerify and Finished Messages</name>
        <t>CertificateVerify and Finished messages have the same format as in
TLS 1.3.  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 CertificateVerify and the Finished messages MUST be computed as
if each handshake message had been sent as a single fragment following
the algorithm described in Section 4.4.3 and Section 4.4.4 of <xref target="TLS13" format="default"/>, respectively.</t>
      </section>
      <section anchor="cryptographic-label-prefix" numbered="true" toc="default">
        <name>Cryptographic Label Prefix</name>
        <t>Section 7.1 of <xref target="TLS13" format="default"/>
        <t><xref target="RFC8446" sectionFormat="of" section="7.1"/> specifies that HKDF-Expand-Label uses
a label prefix of "tls13 ". For DTLS 1.3, that label SHALL <bcp14>SHALL</bcp14> be
"dtls13".  This ensures key separation between DTLS 1.3 and
TLS 1.3. Note that there is no trailing space; this is necessary
in order to keep the overall label size inside of one hash
iteration because "DTLS" is one letter longer than "TLS".</t>
      </section>
      <section anchor="alert-messages" numbered="true" toc="default">
        <name>Alert Messages</name>
        <t>Note that Alert 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 <bcp14>SHOULD</bcp14> generate a new alert
message if the offending record is received again (e.g., as a
retransmitted handshake message).  Implementations SHOULD <bcp14>SHOULD</bcp14> detect when
a peer is persistently sending bad messages and terminate the local
connection state after such misbehavior is detected. Note that alerts
are not reliably transmitted; implementation SHOULD NOT implementations <bcp14>SHOULD NOT</bcp14> depend on
receiving alerts in order to signal errors or connection closure.</t>
        <t>
Any data received with an epoch/sequence number pair after
that of a valid received closure alert <bcp14>MUST</bcp14> be ignored. Note:
this is a change from TLS 1.3 which depends on the order of
receipt rather than the epoch and sequence number.</t>
      </section>
      <section anchor="establishing-new-associations-with-existing-parameters" numbered="true" toc="default">
        <name>Establishing New Associations with Existing Parameters</name>
        <t>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
<bcp14>SHOULD</bcp14> proceed with a new handshake but MUST NOT <bcp14>MUST NOT</bcp14> destroy the existing
association until the client has demonstrated reachability either by
completing a cookie exchange or by completing a complete handshake
including delivering a verifiable Finished message.  After a correct
Finished message is received, the server MUST <bcp14>MUST</bcp14> 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.</t>
        <t>Note: it
        <t indent="3">Note: It is not always possible to distinguish which association
a given record is from. For instance, if the client performs
a handshake, abandons the connection, and then immediately starts
a new handshake, it may not be possible to tell which connection
a given protected record is for. In these cases, trial decryption
may be necessary, though implementations could use CIDs to avoid
the 5-tuple-based ambiguity.</t>
      </section>
    </section>
    <section anchor="example-of-handshake-with-timeout-and-retransmission" numbered="true" toc="default">
      <name>Example of Handshake with Timeout and Retransmission</name>
      <t>The following is an example of a handshake with lost packets and
retransmissions. Note that the client sends an empty ACK message
because it can only acknowledge Record 2 sent by the server once it has
processed messages in Record 0 needed to establish epoch 2 keys, which
are needed to encrypt or decrypt messages found in Record 2.  <xref target="ack-msg" format="default"/>
provides the necessary background details for this interaction.
Note: for simplicity For simplicity, we are not re-setting resetting record numbers in this
diagram, so "Record 1" is really "Epoch 2, Record 0, etc.".</t> 0", etc.
</t>
      <figure anchor="dtls-msg-loss">
        <name>Example DTLS exchange illustrating message loss</name> Exchange Illustrating Message Loss</name>
        <artwork name="" type="" type="ascii-art" align="left" alt=""><![CDATA[
Client                                                Server
------                                                ------

 Record 0                  -------->
 ClientHello
 (message_seq=0)

                             X<-----                 Record 0
                             (lost)               ServerHello
                                              (message_seq=0)
                                                     Record 1
                                          EncryptedExtensions
                                              (message_seq=1)
                                                  Certificate
                                              (message_seq=2)

                           <--------                 Record 2
                                            CertificateVerify
                                              (message_seq=3)
                                                     Finished
                                              (message_seq=4)

 Record 1                  -------->
 ACK []

                           <--------                 Record 3
                                                  ServerHello
                                              (message_seq=0)
                                          EncryptedExtensions
                                              (message_seq=1)
                                                  Certificate
                                              (message_seq=2)

                           <--------                 Record 4
                                            CertificateVerify
                                              (message_seq=3)
                                                     Finished
                                              (message_seq=4)

 Record 2                  -------->
 Certificate
 (message_seq=1)
 CertificateVerify
 (message_seq=2)
 Finished
 (message_seq=3)

                           <--------               Record 5
                                                    ACK [2]
]]></artwork>
      </figure>
      <section anchor="dtls-epoch" numbered="true" toc="default">
        <name>Epoch Values and Rekeying</name>
        <t>A recipient of a DTLS message needs to select the correct keying material
in order to process an incoming message. With the possibility of message
 loss and re-ordering, reordering, an identifier is needed to determine which cipher state
has been used to protect the record payload. The epoch value fulfills this
role in DTLS. In addition to the TLS 1.3-defined key derivation steps, see
Section 7 of steps (see
<xref target="TLS13" format="default"/>, target="RFC8446" sectionFormat="of" section="7"/>), a sender may want to rekey at any time during
the lifetime of the connection. It therefore needs to indicate that it is
updating its sending cryptographic keys.</t>
        <t>This version of DTLS assigns dedicated epoch values to messages in the
protocol exchange to allow identification of the correct cipher state:</t>
        <ul spacing="normal">
          <li>epoch
          <li>Epoch value (0) is used with unencrypted messages. There are
three unencrypted messages in DTLS, namely ClientHello, ServerHello,
and HelloRetryRequest.</li>
          <li>epoch
          <li>Epoch value (1) is used for messages protected using keys derived
from client_early_traffic_secret. Note that this epoch is skipped if
the client does not offer early data.</li>
          <li>epoch
          <li>Epoch value (2) is used for messages protected using keys derived
from [sender]_handshake_traffic_secret. Messages transmitted during
the initial handshake, such as EncryptedExtensions,
CertificateRequest, Certificate, CertificateVerify, and Finished Finished,
belong to this category. Note, however, that post-handshake messages are
protected under the appropriate application traffic key and are not included in this category.</li>
          <li>epoch
          <li>Epoch value (3) is used for payloads protected using keys derived
from the initial [sender]_application_traffic_secret_0. This may include
handshake messages, such as post-handshake messages (e.g., a
NewSessionTicket message).</li>
          <li>epoch value
          <li>Epoch values (4 to 2^16-1) is 2^64-1) are used for payloads protected using keys from
the [sender]_application_traffic_secret_N (N&gt;0).</li>
        </ul>
        <t>Using these reserved epoch values values, a receiver knows what cipher state
has been used to encrypt and integrity protect a
message. Implementations that receive a record with an epoch value
for which no corresponding cipher state can be determined SHOULD <bcp14>SHOULD</bcp14>
handle it as a record which fails deprotection.</t>
        <t>Note that epoch values do not wrap. If a DTLS implementation would
need to wrap the epoch value, it MUST <bcp14>MUST</bcp14> terminate the connection.</t>
        <t>The traffic key calculation is described in Section 7.3 of <xref target="TLS13" format="default"/>.</t> target="RFC8446" sectionFormat="of" section="7.3"/>.</t>
        <t><xref target="dtls-msg-epoch" format="default"/> illustrates the epoch values in an example DTLS handshake.</t>
        <figure anchor="dtls-msg-epoch">
          <name>Example DTLS exchange Exchange with epoch information</name> Epoch Information</name>
          <artwork name="" type="" type="ascii-art" align="left" alt=""><![CDATA[
Client                                             Server
------                                             ------

 Record 0
 ClientHello
 (epoch=0)
                            -------->
                                                     Record 0
                            <--------       HelloRetryRequest
                                                    (epoch=0)
 Record 1
 ClientHello                -------->
 (epoch=0)
                                                     Record 1
                            <--------             ServerHello
                                                    (epoch=0)
                                        {EncryptedExtensions}
                                                    (epoch=2)
                                                {Certificate}
                                                    (epoch=2)
                                          {CertificateVerify}
                                                    (epoch=2)
                                                   {Finished}
                                                    (epoch=2)
 Record 2
 {Certificate}              -------->
 (epoch=2)
 {CertificateVerify}
 (epoch=2)
 {Finished}
 (epoch=2)
                                                     Record 2
                            <--------                   [ACK]
                                                    (epoch=3)
 Record 3
 [Application Data]         -------->
 (epoch=3)
                                                     Record 3
                            <--------      [Application Data]
                                                    (epoch=3)

                         Some time later ...
                 (Post-Handshake Message Exchange)
                                                     Record 4
                            <--------      [NewSessionTicket]
                                                    (epoch=3)
 Record 4
 [ACK]                      -------->
 (epoch=3)

                         Some time later ...
                           (Rekeying)
                                                     Record 5
                            <--------      [Application Data]
                                                    (epoch=4)
 Record 5
 [Application Data]         -------->
 (epoch=4)
]]></artwork>
        </figure>
      </section>
    </section>
    <section anchor="ack-msg" numbered="true" toc="default">
      <name>ACK Message</name>
      <t>The ACK message is used by an endpoint to indicate which handshake records
it has received and processed from the other side. ACK is not
a handshake message but is rather a separate content type,
with code point TBD (proposed, 25). 26. This avoids having ACK being added
to the handshake transcript. Note that ACKs can still be
sent in the same UDP datagram as handshake records.</t>
      <artwork
<sourcecode name="" type="" align="left" alt=""><![CDATA[ type="tls-presentation"><![CDATA[
    struct {
        RecordNumber record_numbers<0..2^16-1>;
    } ACK;
]]></artwork>
]]></sourcecode>

      <dl newline="false" spacing="normal">
        <dt>record_numbers:</dt>
        <dd>
  a
  A list of the records containing handshake messages in the current
flight which the endpoint has received and either processed or buffered,
in numerically increasing
order.</dd>
      </dl>
      <t>Implementations MUST NOT <bcp14>MUST NOT</bcp14> acknowledge records containing
handshake messages or fragments which have not been
processed or buffered. Otherwise, deadlock can ensue.
As an example, implementations MUST NOT <bcp14>MUST NOT</bcp14> send ACKs for
handshake messages which they discard because they are
not the next expected message.</t>
      <t>During the handshake, ACKs only cover the current outstanding flight (this is
possible because DTLS is generally a lockstep lock-step protocol). In particular,
receiving a message from a handshake flight implicitly acknowledges all
messages from the previous flight(s).  Accordingly, an ACK
from the server would not cover both the ClientHello and the client's
Certificate, Certificate message, because the ClientHello and client Certificate are in different
flights. Implementations can accomplish this by clearing their ACK
list upon receiving the start of the next flight.</t>
      <t>After the handshake,
      <t>For post-handshake messages, ACKs SHOULD <bcp14>SHOULD</bcp14> be sent once for each received
and processed handshake record (potentially subject to some delay) and MAY <bcp14>MAY</bcp14>
cover more than one flight. This includes records containing messages which are
discarded because a previous copy has been received.</t>
      <t>During the handshake, ACK records MUST <bcp14>MUST</bcp14> be sent with an epoch that which is
equal to or higher than the record which is being acknowledged.
Note that some care is required when processing flights spanning
multiple epochs. For instance, if the client receives only the Server Hello ServerHello
and Certificate and wishes to ACK them in a single record,
it must do so in epoch 2, as it is required to use an epoch
greater than or equal to 2 and cannot yet send with any greater
epoch. Implementations SHOULD <bcp14>SHOULD</bcp14> simply use the highest
current sending epoch, which will generally be the highest available.
After the handshake, implementations MUST <bcp14>MUST</bcp14> use the highest available
sending epoch.</t>
      <section anchor="sending-acks" numbered="true" toc="default">
        <name>Sending ACKs</name>
        <t>When an implementation detects a disruption in the receipt of the
current incoming flight, it SHOULD <bcp14>SHOULD</bcp14> generate an ACK that covers the
messages from that flight which it has received and processed so far.
Implementations have some discretion about which events to treat
as signs of disruption, but it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that they generate
ACKs under two circumstances:</t>
        <ul spacing="normal">
          <li>When they receive a message or fragment which is out of order,
either because it is not the next expected message or because
it is not the next piece of the current message.</li>
          <li>When they have received part of a flight and do not immediately
receive the rest of the flight (which may be in the same UDP
datagram). "Immediately" is hard to define. One approach is to
set a timer for 1/4 the current retransmit timer value when
the first record in the flight is received and then send an
ACK when that timer expires. Note: the The 1/4 value here is somewhat
arbitrary. Given that the round trip estimates in the DTLS
handshake are generally very rough (or the default), any
value will be an approximation, and there is an inherent
compromise due to competition between retransmision retransmission due to over-agressive over-aggressive ACKing
and over-aggressive timeout-based retransmission.
As a comparison point,
QUIC's loss-based recovery algorithms
(<xref target="I-D.ietf-quic-recovery" format="default"/>; Section 6.1.2) target="RFC9002" sectionFormat="comma" section="6.1.2"/>)
work out to a delay of about 1/3 of the retransmit timer.</li>
        </ul>
        <t>In general, flights MUST <bcp14>MUST</bcp14> be ACKed unless they are implicitly
acknowledged. In the present specification specification, the following flights are implicitly acknowledged
by the receipt of the next flight, which generally immediately follows the flight,</t> flight:</t>
        <ol spacing="normal" type="1"><li>Handshake flights other than the client's final flight of the
main handshake.</li>
          <li>The server's post-handshake CertificateRequest.</li>
        </ol>
        <t>ACKs SHOULD NOT <bcp14>SHOULD NOT</bcp14> be sent for these flights unless
        the responding flight cannot be generated immediately.
        All other flights <bcp14>MUST</bcp14> be ACKed.
In this case,
implementations MAY <bcp14>MAY</bcp14> send explicit ACKs for the complete received
flight even though it will eventually also be implicitly acknowledged
through the responding flight. A notable example for this is
the case of client authentication in constrained
environments, where generating the CertificateVerify message can
take considerable time on the client. All other flights MUST be ACKed.
Implementations MAY <bcp14>MAY</bcp14> acknowledge the records corresponding to each transmission of
each flight or simply acknowledge the most recent one. In general,
implementations SHOULD <bcp14>SHOULD</bcp14> ACK as many received packets as can fit
into the ACK record, as this provides the most complete information
and thus reduces the chance of spurious retransmission; if space
is limited, implementations SHOULD <bcp14>SHOULD</bcp14> favor including records which
have not yet been acknowledged.</t>
        <t>Note:
        <t indent="3">Note: While some post-handshake messages follow a request/response
pattern, this does not necessarily imply receipt.
For example, a KeyUpdate sent in response to a KeyUpdate with
request_update set to 'update_requested' "update_requested" does not implicitly
acknowledge the earlier KeyUpdate message because the two KeyUpdate
messages might have crossed in flight.</t>
        <t>ACKs MUST NOT <bcp14>MUST NOT</bcp14> be sent for other records of any content type
other than handshake or for records which cannot be unprotected.</t> deprotected.
</t>
        <t>Note that in some cases it may be necessary to send an ACK which
does not contain any record numbers. For instance, a client
might receive an EncryptedExtensions message prior to receiving
a ServerHello. Because it cannot decrypt the EncryptedExtensions,
it cannot safely acknowledge it (as it might be damaged). If the client
does not send an ACK, the server will eventually retransmit
its first flight, but this might take far longer than the
actual round trip time between client and server. Having
the client send an empty ACK shortcuts this process.</t>
      </section>
      <section anchor="receiving-acks" numbered="true" toc="default">
        <name>Receiving ACKs</name>
        <t>When an implementation receives an ACK, it SHOULD <bcp14>SHOULD</bcp14> record that the
messages or message fragments sent in the records being
ACKed were received and omit them from any future
retransmissions. Upon receipt of an ACK that leaves it with
only some messages from a flight having been acknowledged acknowledged,
an implementation SHOULD <bcp14>SHOULD</bcp14> retransmit the unacknowledged
messages or fragments. Note that this requires implementations to
track which messages appear in which records. Once all the messages in a flight have been
acknowledged, the implementation MUST <bcp14>MUST</bcp14> cancel all retransmissions
of that flight.
Implementations MUST <bcp14>MUST</bcp14> treat a record
as having been acknowledged if it appears in any ACK; this
prevents spurious retransmission in cases where a flight is
very large and the receiver is forced to elide acknowledgements
for records which have already been ACKed.
As noted above, the receipt of any record responding
to a given flight MUST <bcp14>MUST</bcp14> be taken as an implicit acknowledgement for the entire
flight to which it is responding.</t>
      </section>
      <section anchor="design-rationale" numbered="true" toc="default">
        <name>Design Rationale</name>
        <t>ACK messages are used in two circumstances, namely :</t> namely:</t>
        <ul spacing="normal">
          <li>on
          <li>On sign of disruption, or lack of progress, progress; and</li>
          <li>to
          <li>To indicate complete receipt of the last flight in a handshake.</li>
        </ul>
        <t>In the first case case, the use of the ACK message is optional optional, because
 the peer will retransmit in any case and therefore the ACK just
 allows for selective or early retransmission, as opposed to the
 timeout-based whole flight retransmission in previous
 versions of DTLS.
 When DTLS 1.3 is used in deployments
with lossy networks, such as low-power, long range long-range radio networks as well as
low-power mesh networks, the use of ACKs is recommended.</t>
        <t>The use of the ACK for the second case is mandatory for the proper functioning of the
protocol. For instance, the ACK message sent by the client in Figure 13, <xref target="dtls-msg-epoch"/>
acknowledges receipt and processing of record Record 4 (containing the NewSessionTicket
message)
message), and if it is not sent sent, the server will continue retransmission
of the NewSessionTicket indefinitely until its maximum retransmission count is reached.</t>
      </section>
    </section>
    <section anchor="key-updates" numbered="true" toc="default">
      <name>Key Updates</name>
      <t>As with TLS 1.3, DTLS 1.3 implementations send a KeyUpdate message to
indicate that they are updating their sending keys.  As with other
handshake messages with no built-in response, KeyUpdates MUST <bcp14>MUST</bcp14> be
acknowledged.  In order to facilitate epoch reconstruction
<xref
(<xref target="reconstructing" format="default"/> format="default"/>), implementations MUST NOT <bcp14>MUST NOT</bcp14> send records with the new keys or
send a new KeyUpdate until the previous KeyUpdate has been
acknowledged (this avoids having too many epochs in active use).</t>
      <t>Due to loss and/or re-ordering, reordering, DTLS 1.3 implementations
may receive a record with an older epoch than the
current one (the requirements above preclude receiving
a newer record). They SHOULD <bcp14>SHOULD</bcp14> attempt to process those records
with that epoch (see <xref target="reconstructing" format="default"/> for information
on determining the correct epoch), epoch) but MAY <bcp14>MAY</bcp14> opt to discard
such out-of-epoch records.</t>
      <t>Due to the possibility of an ACK message for a KeyUpdate being lost and thereby
preventing the sender of the KeyUpdate from updating its keying material,
receivers MUST <bcp14>MUST</bcp14> retain the pre-update keying material until receipt and successful
decryption of a message using the new keys.</t>
      <t><xref target="dtls-key-update" format="default"/> shows an example exchange illustrating that a successful
ACK processing updates the keys of the KeyUpdate message sender, which is
reflected in the change of epoch values.</t>
      <figure anchor="dtls-key-update">
        <name>Example DTLS Key Update</name>
        <artwork name="" type="" type="ascii-art" align="left" alt=""><![CDATA[
Client                                             Server

      /-------------------------------------------\
     |                                             |
     |             Initial Handshake               |
      \-------------------------------------------/

 [Application Data]         -------->
 (epoch=3)

                            <--------      [Application Data]
                                                    (epoch=3)

      /-------------------------------------------\
     |                                             |
     |              Some time later ...            |
      \-------------------------------------------/

 [Application Data]         -------->
 (epoch=3)

 [KeyUpdate]
 (+ update_requested        -------->
 (epoch 3)

                            <--------      [Application Data]
                                                    (epoch=3)

                                                        [Ack]

                                                        [ACK]
                            <--------               (epoch=3)

 [Application Data]
 (epoch=4)                  -------->

                            <--------             [KeyUpdate]
                                                    (epoch=3)

 [Ack]

 [ACK]                      -------->
 (epoch=4)

                            <--------      [Application Data]
                                                    (epoch=4)
]]></artwork>
      </figure>
      <t>
With a 128-bit key as in AES-128, rekeying 2^64 times has a high
probability of key reuse within a given connection. Note that even if
the key repeats, the IV is also independently generated. In order to
provide an extra margin of security, sending implementations <bcp14>MUST NOT</bcp14>
allow the epoch to exceed 2^48-1. In order to allow this value to
be changed later, receiving implementations <bcp14>MUST NOT</bcp14>
enforce this rule. If a sending implementation receives a KeyUpdate
with request_update set to "update_requested", it <bcp14>MUST NOT</bcp14> send
its own KeyUpdate if that would cause it to exceed these limits
and <bcp14>SHOULD</bcp14> instead ignore the "update_requested" flag.
Note: this overrides the requirement in TLS 1.3 to always
send a KeyUpdate in response to "update_requested".
      </t>
    </section>
    <section anchor="connection-id-updates" numbered="true" toc="default">
      <name>Connection ID Updates</name>
      <t>If the client and server have negotiated the "connection_id"
extension <xref target="I-D.ietf-tls-dtls-connection-id" target="RFC9146" format="default"/>, either side
can send a new CID which that it wishes the other side to use
in a NewConnectionId message.</t>
      <artwork
<sourcecode name="" type="" align="left" alt=""><![CDATA[ type="tls-presentation"><![CDATA[
    enum {
        cid_immediate(0), cid_spare(1), (255)
    } ConnectionIdUsage;

    opaque ConnectionId<0..2^8-1>;

    struct {
        ConnectionIds
        ConnectionId cids<0..2^16-1>;
        ConnectionIdUsage usage;
    } NewConnectionId;
]]></artwork>
]]></sourcecode>
      <dl newline="false" spacing="normal">
        <dt>cid</dt>
        <dt>cids:</dt>
        <dd>
  Indicates the set of CIDs which that the sender wishes the peer to use.</dd>
        <dt>usage</dt>
        <dt>usage:</dt>
        <dd>
  Indicates whether the new CIDs should be used immediately or are
spare.  If usage is set to "cid_immediate", then one of the new CID
MUST CIDs
<bcp14>MUST</bcp14> be used immediately for all future records. If it is set to
"cid_spare", then either an existing or new CID MAY <bcp14>MAY</bcp14> be used.</dd>
      </dl>
      <t>Endpoints SHOULD <bcp14>SHOULD</bcp14> use receiver-provided CIDs in the order they were provided.
Implementations which receive more spare CIDs than they wish to maintain
MAY
<bcp14>MAY</bcp14> simply discard any extra CIDs.
Endpoints MUST NOT <bcp14>MUST NOT</bcp14> have more than one NewConnectionId message outstanding.</t>
      <t>Implementations which either did not negotiate the "connection_id" extension
or which have negotiated receiving an empty CID MUST NOT <bcp14>MUST NOT</bcp14>
send NewConnectionId. Implementations MUST NOT <bcp14>MUST NOT</bcp14> send RequestConnectionId
when sending an empty Connection ID. Implementations which detect a violation
of these rules MUST <bcp14>MUST</bcp14> terminate the connection with an "unexpected_message"
alert.</t>
      <t>Implementations SHOULD <bcp14>SHOULD</bcp14> use a new CID whenever sending on a new path, path
and SHOULD <bcp14>SHOULD</bcp14> request new CIDs for this purpose if path changes are anticipated.</t>
      <artwork
<sourcecode name="" type="" align="left" alt=""><![CDATA[ type="tls-presentation"><![CDATA[
    struct {
      uint8 num_cids;
    } RequestConnectionId;
]]></artwork>
]]></sourcecode>
      <dl newline="false" spacing="normal">
        <dt>num_cids</dt>
        <dt>num_cids:</dt>
        <dd>
  The number of CIDs desired.</dd>
      </dl>
      <t>Endpoints SHOULD <bcp14>SHOULD</bcp14> respond to RequestConnectionId by sending a
NewConnectionId with usage "cid_spare" containing num_cid num_cids CIDs as soon as
possible.  Endpoints MUST NOT <bcp14>MUST NOT</bcp14> send a RequestConnectionId message
when an existing request is still unfulfilled; this implies that
endpoints needs need to request new CIDs well in advance.  An endpoint MAY <bcp14>MAY</bcp14>
handle requests, requests which it considers excessive, excessive by responding with
a NewConnectionId message containing fewer than num_cid num_cids CIDs,
including no CIDs at all. Endpoints MAY <bcp14>MAY</bcp14> handle an excessive number
of RequestConnectionId messages by terminating the connection
using a "too_many_cids_requested" (alert number 52) alert.</t>
      <t>Endpoints MUST NOT <bcp14>MUST NOT</bcp14> send either of these messages if they did not negotiate a
CID. If an implementation receives these messages when CIDs
were not negotiated, it MUST <bcp14>MUST</bcp14> abort the connection with an unexpected_message "unexpected_message"
alert.</t>
      <section anchor="connection-id-example" numbered="true" toc="default">
        <name>Connection ID Example</name>
        <t>Below is an example exchange for DTLS 1.3 using a single
CID in each direction.</t>
        <t>Note:
        <t indent="3">Note: The connection_id extension is defined in
<xref target="I-D.ietf-tls-dtls-connection-id" format="default"/>, "connection_id" extension, which is used in ClientHello and ServerHello messages.</t> messages, is defined in
<xref target="RFC9146" format="default"/>.</t>
        <figure anchor="dtls-example">
          <name>Example DTLS 1.3 Exchange with CIDs</name>
          <artwork name="" type="" type="ascii-art" align="left" alt=""><![CDATA[
Client                                             Server
------                                             ------

ClientHello
(connection_id=5)
                            -------->

                            <--------       HelloRetryRequest
                                                     (cookie)

ClientHello                 -------->
(connection_id=5)
  +cookie
  + cookie

                            <--------             ServerHello
                                          (connection_id=100)
                                          EncryptedExtensions
                                                      (cid=5)
                                                  Certificate
                                                      (cid=5)
                                            CertificateVerify
                                                      (cid=5)
                                                     Finished
                                                      (cid=5)

Certificate                -------->
(cid=100)
CertificateVerify
(cid=100)
Finished
(cid=100)
                           <--------                      Ack                      ACK
                                                      (cid=5)

Application Data           ========>
(cid=100)
                           <========         Application Data
                                                      (cid=5)
]]></artwork>
        </figure>
        <t>If no CID is negotiated, then the receiver MUST <bcp14>MUST</bcp14> reject any
records it receives that contain a CID.</t>
      </section>
    </section>
    <section anchor="application-data-protocol" numbered="true" toc="default">
      <name>Application Data Protocol</name>
      <t>Application data messages are carried by the record layer and are split
into records
and encrypted based on the current connection state. The messages
are treated as transparent data to the record layer.</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Security issues are discussed primarily in <xref target="TLS13" target="RFC8446" format="default"/>.</t>
      <t>The primary additional security consideration raised by DTLS is that
of denial of service by excessive resource consumption.  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 <bcp14>SHOULD</bcp14> use the cookie
exchange unless there is good reason to believe that amplification is
not a threat in their environment.  Clients MUST <bcp14>MUST</bcp14> be prepared to do a
cookie exchange with every handshake.</t>
      <t>Some key properties required of the cookie for the cookie-exchange mechanism
to be functional are described in Section 3.3 of <xref target="RFC2522" format="default"/>:</t> sectionFormat="of" section="3.3"/>:</t>
      <ul spacing="normal">
        <li>the
        <li>The cookie MUST <bcp14>MUST</bcp14> depend on the client's address.</li>
        <li>it MUST NOT
        <li>It <bcp14>MUST NOT</bcp14> be possible for anyone other than the issuing entity to generate
cookies that are accepted as valid by that entity.  This typically entails
an integrity check based on a secret key.</li>
        <li>cookie
        <li>Cookie generation and verification are triggered by unauthenticated parties,
and as such their resource consumption needs to be restrained in order to
avoid having the cookie-exchange mechanism itself serve as a DoS vector.</li>
      </ul>
      <t>Although the cookie must allow the server to produce the right handshake
transcript, it SHOULD <bcp14>SHOULD</bcp14> be constructed so that knowledge of the cookie
is insufficient to reproduce the ClientHello contents. Otherwise,
this may create problems with future extensions such as Encrypted Client Hello <xref target="I-D.ietf-tls-esni" target="TLS-ECH" format="default"/>.</t>
      <t>When cookies are generated using a keyed authentication mechanism mechanism,
it should be possible to rotate the associated
secret key, so that temporary compromise of the key does not permanently
compromise the integrity of the cookie-exchange mechanism.  Though this secret
is not as high-value as, e.g., a session-ticket-encryption key, rotating the
cookie-generation key on a similar timescale would ensure that the
key-rotation
key rotation functionality is exercised regularly and thus in working order.</t>
      <t>The cookie exchange provides address validation during the initial handshake.
DTLS with Connection IDs allows for endpoint addresses to change during the
association; any such updated addresses are not covered by the cookie exchange
during the handshake.
DTLS implementations MUST NOT <bcp14>MUST NOT</bcp14> update the address they send to in response
to packets from a different address unless they first perform some
reachability test; no such test is defined in this specification. specification
and a future specification would need to specify a complete procedure for
how and when to update addresses. Even
with such a test, an active on-path adversary can also black-hole traffic or
create a reflection attack against third parties because a DTLS peer
has no means to distinguish a genuine address update event (for
example, due to a NAT rebinding) from one that is malicious. This
attack is of concern when there is a large asymmetry of
request/response message sizes.</t>
      <t>With the exception of order protection and non-replayability, the security
guarantees for DTLS 1.3 are the same as TLS 1.3. While TLS always provides
order protection and non-replayability, DTLS does not provide order protection
and may not provide replay protection.</t>
      <t>Unlike TLS implementations, DTLS implementations SHOULD NOT <bcp14>SHOULD NOT</bcp14> respond
to invalid records by terminating the connection.</t>
      <t>TLS 1.3 requires replay protection for 0-RTT data (or rather, for connections
that use 0-RTT data; see Section 8 of <xref target="TLS13" format="default"/>). target="RFC8446" sectionFormat="of" section="8"/>).  DTLS provides an optional
per-record replay-protection mechanism, since datagram protocols are
inherently subject to message reordering and replay.  These two
replay-protection mechanisms are orthogonal, and neither mechanism meets the
      requirements for the other.</t>
      <t>
        DTLS 1.3's handshake transcript does not include the new DTLS fields,
which makes it have the same format as TLS 1.3. However, the DTLS 1.3 and
TLS 1.3 transcripts are disjoint because they use different version
numbers. Additionally, the DTLS 1.3 key schedule uses a different label
and so will produce different keys for the same transcript.
      </t>
      <t>The security and privacy properties of the CID for DTLS 1.3 builds build
on top of what is described for DTLS 1.2 in <xref target="I-D.ietf-tls-dtls-connection-id" target="RFC9146" format="default"/>. There are,
however, several differences:</t>
      <ul spacing="normal">
        <li>In both versions of DTLS DTLS, extension negotiation is used to agree on the use of the CID
feature and the CID values. In both versions versions, the CID is carried in the DTLS record header (if negotiated).
However, the way the CID is included in the record header differs between the two versions.</li>
        <li>The use of the Post-Handshake post-handshake message allows the client and the server
to update their CIDs CIDs, and those values are exchanged with confidentiality
protection.</li>
        <li>The ability to use multiple CIDs allows for improved privacy properties
in multi-homed multihomed scenarios. When only a single CID is in use on multiple
paths from such a host, an adversary can correlate the communication
interaction across paths, which adds further privacy concerns. In order
to prevent this, implementations SHOULD <bcp14>SHOULD</bcp14> attempt to use fresh CIDs
whenever they change local addresses or ports (though this is not always
possible to detect). The RequestConnectionId message can be used by a peer
to ask for new CIDs to ensure that a pool of suitable CIDs is available.</li>
        <li>The mechanism for encrypting sequence numbers (<xref target="rne" format="default"/>) prevents
trivial tracking by on-path adversaries that attempt to correlate the
pattern of sequence numbers received on different paths; such tracking
could occur even when different CIDs are used on each path, in the
absence of sequence number encryption. Switching CIDs based on certain
events, or even regularly, helps against tracking by on-path
adversaries.  Note that sequence number encryption is used for all
encrypted DTLS 1.3 records irrespective of whether a CID is used or
not.  Unlike the sequence number, the epoch is not encrypted because it acts as a key identifier, which
may improve correlation of packets from a single connection across
different network paths.</li>
        <li>DTLS 1.3 encrypts handshake messages much earlier than in previous
DTLS versions. Therefore, less information identifying the DTLS client, such as
the client certificate, is available to an on-path adversary.</li>
      </ul>
    </section>
    <section anchor="changes-since-dtls-12" numbered="true" toc="default">
      <name>Changes since DTLS 1.2</name>
      <t>Since TLS 1.3 introduces a large number of changes with respect to TLS 1.2, the list
of changes from DTLS 1.2 to DTLS 1.3 is equally large. For this reason reason,
this section focuses on the most important changes only.</t>
      <ul spacing="normal">
        <li>New handshake pattern, which leads to a shorter message exchange</li> exchange.</li>
        <li>Only AEAD ciphers are supported. Additional data calculation has been simplified.</li>
        <li>Removed support for weaker and older cryptographic algorithms</li> algorithms.</li>
        <li>HelloRetryRequest of TLS 1.3 used instead of HelloVerifyRequest</li> HelloVerifyRequest.</li>
        <li>More flexible ciphersuite negotiation</li> cipher suite negotiation.</li>
        <li>New session resumption mechanism</li> mechanism.</li>
        <li>PSK authentication redefined</li> redefined.</li>
        <li>New key derivation hierarchy utilizing a new key derivation construct</li> construct.</li>
        <li>Improved version negotiation</li> negotiation.</li>
        <li>Optimized record layer encoding and thereby its size</li> size.</li>
        <li>Added CID functionality</li> functionality.</li>
        <li>Sequence numbers are encrypted.</li>
      </ul>
    </section>
    <section anchor="updates-affecting-dtls-12" numbered="true" toc="default">
      <name>Updates affecting Affecting DTLS 1.2</name>
      <t>This document defines several changes that optionally affect
implementations of DTLS 1.2, including those which do not also support
DTLS 1.3.</t>
      <ul spacing="normal">
        <li>A version downgrade protection mechanism as described
in <xref target="TLS13" format="default"/>; Section 4.1.3 target="RFC8446" sectionFormat="comma" section="4.1.3"/> and applying to DTLS as
described in <xref target="clienthello-message" format="default"/>.</li>
        <li>The updates described in <xref target="TLS13" format="default"/>; Section 3.</li> target="RFC8446" sectionFormat="comma" section="1.3"/>.</li>
        <li>The new compliance requirements described in <xref target="TLS13" format="default"/>; Section 9.3.</li> target="RFC8446" sectionFormat="comma" section="9.3"/>.</li>
      </ul>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA is requested to allocate a new has allocated the content type value 26 in the "TLS ContentType"
registry for the ACK message, defined in <xref target="ack-msg" format="default"/>, with content type 26. format="default"/>.
The value for the "DTLS-OK" column is "Y".  IANA is requested to reserve has reserved
the content type range 32-63 so that content types in this range are not
allocated.</t>
      <t>IANA is requested to allocate "the too_many_cids_requested" has allocated value 52 for the "too_many_cids_requested" alert in
the "TLS Alerts" registry with registry. The value 52.</t>
      <t>IANA for the "DTLS-OK" column is requested "Y".

<!-- 9/1/2021  Lynne to allocate ask IANA to change "the too_many_cids_requested" to
"too_many_cids_requested" on <https://www.iana.org/assignments/tls-parameters/>
just prior to publication. -->
</t>
      <t>IANA has allocated two values in the "TLS Handshake Type" HandshakeType"
registry, defined in <xref target="TLS13" target="RFC8446" format="default"/>, for RequestConnectionId (TBD), request_connection_id (9) and
NewConnectionId (TBD),
new_connection_id (10), as defined in this document.  The value for the
"DTLS-OK" columns are column is "Y".</t>
      <t>IANA is requested to add has added this RFC as a reference to the TLS "TLS Cipher Suite Registry Suites" registry
along with the following Note:</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
<blockquote>
Any TLS cipher suite that is specified for use with DTLS MUST <bcp14>MUST</bcp14>
define limits on the use of the associated AEAD function that
preserves margins for both confidentiality and integrity,
as specified in [THIS RFC; Section TODO]
]]></artwork> <xref target="aead-limits"/> of RFC 9147.
</blockquote>
    </section>
  </middle>
  <back>

<displayreference target="RFC8446" to="TLS13"/>
<displayreference target="RFC8439" to="CHACHA"/>
<displayreference target="RFC8996" to="DEPRECATE"/>
<displayreference target="I-D.ietf-uta-tls13-iot-profile" to="IOT-PROFILE"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC0768" target="https://www.rfc-editor.org/info/rfc768">
          <front>
            <title>User Datagram Protocol</title>
            <author initials="J." surname="Postel" fullname="J. Postel">
              <organization/>
            </author>
            <date year="1980" month="August"/>
          </front>
          <seriesInfo name="STD" value="6"/>
          <seriesInfo name="RFC" value="768"/>
          <seriesInfo name="DOI" value="10.17487/RFC0768"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC1191" target="https://www.rfc-editor.org/info/rfc1191">
          <front>
            <title>Path MTU discovery</title>
            <author initials="J.C." surname="Mogul" fullname="J.C. Mogul">
              <organization/>
            </author>
            <author initials="S.E." surname="Deering" fullname="S.E. Deering">
              <organization/>
            </author>
            <date year="1990" month="November"/>
            <abstract>
              <t>This memo describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path.  It specifies a small change to the way routers generate one type of ICMP message.  For a path that passes through a router that has not been so changed, this technique might not discover the correct Path MTU, but it will always choose a Path MTU as accurate as, and in many cases more accurate than, the Path MTU that would be chosen by current practice.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1191"/>
          <seriesInfo name="DOI" value="10.17487/RFC1191"/>
        </reference>
        <reference anchor="RFC4443" target="https://www.rfc-editor.org/info/rfc4443">
          <front>
            <title>Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification</title>
            <author initials="A." surname="Conta" fullname="A. Conta">
              <organization/>
            </author>
            <author initials="S." surname="Deering" fullname="S. Deering">
              <organization/>
            </author>
            <author initials="M." surname="Gupta" fullname="M. Gupta" role="editor">
              <organization/>
            </author>
            <date year="2006" month="March"/>
            <abstract>
              <t>This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol).  ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6).  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="89"/>
          <seriesInfo name="RFC" value="4443"/>
          <seriesInfo name="DOI" value="10.17487/RFC4443"/>
        </reference>
        <reference anchor="RFC4821" target="https://www.rfc-editor.org/info/rfc4821">
          <front>
            <title>Packetization Layer Path MTU Discovery</title>
            <author initials="M." surname="Mathis" fullname="M. Mathis">
              <organization/>
            </author>
            <author initials="J." surname="Heffner" fullname="J. Heffner">
              <organization/>
            </author>
            <date year="2007" month="March"/>
            <abstract>
              <t>This document describes a robust method for Path MTU Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets.  This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6, respectively.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4821"/>
          <seriesInfo name="DOI" value="10.17487/RFC4821"/>
        </reference>
        <reference anchor="RFC0793" target="https://www.rfc-editor.org/info/rfc793">
          <front>
            <title>Transmission Control Protocol</title>
            <author initials="J." surname="Postel" fullname="J. Postel">
              <organization/>
            </author>
            <date year="1981" month="September"/>
          </front>
          <seriesInfo name="STD" value="7"/>
          <seriesInfo name="RFC" value="793"/>
          <seriesInfo name="DOI" value="10.17487/RFC0793"/>
        </reference>
        <reference anchor="RFC6298" target="https://www.rfc-editor.org/info/rfc6298">
          <front>
            <title>Computing TCP's Retransmission Timer</title>
            <author initials="V." surname="Paxson" fullname="V. Paxson">
              <organization/>
            </author>
            <author initials="M." surname="Allman" fullname="M. Allman">
              <organization/>
            </author>
            <author initials="J." surname="Chu" fullname="J. Chu">
              <organization/>
            </author>
            <author initials="M." surname="Sargent" fullname="M. Sargent">
              <organization/>
            </author>
            <date year="2011" month="June"/>
            <abstract>
              <t>This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer.  It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST.  This document obsoletes RFC 2988.   [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6298"/>
          <seriesInfo name="DOI" value="10.17487/RFC6298"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="I-D.ietf-tls-dtls-connection-id" target="https://www.ietf.org/internet-drafts/draft-ietf-tls-dtls-connection-id-11.txt">
          <front>
            <title>Connection Identifiers for DTLS 1.2</title>
            <author initials="E" surname="Rescorla" fullname="Eric Rescorla">
              <organization/>
            </author>
            <author initials="H" surname="Tschofenig" fullname="Hannes Tschofenig">
              <organization/>
            </author>
            <author initials="T" surname="Fossati" fullname="Thomas Fossati">
              <organization/>
            </author>
            <author initials="A" surname="Kraus" fullname="Achim Kraus">
              <organization/>
            </author>
            <date year="2021" month="April" day="14"/>
            <abstract>
              <t>This document specifies the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol version 1.2.</t>
              <t> A CID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association.  In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple.  If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session then the receiver will be unable to locate the correct security context.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-tls-dtls-connection-id-11"/>
        </reference>
        <reference anchor="TLS13" target="https://www.rfc-editor.org/info/rfc8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization/>
            </author>
            <date year="2018" month="August"/>
            <abstract>
              <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="CHACHA" target="https://www.rfc-editor.org/info/rfc8439">
          <front>
            <title>ChaCha20 and Poly1305 for IETF Protocols</title>
            <author initials="Y." surname="Nir" fullname="Y. Nir">
              <organization/>
            </author>
            <author initials="A." surname="Langley" fullname="A. Langley">
              <organization/>
            </author>
            <date year="2018" month="June"/>
            <abstract>
              <t>This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm.</t>
              <t>RFC 7539, the predecessor of this document, was meant to serve as a stable reference and an implementation guide.  It was a product of the Crypto Forum Research Group (CFRG).  This document merges the errata filed against RFC 7539 and adds a little text to the Security Considerations section.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8439"/>
          <seriesInfo name="DOI" value="10.17487/RFC8439"/>
        </reference>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0768.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1191.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4821.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0793.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6298.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8439.xml"/>

<!-- draft-ietf-tls-dtls-connection-id (RFC 9146) -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9146.xml"/>

      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC7296" target="https://www.rfc-editor.org/info/rfc7296">
          <front>
            <title>Internet Key Exchange Protocol Version 2 (IKEv2)</title>
            <author initials="C." surname="Kaufman" fullname="C. Kaufman">
              <organization/>
            </author>
            <author initials="P." surname="Hoffman" fullname="P. Hoffman">
              <organization/>
            </author>
            <author initials="Y." surname="Nir" fullname="Y. Nir">
              <organization/>
            </author>
            <author initials="P." surname="Eronen" fullname="P. Eronen">
              <organization/>
            </author>
            <author initials="T." surname="Kivinen" fullname="T. Kivinen">
              <organization/>
            </author>
            <date year="2014" month="October"/>
            <abstract>
              <t>This document describes version 2 of the Internet Key Exchange (IKE) protocol.  IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs).  This document obsoletes RFC 5996, and includes all of the errata for it.  It advances IKEv2 to be an Internet Standard.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="79"/>
          <seriesInfo name="RFC" value="7296"/>
          <seriesInfo name="DOI" value="10.17487/RFC7296"/>
        </reference>
        <reference anchor="RFC2522" target="https://www.rfc-editor.org/info/rfc2522">
          <front>
            <title>Photuris: Session-Key Management Protocol</title>
            <author initials="P." surname="Karn" fullname="P. Karn">
              <organization/>
            </author>
            <author initials="W." surname="Simpson" fullname="W. Simpson">
              <organization/>
            </author>
            <date year="1999" month="March"/>
            <abstract>
              <t>This document defines the basic protocol mechanisms. This document defines an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2522"/>
          <seriesInfo name="DOI" value="10.17487/RFC2522"/>
        </reference>
        <reference anchor="RFC4303" target="https://www.rfc-editor.org/info/rfc4303">
          <front>
            <title>IP Encapsulating Security Payload (ESP)</title>
            <author initials="S." surname="Kent" fullname="S. Kent">
              <organization/>
            </author>
            <date year="2005" month="December"/>
            <abstract>
              <t>This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6.  ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality.  This document obsoletes RFC 2406 (November 1998).  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4303"/>
          <seriesInfo name="DOI" value="10.17487/RFC4303"/>
        </reference>
        <reference anchor="RFC4340" target="https://www.rfc-editor.org/info/rfc4340">
          <front>
            <title>Datagram Congestion Control Protocol (DCCP)</title>
            <author initials="E." surname="Kohler" fullname="E. Kohler">
              <organization/>
            </author>
            <author initials="M." surname="Handley" fullname="M. Handley">
              <organization/>
            </author>
            <author initials="S." surname="Floyd" fullname="S. Floyd">
              <organization/>
            </author>
            <date year="2006" month="March"/>
            <abstract>
              <t>The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides bidirectional unicast connections of congestion-controlled unreliable datagrams.  DCCP is suitable for applications that transfer fairly large amounts of data and that can benefit from control over the tradeoff between timeliness and reliability.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4340"/>
          <seriesInfo name="DOI" value="10.17487/RFC4340"/>
        </reference>
        <reference anchor="RFC4346" target="https://www.rfc-editor.org/info/rfc4346">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.1</title>
            <author initials="T." surname="Dierks" fullname="T. Dierks">
              <organization/>
            </author>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization/>
            </author>
            <date year="2006" month="April"/>
            <abstract>
              <t>This document specifies Version 1.1 of the Transport Layer Security (TLS) protocol.  The TLS protocol provides communications security over the Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4346"/>
          <seriesInfo name="DOI" value="10.17487/RFC4346"/>
        </reference>
        <reference anchor="RFC4347" target="https://www.rfc-editor.org/info/rfc4347">
          <front>
            <title>Datagram Transport Layer Security</title>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization/>
            </author>
            <author initials="N." surname="Modadugu" fullname="N. Modadugu">
              <organization/>
            </author>
            <date year="2006" month="April"/>
            <abstract>
              <t>This document specifies Version 1.0 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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4347"/>
          <seriesInfo name="DOI" value="10.17487/RFC4347"/>
        </reference>
        <reference anchor="RFC5238" target="https://www.rfc-editor.org/info/rfc5238">
          <front>
            <title>Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)</title>
            <author initials="T." surname="Phelan" fullname="T. Phelan">
              <organization/>
            </author>
            <date year="2008" month="May"/>
            <abstract>
              <t>This document specifies the use of Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP).  DTLS provides communications privacy for applications that use datagram transport protocols and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery.  DCCP is a transport protocol that provides a congestion-controlled unreliable datagram service.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5238"/>
          <seriesInfo name="DOI" value="10.17487/RFC5238"/>
        </reference>
        <reference anchor="RFC5246" target="https://www.rfc-editor.org/info/rfc5246">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
            <author initials="T." surname="Dierks" fullname="T. Dierks">
              <organization/>
            </author>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization/>
            </author>
            <date year="2008" month="August"/>
            <abstract>
              <t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol.  The TLS protocol provides communications security over the Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5246"/>
          <seriesInfo name="DOI" value="10.17487/RFC5246"/>
        </reference>
        <reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc6347">
          <front>
            <title>Datagram Transport Layer Security Version 1.2</title>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization/>
            </author>
            <author initials="N." surname="Modadugu" fullname="N. Modadugu">
              <organization/>
            </author>
            <date year="2012" month="January"/>
            <abstract>
              <t>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.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6347"/>
          <seriesInfo name="DOI" value="10.17487/RFC6347"/>
        </reference>
        <reference anchor="RFC7525" target="https://www.rfc-editor.org/info/rfc7525">
          <front>
            <title>Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
            <author initials="Y." surname="Sheffer" fullname="Y. Sheffer">
              <organization/>
            </author>
            <author initials="R." surname="Holz" fullname="R. Holz">
              <organization/>
            </author>
            <author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre">
              <organization/>
            </author>
            <date year="2015" month="May"/>
            <abstract>
              <t>Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP.  Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation.  This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="195"/>
          <seriesInfo name="RFC" value="7525"/>
          <seriesInfo name="DOI" value="10.17487/RFC7525"/>
        </reference>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2522.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4340.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4346.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4347.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5238.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7525.xml"/>

<reference anchor="AEBounds" target="http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf"> target="https://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf">
          <front>
            <title>Limits on Authenticated Encryption Use in TLS</title>
            <author initials="A." surname="Luykx">
              <organization/>
            </author>
            <author initials="K." surname="Paterson">
              <organization/>
            </author>
            <date year="2016" month="March" day="08"/> year="2017" month="August" day="28"/>
          </front>
        </reference>

        <reference anchor="ROBUST" target="https://eprint.iacr.org/2020/718">
          <front>
            <title>Robust Channels: Handling Unreliable Networks in the Record Layers of QUIC and DTLS 1.3</title>
            <author initials="M." surname="Fischlin">
              <organization/>
            </author>
            <author initials="F." surname="Günther">
              <organization/>
            </author>
            <author initials="C." surname="Janson">
              <organization/>
            </author>
            <date year="2020" month="June" day="15"/>
            <date/>
          </front>
        <refcontent>received 15 June 2020, last revised 22 February 2021</refcontent>
        </reference>
        <reference anchor="DEPRECATE" target="http://www.ietf.org/internet-drafts/draft-ietf-tls-oldversions-deprecate-12.txt">
          <front>
            <title>Deprecating TLSv1.0 and TLSv1.1</title>
            <author initials="K" surname="Moriarty" fullname="Kathleen Moriarty">
              <organization/>
            </author>
            <author initials="S" surname="Farrell" fullname="Stephen Farrell">
              <organization/>
            </author>
            <date month="January" day="21" year="2021"/>
            <abstract>
              <t>This document, if approved, formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1

<!-- draft-ietf-tls-oldversions-deprecate (RFC 4346). Accordingly, those documents (will be moved|have been moved) to Historic status.  These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions.  TLSv1.2 became the recommended version for IETF protocols in 2008, (subsequently being obsoleted by TLSv1.3 in 2018), providing sufficient time to transition away from older versions.  Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance.  This document also deprecates Datagram TLS (DTLS) version 1.0 8996, pub. March 2021) -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8996.xml"/>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5763.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7983.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4960.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8201.xml"/>

<!-- draft-ietf-uta-tls13-iot-profile (I-D Exists) Checks OK 8/9/2021 -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-uta-tls13-iot-profile.xml"/>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5764.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8445.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7924.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8879.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/>

<!-- draft-ietf-quic-recovery (RFC 4347), but not DTLS version 1.2, and there is no DTLS version 1.1.  This document updates many RFCs that normatively refer to TLSv1.0 or TLSv1.1 as described herein.  This document also updates the best practices for TLS usage in RFC 7525 and hence is part of BCP 195.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-tls-oldversions-deprecate-12"/>
        </reference>
        <reference anchor="RFC5763" target="https://www.rfc-editor.org/info/rfc5763">
          <front>
            <title>Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)</title>
            <author initials="J." surname="Fischl" fullname="J. Fischl">
              <organization/>
            </author>
            <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
              <organization/>
            </author>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization/>
            </author>
            <date year="2010" month="May"/>
            <abstract>
              <t>This document specifies how 9002, pub. May 2021) -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9002.xml"/>

<!-- draft-ietf-tls-esni (I-D Exists) [LB]
    Have to use the Session Initiation Protocol (SIP) do "long way" to establish a Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol.  It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake.  The key exchange travels along the media path accommodate "C.A. Wood".
    Otherwise OK as opposed to the signaling path.  The SIP Identity mechanism can be used to protect the integrity of the fingerprint attribute from modification by intermediate proxies.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5763"/>
          <seriesInfo name="DOI" value="10.17487/RFC5763"/>
        </reference> 8/9/2021 -->
<reference anchor="RFC7983" target="https://www.rfc-editor.org/info/rfc7983"> anchor='TLS-ECH'>
<front>
            <title>Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)</title>
            <author initials="M." surname="Petit-Huguenin" fullname="M. Petit-Huguenin">
              <organization/>
            </author>
<title>TLS Encrypted Client Hello</title>
<author initials="G." surname="Salgueiro" fullname="G. Salgueiro">
              <organization/> initials='E' surname='Rescorla' fullname='Eric Rescorla'>
<organization />
</author>
<author initials='K' surname='Oku' fullname='Kazuho Oku'>
<organization />
</author>
<author initials='N' surname='Sullivan' fullname='Nick Sullivan'>
<organization />
</author>
<author initials='C.A.' surname='Wood' fullname='Christopher A. Wood'>
<organization />
</author>
<date year="2016" month="September"/>
            <abstract>
              <t>This document defines how Datagram Transport Layer Security (DTLS), Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP), Session Traversal Utilities for NAT (STUN), Traversal Using Relays around NAT (TURN), and ZRTP packets are multiplexed on a single receiving socket.  It overrides the guidance from RFC 5764 ("SRTP                Extension for DTLS"), which suffered from four issues described and fixed in this document.</t>
              <t>This document updates RFC 5764.</t>
            </abstract> year='2021' month='July' day='7' />
</front>
<seriesInfo name="RFC" value="7983"/>
          <seriesInfo name="DOI" value="10.17487/RFC7983"/> name='Internet-Draft' value='draft-ietf-tls-esni-11'/>
</reference>
        <reference anchor="RFC4960" target="https://www.rfc-editor.org/info/rfc4960">
          <front>
            <title>Stream Control Transmission Protocol</title>
            <author initials="R." surname="Stewart" fullname="R. Stewart" role="editor">
              <organization/>
            </author>
            <date year="2007" month="September"/>
            <abstract>
              <t>This document obsoletes RFC 2960 and RFC 3309.  It describes the Stream Control Transmission Protocol (SCTP).  SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications.</t>
              <t>SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP.  It offers the following services to its users:</t>
              <t>--  acknowledged error-free non-duplicated transfer of user data,</t>
              <t>--  data fragmentation to conform

<!-- draft-irtf-cfrg-aead-limits (I-D Exists)
   Had to discovered path MTU size,</t>
              <t>--  sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,</t>
              <t>--  optional bundling of multiple user messages into a single SCTP packet, and</t>
              <t>--  network-level fault tolerance through supporting of multi-homing at either or both ends of an association.</t>
              <t> The design of SCTP includes appropriate congestion avoidance behavior and resistance do "long way" to flooding and masquerade attacks.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4960"/>
          <seriesInfo name="DOI" value="10.17487/RFC4960"/>
        </reference>
        <reference anchor="RFC8201" target="https://www.rfc-editor.org/info/rfc8201">
          <front>
            <title>Path MTU Discovery for IP accommodate Günther, C.A. Wood, version 6</title>
            <author initials="J." surname="McCann" fullname="J. McCann">
              <organization/>
            </author>
            <author initials="S." surname="Deering" fullname="S. Deering">
              <organization/>
            </author>
            <author initials="J." surname="Mogul" fullname="J. Mogul">
              <organization/>
            </author>
            <author initials="R." surname="Hinden" fullname="R. Hinden" role="editor">
              <organization/>
            </author>
            <date year="2017" month="July"/>
            <abstract>
              <t>This document describes Path MTU Discovery (PMTUD) for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4.  It obsoletes RFC 1981.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="87"/>
          <seriesInfo name="RFC" value="8201"/>
          <seriesInfo name="DOI" value="10.17487/RFC8201"/>
        </reference>
        <reference anchor="I-D.ietf-uta-tls13-iot-profile" target="https://www.ietf.org/internet-drafts/draft-ietf-uta-tls13-iot-profile-01.txt">
          <front>
            <title>TLS/DTLS 1.3 Profiles for the Internet of Things</title>
            <author initials="H" surname="Tschofenig" fullname="Hannes Tschofenig">
              <organization/>
            </author>
            <author initials="T" surname="Fossati" fullname="Thomas Fossati">
              <organization/>
            </author>
            <date year="2021" month="February" day="22"/>
            <abstract>
              <t>This document is a companion to RFC 7925 and defines TLS/DTLS 1.3 profiles for Internet of Things devices.  It also updates RFC 7925 with regards to the X.509 certificate profile.</t>
              <t> Discussion Venues</t>
              <t> This note is to be removed before publishing as an RFC.</t>
              <t> Source for this draft and an issue tracker can be found at https://github.com/thomas-fossati/draft-tls13-iot (https://github.com/thomas-fossati/draft-tls13-iot).</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-uta-tls13-iot-profile-01"/>
        </reference>
        <reference anchor="RFC5764" target="https://www.rfc-editor.org/info/rfc5764">
          <front>
            <title>Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)</title>
            <author initials="D." surname="McGrew" fullname="D. McGrew">
              <organization/>
            </author>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization/>
            </author>
            <date year="2010" month="May"/>
            <abstract>
              <t>This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTP Control Protocol (SRTCP) flows.  DTLS keying happens on the media path, independent of any out-of-band signalling channel present. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5764"/>
          <seriesInfo name="DOI" value="10.17487/RFC5764"/>
        </reference>
        <reference anchor="RFC8445" target="https://www.rfc-editor.org/info/rfc8445">
          <front>
            <title>Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal</title>
            <author initials="A." surname="Keranen" fullname="A. Keranen">
              <organization/>
            </author>
            <author initials="C." surname="Holmberg" fullname="C. Holmberg">
              <organization/>
            </author>
            <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
              <organization/>
            </author>
            <date year="2018" month="July"/>
            <abstract>
              <t>This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication.  This protocol is called Interactive Connectivity Establishment (ICE).  ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).</t>
              <t>This document obsoletes RFC 5245.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8445"/>
          <seriesInfo name="DOI" value="10.17487/RFC8445"/>
        </reference>
        <reference anchor="RFC7924" target="https://www.rfc-editor.org/info/rfc7924">
          <front>
            <title>Transport Layer Security (TLS) Cached Information Extension</title>
            <author initials="S." surname="Santesson" fullname="S. Santesson">
              <organization/>
            </author>
            <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
              <organization/>
            </author>
            <date year="2016" month="July"/>
            <abstract>
              <t>Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted certification authorities (CAs).  This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA).</t>
              <t>This document defines an extension that allows a TLS client to inform a server of cached information, thereby enabling the server to omit already available information.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7924"/>
          <seriesInfo name="DOI" value="10.17487/RFC7924"/>
        </reference>
        <reference anchor="RFC8879" target="https://www.rfc-editor.org/info/rfc8879">
          <front>
            <title>TLS Certificate Compression</title>
            <author initials="A." surname="Ghedini" fullname="A. Ghedini">
              <organization/>
            </author>
            <author initials="V." surname="Vasiliev" fullname="V. Vasiliev">
              <organization/>
            </author>
            <date year="2020" month="December"/>
            <abstract>
              <t>In TLS handshakes, certificate chains often take up the majority of the bytes transmitted.</t>
              <t>This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8879"/>
          <seriesInfo name="DOI" value="10.17487/RFC8879"/>
        </reference>
        <reference anchor="RFC6066" target="https://www.rfc-editor.org/info/rfc6066">
          <front>
            <title>Transport Layer Security (TLS) Extensions: Extension Definitions</title>
            <author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3rd">
              <organization/>
            </author>
            <date year="2011" month="January"/>
            <abstract>
              <t>This document provides specifications for existing TLS extensions.  It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2".  The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6066"/>
          <seriesInfo name="DOI" value="10.17487/RFC6066"/>
        </reference> #, date -->
<reference anchor="I-D.ietf-quic-recovery" target="https://www.ietf.org/internet-drafts/draft-ietf-quic-recovery-34.txt"> anchor='AEAD-LIMITS'>
<front>
            <title>QUIC Loss Detection and Congestion Control</title>
            <author initials="J" surname="Iyengar" fullname="Jana Iyengar">
              <organization/>
            </author>
            <author initials="I" surname="Swett" fullname="Ian Swett">
              <organization/>
            </author>
            <date year="2021" month="January" day="14"/>
            <abstract>
              <t>This document describes loss detection and congestion control mechanisms for QUIC.</t>
              <t> Note to Readers</t>
              <t> Discussion of this draft takes place
<title>Usage Limits on the QUIC working group mailing list (quic@ietf.org (mailto:quic@ietf.org)), which is archived at https://mailarchive.ietf.org/arch/ search/?email_list=quic.</t>
              <t> Working Group information can be found at https://github.com/quicwg; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/-recovery.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-quic-recovery-34"/>
        </reference>
        <reference anchor="I-D.ietf-tls-esni" target="https://www.ietf.org/internet-drafts/draft-ietf-tls-esni-10.txt">
          <front>
            <title>TLS Encrypted Client Hello</title>
            <author initials="E" surname="Rescorla" fullname="Eric Rescorla">
              <organization/>
            </author> AEAD Algorithms</title>
<author initials="K" surname="Oku" fullname="Kazuho Oku">
              <organization/>
            </author>
            <author initials="N" surname="Sullivan" fullname="Nick Sullivan">
              <organization/>
            </author>
            <author initials="C" surname="Wood" fullname="Christopher Wood">
              <organization/> initials='F' surname='Günther' fullname='Felix Günther'>
<organization />
</author>
<author initials='M' surname='Thomson' fullname='Martin Thomson'>
<organization />
</author>
<author initials='C.A.' surname='Wood' fullname='Christopher Wood'>
<organization />
</author>
<date year="2021" month="March" day="08"/>
            <abstract>
              <t>This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key.</t>
            </abstract> year='2021' month='July' day='12' />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-esni-10"/> name='Internet-Draft' value='draft-irtf-cfrg-aead-limits-03'/>
</reference>

        <reference anchor="CCM-ANALYSIS">
          <front>
            <title>On the Security of CTR + CBC-MAC</title>
            <author initials="J." surname="Jonsson" fullname="Jakob Jonsson">
              <organization/>
            </author>
            <date month="February" year="2003"/>
          </front>
          <seriesInfo name="Selected
          <refcontent>Selected Areas in Cryptography" value="pp. 76-93"/> Cryptography pp. 76-93</refcontent>
          <seriesInfo name="DOI" value="10.1007/3-540-36492-7_7"/>
        </reference>
      </references>
    </references>
    <section anchor="protocol-data-structures-and-constant-values" numbered="true" toc="default">
      <name>Protocol Data Structures and Constant Values</name>
      <t>This section provides the normative protocol types and constants definitions.</t>
      <section anchor="record-layer" numbered="true" toc="default">
        <name>Record Layer</name>
<artwork name="" type="" type="ascii-art" align="left" alt=""><![CDATA[
    struct {
        ContentType type;
        ProtocolVersion legacy_record_version;
        uint16 epoch = 0
        uint48 sequence_number;
        uint16 length;
        opaque fragment[DTLSPlaintext.length];
    } DTLSPlaintext;

    struct {
         opaque content[DTLSPlaintext.length];
         ContentType type;
         uint8 zeros[length_of_padding];
    } DTLSInnerPlaintext;

    struct {
        opaque unified_hdr[variable];
        opaque encrypted_record[length];
    } DTLSCiphertext;

    0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |0|0|1|C|S|L|E E|
    +-+-+-+-+-+-+-+-+
    | Connection ID |   Legend:
    | (if any,      |
    /  length as    /   C   - Connection ID (CID) present
    |  negotiated)  |   S   - Sequence number length
    +-+-+-+-+-+-+-+-+   L   - Length present
    |  8 or 16 bit  |   E   - Epoch
    |Sequence Number|
    +-+-+-+-+-+-+-+-+
    | 16 bit Length |
    | (if present)  |
    +-+-+-+-+-+-+-+-+

    struct {
    uint16
        uint64 epoch;
    uint48
        uint64 sequence_number;
    } RecordNumber;
]]></artwork>
      </section>
      <section anchor="handshake-protocol" numbered="true" toc="default">
        <name>Handshake Protocol</name>
        <artwork
<sourcecode name="" type="" align="left" alt=""><![CDATA[ type="tls-presentation"><![CDATA[
    enum {
        hello_request_RESERVED(0),
        client_hello(1),
        server_hello(2),
        hello_verify_request_RESERVED(3),
        new_session_ticket(4),
        end_of_early_data(5),
        hello_retry_request_RESERVED(6),
        encrypted_extensions(8),
        request_connection_id(9),           /* New */
        new_connection_id(10),              /* New */
        certificate(11),
        server_key_exchange_RESERVED(12),
        certificate_request(13),
        server_hello_done_RESERVED(14),
        certificate_verify(15),
        client_key_exchange_RESERVED(16),
        finished(20),
        certificate_url_RESERVED(21),
        certificate_status_RESERVED(22),
        supplemental_data_RESERVED(23),
        key_update(24),
        message_hash(254),
        (255)
    } HandshakeType;

    struct {
        HandshakeType msg_type;    /* handshake type */
        uint24 length;             /* bytes in message */
        uint16 message_seq;        /* DTLS-required field */
        uint24 fragment_offset;    /* DTLS-required field */
        uint24 fragment_length;    /* DTLS-required field */
        select (msg_type) {
            case client_hello:          ClientHello;
            case server_hello:          ServerHello;
            case end_of_early_data:     EndOfEarlyData;
            case encrypted_extensions:  EncryptedExtensions;
            case certificate_request:   CertificateRequest;
            case certificate:           Certificate;
            case certificate_verify:    CertificateVerify;
            case finished:              Finished;
            case new_session_ticket:    NewSessionTicket;
            case key_update:            KeyUpdate;
            case request_connection_id: RequestConnectionId;
            case new_connection_id:     NewConnectionId;
        } body;
    } Handshake;

    uint16 ProtocolVersion;
    opaque Random[32];

    uint8 CipherSuite[2];    /* Cryptographic suite selector */

    struct {
        ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2
        Random random;
        opaque legacy_session_id<0..32>;
        opaque legacy_cookie<0..2^8-1>;                  // DTLS
        CipherSuite cipher_suites<2..2^16-2>;
        opaque legacy_compression_methods<1..2^8-1>;
        Extension extensions<8..2^16-1>;
    } ClientHello;
]]></artwork>
]]></sourcecode>
      </section>
      <section anchor="acks" numbered="true" toc="default">
        <name>ACKs</name>
        <artwork
<sourcecode name="" type="" align="left" alt=""><![CDATA[ type="tls-presentation"><![CDATA[
    struct {
        RecordNumber record_numbers<0..2^16-1>;
    } ACK;
]]></artwork>
]]></sourcecode>
      </section>
      <section anchor="connection-id-management" numbered="true" toc="default">
        <name>Connection ID Management</name>
        <artwork
<sourcecode name="" type="" align="left" alt=""><![CDATA[ type="tls-presentation"><![CDATA[
    enum {
        cid_immediate(0), cid_spare(1), (255)
    } ConnectionIdUsage;

    opaque ConnectionId<0..2^8-1>;

    struct {
    ConnectionIds
        ConnectionId cids<0..2^16-1>;
        ConnectionIdUsage usage;
    } NewConnectionId;

    struct {
      uint8 num_cids;
    } RequestConnectionId;
]]></artwork>
]]></sourcecode>
      </section>
    </section>
    <section anchor="ccm-bounds" numbered="true" toc="default">
      <name>Analysis of Limits on CCM Usage</name>
      <t>TLS <xref target="TLS13" target="RFC8446" format="default"/> and <xref target="AEBounds" format="default"/> do not specify limits on key usage for
AEAD_AES_128_CCM.
 However, any AEAD that is used with DTLS requires limits on
use that ensure that both confidentiality and integrity are preserved. This
section documents that analysis for AEAD_AES_128_CCM.</t>
      <t><xref target="CCM-ANALYSIS" format="default"/> is used as the basis of this
analysis. The results of that analysis are used to derive usage limits that are
based on those chosen in <xref target="TLS13" target="RFC8446" format="default"/>.</t>
      <t>This analysis uses symbols for multiplication (*), division (/), and
exponentiation (^), plus parentheses for establishing precedence. The following
symbols are also used:</t>
      <dl newline="false" spacing="normal"> spacing="normal" indent="4">
        <dt>t:</dt>
        <dd>
  The size of the authentication tag in bits. For this cipher, t is 128.</dd>
        <dt>n:</dt>
        <dd>
  The size of the block function in bits. For this cipher, n is 128.</dd>
        <dt>l:</dt>
        <dd>
  The number of blocks in each packet (see below).</dd>
        <dt>q:</dt>
        <dd>
  The number of genuine packets created and protected by endpoints. This value
is the bound on the number of packets that can be protected before updating
keys.</dd>
        <dt>v:</dt>
        <dd>
  The number of forged packets that endpoints will accept. This value is the
bound on the number of forged packets that an endpoint can reject before
updating keys.</dd>
      </dl>
      <t>The analysis of AEAD_AES_128_CCM relies on a count of the number of block
operations involved in producing each message. For simplicity, and to match the
analysis of other AEAD functions in <xref target="AEBounds" format="default"/>, this analysis assumes a
packet length of 2^10 blocks and a packet size limit of 2^14 bytes.</t>
      <t>For AEAD_AES_128_CCM, the total number of block cipher operations is the sum
of: the length of the associated data in blocks, the length of the ciphertext in blocks, and the length of the plaintext in blocks, plus 1. In this analysis,
this is simplified to a value of twice the maximum length of a record in blocks
(that is, <tt>2l = 2^11</tt>). This simplification is based on the associated data
being limited to one block.</t>
      <section anchor="ccm-confidentiality" numbered="true" toc="default">
        <name>Confidentiality Limits</name>
        <t>For confidentiality, Theorem 2 in <xref target="CCM-ANALYSIS" format="default"/> establishes that an attacker
gains a distinguishing advantage over an ideal pseudorandom permutation (PRP) of
no more than:</t>
        <artwork name="" type="" type="ascii-art" align="left" alt=""><![CDATA[
(2l * q)^2 / 2^n
]]></artwork>

        <t>For a target advantage in a single-key setting of 2^-60, which matches that used by TLS 1.3, as summarized in <xref target="TLS13" format="default"/>, target="AEAD-LIMITS"/>, this results in the relation:</t>
        <artwork name="" type="" type="ascii-art" align="left" alt=""><![CDATA[
q <= 2^23
]]></artwork>
        <t>That is, endpoints cannot protect more than 2^23 packets with the same set of
keys without causing an attacker to gain an a larger advantage than the target of
2^-60.</t>
      </section>
      <section anchor="ccm-integrity" numbered="true" toc="default">
        <name>Integrity Limits</name>
        <t>For integrity, Theorem 1 in <xref target="CCM-ANALYSIS" format="default"/> establishes that an attacker
gains an advantage over an ideal PRP of no more than:</t>
        <artwork name="" type="" type="ascii-art" align="left" alt=""><![CDATA[
v / 2^t + (2l * (v + q))^2 / 2^n
]]></artwork>
        <t>The goal is to limit this advantage to 2^-57, to match the target in
TLS 1.3, as summarized in <xref target="TLS13" format="default"/>. target="AEAD-LIMITS"/>. As <tt>t</tt> and <tt>n</tt> are both 128, the first term is negligible relative
to the second, so that term can be removed without a significant effect on the
result. This produces the relation:</t>
        <artwork name="" type="" type="ascii-art" align="left" alt=""><![CDATA[
v + q <= 2^24.5
]]></artwork>
        <t>Using the previously-established previously established value of 2^23 for <tt>q</tt> and rounding, this leads
to an upper limit on <tt>v</tt> of 2^23.5. That is, endpoints cannot attempt to
authenticate more than 2^23.5 packets with the same set of keys without causing
an attacker to gain an a larger advantage than the target of 2^-57.</t>
      </section>
      <section anchor="ccm-short" numbered="true" toc="default">
        <name>Limits for AEAD_AES_128_CCM_8</name>
        <t>The TLS_AES_128_CCM_8_SHA256 cipher suite uses the AEAD_AES_128_CCM_8 function,
which uses a short authentication tag (that is, t=64).</t>
        <t>The confidentiality limits of AEAD_AES_128_CCM_8 are the same as those for
AEAD_AES_128_CCM, as this does not depend on the tag length; see
<xref target="ccm-confidentiality" format="default"/>.</t>
        <t>The shorter tag length of 64 bits means that the simplification used in
<xref target="ccm-integrity" format="default"/> does not apply to AEAD_AES_128_CCM_8. If the goal is to
preserve the same margins as other cipher suites, then the limit on forgeries
is largely dictated by the first term of the advantage formula:</t>
        <artwork name="" type="" type="ascii-art" align="left" alt=""><![CDATA[
v <= 2^7
]]></artwork>
        <t>As this represents attempts to that fail authentication, applying this limit might
be feasible in some environments. However, applying this limit in an
implementation intended for general use exposes connections to an inexpensive
denial of service
denial-of-service attack.</t>
        <t>This analysis supports the view that TLS_AES_128_CCM_8_SHA256 is not suitable
for general use. Specifically, TLS_AES_128_CCM_8_SHA256 cannot be used without
additional measures to prevent forgery of records, or to mitigate the effect of
forgeries. This might require understanding the constraints that exist in a
particular deployment or application. For instance, it might be possible to set
a different target for the advantage an attacker gains based on an
understanding of the constraints imposed on a specific usage of DTLS.</t>
      </section>
    </section>
    <section anchor="implementation-pitfalls" numbered="true" toc="default">
      <name>Implementation Pitfalls</name>
      <t>In addition to the aspects of TLS that have been a source of interoperability
and security problems (Section C.3 of <xref target="TLS13" format="default"/>), (<xref target="RFC8446" sectionFormat="of" section="C.3"/>), DTLS presents a few new
potential sources of issues, noted here.</t>
      <ul spacing="normal">
        <li>Do you correctly handle messages received from multiple epochs during a key
transition?  This includes locating the correct key as well as performing
replay detection, if enabled.</li>
        <li>Do you retransmit handshake messages that are not (implicitly or explicitly)
acknowledged (<xref target="timeout-retransmissions" format="default"/>)?</li>
        <li>Do you correctly handle handshake message fragments received, including
when they are out of order?</li>
        <li>Do you correctly handle handshake messages received out of order?
This may include either buffering or discarding them.</li>
        <li>Do you limit how much data you send to a peer before its address is
validated?</li>
        <li>Do you verify that the explicit record length is contained within the
datagram in which it is contained?</li>
      </ul>
    </section>
     <section anchor="history" numbered="true" toc="default">
      <name>History</name>
      <t>RFC EDITOR: PLEASE REMOVE THE THIS SECTION</t>
      <t>(*) indicates a change that may affect interoperability.</t>
      <t>IETF Drafts
draft-42</t>
      <ul spacing="normal">
        <li>SHOULD level requirement for the client to offer CID
extension.</li>
        <li>Change the default retransmission timer to 1s and
allow people to do otherwise if they have side knowledge.</li>
        <li>Cap any given flight to 10 records</li>
        <li>Don't re-set the timer to the initial value but to 1.5
times the measured RTT.</li>
        <li>A bunch more clarity about the reliability algorithms
and timers (including changing reset to re-arm)</li>
        <li>Update IANA considerations</li>
      </ul>
      <t>draft-40</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
   - Clarified encrypted_record structure in DTLS 1.3 record layer
   - Added description of the demultiplexing process
   - Added text about the DTLS 1.2 and DTLS 1.3 CID mechanism
   - Forbid going from an empty CID to a non-empty CID (*)
   - Add warning about certificates and congestion
   - Use DTLS style version values, even for DTLS 1.3 (*)
   - Describe how to distinguish DTLS 1.2 and DTLS 1.3 connections
   - Updated examples
   - Included editorial improvements from Ben Kaduk
   - Removed stale text about out-of-epoch records
   - Added clarifications around when ACKs are sent
   - Noted that alerts are unreliable
   - Clarify when you can reset the timer
   - Indicated that records with bogus epochs should be discarded
   - Relax age out text
   - Updates to cookie text
   - Require that cipher suites define a record number encryption algorithm
   - Clean up use of connection and association
   - Reference tls-old-versions-deprecate
]]></artwork>
      <t>draft-39
- Updated Figure 4 due to misalignment with Figure 3 content</t>
      <t>draft-38
- Ban implicit Connection IDs (*)
- ACKs are processed as the union.</t>
      <t>draft-37:
- Fix the other place where we have ACK.</t>
      <t>draft-36:
- Some editorial changes.
- Changed the content type to not conflict with existing allocations (*)</t>
      <t>draft-35:
- I-D.ietf-tls-dtls-connection-id became a normative reference
- Removed duplicate reference to I-D.ietf-tls-dtls-connection-id.
- Fix figure 11 to have the right numbers andno cookie in message 1.
- Clarify when you can ACK.
- Clarify additional data computation.</t>
      <t>draft-33:
- Key separation between TLS and DTLS. Issue #72.</t>
      <t>draft-32:
- Editorial improvements and clarifications.</t>
      <t>draft-31:
- Editorial improvements in text and figures.
- Added normative reference to ChaCha20 and Poly1305.</t>
      <t>draft-30:
- Changed record format
- Added text about end of early data
- Changed format of the Connection ID Update message
- Added Appendix A "Protocol Data Structures and Constant Values"</t>
      <t>draft-29:
- Added support for sequence number encryption
- Update to new record format
- Emphasize that compatibility mode isn't used.</t>
      <t>draft-28:
- Version bump to align with TLS 1.3 pre-RFC version.</t>
      <t>draft-27:
- Incorporated unified header format.
- Added support for CIDs.</t>
      <t>draft-04 - 26:
- Submissions to align with TLS 1.3 draft versions</t>
      <t>draft-03
- Only update keys after KeyUpdate is ACKed.</t>
      <t>draft-02
- Shorten the protected record header and introduce an ultra-short
  version of the record header.
- Reintroduce KeyUpdate, which works properly now that we have ACK.
- Clarify the ACK rules.</t>
      <t>draft-01
- Restructured the ACK to contain a list of records and also
  be a record rather than a handshake message.</t>
      <t>draft-00
- First IETF Draft</t>
      <t>Personal Drafts
draft-01
- Alignment with version -19 of the TLS 1.3 specification</t>
      <t>draft-00</t>
      <ul spacing="normal">
        <li>Initial version using TLS 1.3 as a baseline.</li>
        <li>Use of epoch values instead of KeyUpdate message</li>
        <li>Use of cookie extension instead of cookie field in
ClientHello and HelloVerifyRequest messages</li>
        <li>Added ACK message</li>
        <li>Text about sequence number handling</li>
      </ul>
    </section>
    <section anchor="working-group-information" numbered="true" toc="default">
      <name>Working Group Information</name>
      <t>RFC EDITOR: PLEASE REMOVE THIS SECTION.</t>
      <t>The discussion list for the IETF TLS working group is located at the e-mail
address <eref target="mailto:tls@ietf.org">tls@ietf.org</eref>. Information on the group and information on how to
subscribe to the list is at <eref target="https://www1.ietf.org/mailman/listinfo/tls">https://www1.ietf.org/mailman/listinfo/tls</eref></t>
      <t>Archives of the list can be found at:
<eref target="https://www.ietf.org/mail-archive/web/tls/current/index.html">https://www.ietf.org/mail-archive/web/tls/current/index.html</eref></t>
    </section>
    <section anchor="contributors" numbered="true" numbered="false" toc="default">
      <name>Contributors</name>
      <t>Many people have contributed to previous DTLS versions versions, and they are acknowledged
in prior versions of DTLS specifications or in the referenced specifications. specifications.</t>

      <contact fullname="Hanno Becker">
        <organization>Arm Limited</organization>
        <address>
          <email>Hanno.Becker@arm.com</email>
        </address>
      </contact>

      <contact fullname="David Benjamin">
        <organization>Google</organization>
        <address>
          <email>davidben@google.com</email>
        </address>
      </contact>

      <contact fullname="Thomas Fossati">
        <organization>Arm Limited</organization>
        <address>
          <email>thomas.fossati@arm.com</email>
        </address>
      </contact>

      <contact fullname="Tobias Gondrom">
        <organization>Huawei</organization>
        <address>
          <email>tobias.gondrom@gondrom.org</email>
        </address>
      </contact>

      <contact fullname="Felix Günther">
        <organization>ETH Zurich</organization>
        <address>
          <email>mail@felixguenther.info</email>
        </address>
      </contact>

      <contact fullname="Benjamin Kaduk">
        <organization>Akamai Technologies</organization>
        <address>
          <email>kaduk@mit.edu</email>
        </address>
      </contact>

      <contact fullname="Ilari Liusvaara">
        <organization>Independent</organization>
        <address>
          <email>ilariliusvaara@welho.com</email>
        </address>
      </contact>

      <contact fullname="Martin Thomson">
        <organization>Mozilla</organization>
        <address>
          <email>martin.thomson@gmail.com</email>
        </address>
      </contact>

      <contact fullname="Christopher A. Wood">
        <organization>Cloudflare</organization>
        <address>
          <email>caw@heapingbits.net</email>
        </address>
      </contact>

      <contact fullname="Yin Xinxing">
        <organization>Huawei</organization>
        <address>
          <email>yinxinxing@huawei.com</email>
        </address>
      </contact>

      <t> The
sequence number encryption concept is taken from the QUIC specification. <xref target="RFC9000"/>. We would
like to thank the authors of the QUIC specification RFC 9000 for their work. Felix
Guenther and Martin Thomson <contact fullname="Felix Günther"/> and <contact fullname="Martin
 Thomson"/> contributed the analysis in <xref target="ccm-bounds" format="default"/>.</t>
      <t>In addition, we would like to thank:</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
* David Benjamin
  Google
  davidben@google.com
]]></artwork>
      <artwork name="" type="" align="left" alt=""><![CDATA[
* Thomas Fossati
  Arm Limited
  Thomas.Fossati@arm.com
]]></artwork>
      <artwork name="" type="" align="left" alt=""><![CDATA[
* Tobias Gondrom
  Huawei
  tobias.gondrom@gondrom.org
]]></artwork>
      <artwork name="" type="" align="left" alt=""><![CDATA[
* Felix Günther
  ETH Zurich
  mail@felixguenther.info
]]></artwork>
      <artwork name="" type="" align="left" alt=""><![CDATA[
* Benjamin Kaduk
  Akamai Technologies
  kaduk@mit.edu
]]></artwork>
      <artwork name="" type="" align="left" alt=""><![CDATA[
* Ilari Liusvaara
  Independent
  ilariliusvaara@welho.com
]]></artwork>
      <artwork name="" type="" align="left" alt=""><![CDATA[
* Martin Thomson
  Mozilla
  martin.thomson@gmail.com
]]></artwork>
      <artwork name="" type="" align="left" alt=""><![CDATA[
* Christopher A. Wood
  Apple Inc.
  cawood@apple.com
]]></artwork>
      <artwork name="" type="" align="left" alt=""><![CDATA[
* Yin Xinxing
  Huawei
  yinxinxing@huawei.com
]]></artwork>
      <artwork name="" type="" align="left" alt=""><![CDATA[
* Hanno Becker
  Arm Limited
  Hanno.Becker@arm.com
]]></artwork>
    </section>
    <section anchor="acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>We format="default"/>.
      We would like to thank Jonathan Hammell, Bernard Aboba and Andy Cunningham <contact fullname="Jonathan Hammell"/>, <contact fullname="Bernard Aboba"/>, and <contact fullname="Andy Cunningham"/> for their review comments.</t>
      <t>Additionally, we would like to thank the IESG members for their review comments: Martin Duke, Erik Kline, Francesca Palombini, Lars Eggert, Zaheduzzaman Sarker, John Scudder, Eric Vyncke, Robert Wilton, Roman Danyliw, Benjamin Kaduk, Murray Kucherawy, Martin Vigoureux, and Alvaro Retana</t> <contact fullname="Martin Duke"/>, <contact fullname="Erik Kline"/>, <contact fullname="Francesca Palombini"/>, <contact fullname="Lars Eggert"/>, <contact fullname="Zaheduzzaman Sarker"/>, <contact fullname="John Scudder"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Robert Wilton"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Benjamin Kaduk"/>, <contact fullname="Murray Kucherawy"/>, <contact fullname="Martin Vigoureux"/>, and <contact fullname="Alvaro Retana"/>.</t>
    </section>

  </back>
  <!-- ##markdown-source:
H4sIAC7BjGAAA+y9a3vbVpYu+H3/ChzlQ6SEpHWz49hJTiuSXNaUb8dSKt2T
SusBSVBCmQTYAGiZbbt/2XybPzbrvvcGQNly0t3nmRlWd5VMAvu69trr+q7h
cOiavJlnj5KL6yw5SZv0qkoXyUWVFvWyrJrkWbrOquQ8m6yqvFkn2ycXz853
kldV2ZSTcp78LavqvCySvdGBS8fjKnv7KMFH6ItpOSnSBbQ9rdJZM8yzZjZs
5vVwCv+1dzA8PHCTtMmuymr9KKmbqSvHdTnPmqx+lDw4OPzOuXxZPUqWVXb/
4LuHF9WqbvZ3d7/f3XdplaWPbFDupqzeXFXlagmzeHbu3mRr+Gb6KDkrmqwq
smZ4gv07VzdpMb1M52UBY1pntVvmj1ySVLNJNq2b9Vy+TRKYW/BnXkyzotEv
aliVKpvV9u/1IvpnU+UTe3hSLhbwrv2aF/O88N1k75rhPK+bITQyLufw2LD8
5lv4BVZukS6XeXHFz6ar5rqsYLBD+JE+eQFPn46S11k9Kat5qt/zgp/CIDo/
ldVVWuT/njawYY+S1xdPng9giSYj/T1bpPn8UZK9qf6pamaLEQzetXt8Okou
6sl1OcuK/Cru82laFFnd83Pc71G1SJ7li7zJpq2Or6mBUWMN/FNa9Y/ixSh5
Xk7T6epqFY/hRXqVFUBtnZ/jMfylLK/mWe/sC2nhnyb1COllBpQ0yqYr54qy
WsD7bzOkmddPjne/e/BQ/tzf2/te/oS/9uTPw8PDA/3z4f6evfa9fvtg/3tt
4eHed4f459nwZBSdk+GkhFWZ4LiH+fQRnAkcUjSQ7/a/f6ADub+/r10e7Frv
B4e7/s8H/s/v5M/7+wcP7U974IF/4Lv7+/fxz6PTn8tVMa0f0aoJ59ii7awT
YANHQKdA7zme62lyWkyq9RKHnvxSZ7B1eDy36FUjaPoMeVuPRsmz1frNu/jb
v46SV9BcVZcF/TCFfzxK9nf3Hgx3D4a7D3koaXWVwbHbum6a5aN7925ubkZ5
fTWqrlfzUToZrd7c+483y3vQ//DodExzGC2nMxzM65c//3J+Ec/odTkGbpMc
E0niuQTinsLRvUp+KapsnqfjeZa8yBrkPDVODKYN5w2O25Q5JqzGLPlfv5wd
J/CiccRb5v58lDzJgfKhk/iHJ6PkL//3/1VAB1X8w/Eo+T+AS7dWZX93uPtg
uHe/uyo1LEu2rPKiGeXppBrBkbiHz9/7bu/hlnPD4TBJx8C+0gmwyovrvEYu
tEL2ldTLbJLPcjjdAb/HGTafc2k4uTSWcmmMbD2SdD4vb+pkMs+hm3t1Vr2F
94DxzZGCoJ8a+C8x0VVBNJWU+AD06pS34+KnyU26hm9T+BeMOqvzqwLID16F
u+MtTiBL32b1tCqJpQ5gXRbLrKI/cXsWWV3DsXdwsK6yaj3C6Wd+kDpubBxW
D+m7LGDk62Sc1tBPydu/+c7E2buoJewV/vE2h8Em2b+t8rfpnBZa37lapdBc
k8HPN3lzTR1k7yYZnyZYeaA06AMbZOZwrwAGUWXLebpOx/kc2hglfmtq4G54
LGvdNDgAWTVfI0U3Nm64VnHFaBumyXjN24vLYFvXpgy7spFL0K09YlJa5NPp
PHPOfZXgPVyV0xWN0zl88PTk7OLl60fJq2enR+enyevT5y//dppcPD1Nnrx8
9uzlr2cv/pK8Onp99JfXR6+e8nbU5aqaZAnsEQwLh4B3Om4J8O2igf+HIQMt
/CVvnq7Go+R8dXWV1ciFJnCI4U9XX5erOUwLmlqNgWHhb2mdLFfzeVLBHsDT
dQIkpGflCtYdWgLquwd8+ObqnogteBhGQH9wVHhKNS0cUQG8vgRKwnZvsjlQ
+uk0b8oqT+c6jGSSFjgG2A94MBjywI1XsAXFGoeHNw9yeHkr8WOfApNY1SHZ
wfbg1YVbibKEUC8c9EVaASGV0LdseriTuHJwQGDSwMvy+hp6JsZk3Hvg4OaZ
5Sj6wPCRJpFokf6viEKF9GSBgUvC6JqbLINR3YRnFse1zIBtjGhc7THAg8uS
pjOjF+fEPR85Ha8w1VfhydHfkCnX1+mbzH4eJU/LGzjy1YDXBZi4q1YFs400
MdbtaV4HDyTbrJcwYDzXF8evkvfv5bL++JGXFPYY9znmTrjjK7jbfjmxNx48
/PgRCSANT1ZB7KiczWAcwdrAebAj78+yEDksS7u3zdzWtUV0W+RrGMsY92UK
CzMvl9lUGDDxynk+zirYb5h1yDjHmYPXarjY52mFX+ALeFrKus7HKDuNS2RL
JRz0Ap769ywpshvPv/LiLfNJmbpbpO/4MZxEuoAbuMEtn5TTTAhrVqV8pFaw
ylUGqwrrLkx4lxcXRRZY3BsYCByqq5y58DSb0emnNYcZNWkyq8pFwq/u2asP
cF+Kqba5zz888G1GDQEXxAsPxkhN1roI9iJKSkAbSUK04WA1i1Ivjb3HTBpv
5bosVgtYZuqkfpMvl3zwmYdDu9cg6JYFrk78Qu2I+UOb1A10ITcxUwTu2KSC
DWTSWJQgssD6V8iYtSG9pMNz5/pX6gDm9T/gz72DH1EiPeTpnYVMXpcOduZs
sZxneAeERwGGl75h0rBVDgUg4n7IQ+AqJrLT2w1o3QUtlAXsq7WwvaqRi9i/
iW5WVZ3tDJJ/oJwG89EO8nhYrr9Da7nOsuQI9qOY5u+SE2z5/XtaAiAJPIXT
DK6Web0zcr9e58A4xunkzU1aTZlxQR9813KrRqy5Pyh828JJhqbD34sSOFPG
+uGUaS57B7e33mPnwgoORjJjvDZRDGfiw7+YnOHf//Pk9NXr0+Oji9MfI/2h
nE+FDECXANEvQ8ZO7Awu5eNSj2hNzVxkFRzlcl5erfkGATU6QT26Traeg4C8
NeD/TV68pL9fn4J4+/r0BP8+f3r07Jn9oU+cP335yzP43clf/s3jl8+fn744
4Zfh26T11fOjf9li0Wzr5auLs5cvjp5tsZSd185kD+TGxKp4g2F+cqXrsaCF
/Bl4+d4hrxrqabBq9DdqXB8/uhu48bgrojn+J+zZGllvBrwP5UuQECbpMm/S
eT3ADuA6vikSPPZy285KFGRJmoJlZIEANh31NZTXWb5lGwts97KEAUPDOdys
dD/aCfXK3ojfTOu6nOSitp4Dn4BJwZUNdBzettpm7e9zeA5pkhUObvxar0tp
23cGTa9BflwviOaDPuVJbf9RcpqjIkID5kkBE0tEbhdW05lDtiwn149gfUGO
yZjro1pYwjW2vM4nSGg1rRb1nnmlEXdlmuk/pTWbBeiLhSziHC6fq7LhMdvK
yACxFRkhcRi/RDUrSSgtgbS9yBrR23pngTIMdamLMUp+vcZblQUy3MYU2wHx
aYV3pj4G5IyvbsGVNsP24S7UXo0UVHWpsgXIAEjUTSDCgTz4DxgKXUXSmY0K
znQGcmI8sqA9/BWHVpEYVctbNfKcDe+Q0ILicd9rFXUVkfENbOE1DGyKLE2J
OruFpI/PTh4h95Fvk7MT/v75+TNQg1FMWC2A/V3RGX+Wz7ImX2R8zKosxRsT
Rgk0CkxARJVkloKcksOiExs2Dj5yR7VYHfBuoHOdPAW5vHydNdX6NQv9JCDh
LzWQQMLGFRYBzmm+9IITHRHkHpDSkU4nxD+BwkApuWEWj43g+e/po7muytUV
SPGNayIFCjrKZ0kO60gCJu4wrDzstnToZaAD7AMuDrY6gHqG6jBJENvj/GqI
V1ha7OgE5CiVU9xGaat2kcJqP8srKv7AivlLEE8PsEE4StDPyQ4OJZJB6lFn
a+Z1+Yn9+YSVC9gybUm0TigIi6ADFJTMVsWE9XC8fhuTvA5gPE/yK5Aha70x
fCP5fL5CCwes3Nu0yssVXeNjkCP5HuwTllDtFtVNdQ+x1gLhvOVN9+x/kaUF
Wm2RpL9Jvv72a7RYTkmjojs/g71rrtfQaJMVdDPjYWzUhIT2ChwW3ET48NRT
ATX3TdRcueQFIBacNyuaBF70GRmsbdfvBZ3RKcfbCQ9rOr9J1zwA6eD9x6+D
DrSBQNdjSYw4Nmx3jnYCkiDT5O+/MVf5/dI49CUs9QwI5RLUAricpY+///b7
F3YSN3f5YkTmBdqtE9JdktcpLwnrFC/h9L7NQS15/xURWSW/fmSShcMAtw9r
PQncRPOyLpewNyqp5WJ9Ek0/2cIvSZOcqhJmGt7WyJ10vgTC410n+0JOq16p
3ccroyUKGUM+yqiQQQ80COxl5E1RRpBqopEjsiTRFg4B3d1eX5T3jwINcgB3
CTDrFFcduAU6KzI4mmgHM3saqILZ8hqEAZOKgCkkV/QYciDXnbzww0CrTaYr
u8ZgSul6WCMFkkkDDhucTodnTRuADabBki4FDAMOVl6SQMHjDZVgmDEcfTqR
UxLXyBwYr1Au8gSMgDTSLB4dLEOObLurGNmGoXQPI0ZOgZObo2oF/1tltE0y
XiXIUfKCrm08WzeoJjjgBsM5vFxM1n6RaT39QnLXZKQkwucmt7PR1Qj7dIE9
ABYiTX7Nxq8vjvkpsVqA/mPblawa4LH/rkoatoASvEk7yAB5S895SV5n6XyI
d2tgSjAzy/b564tXOz3joO5B5UAF+LsHYhzBax4GBOs2ZrkXrjEQHRpgYxvO
S93imzOkDFinGrYYmOfeiC5tPCIZORZQi1sgFeRoJIU7FfdPtGr4WeWUJDmb
kZ2HjEaiZoG0JWLSlEQAZrXwVb4kAfEGrgW7v2+qEobT7gLpDNtJmyZbLFlm
L0lco2FTb6H9BrkVmvGomcYPj7YGlOm3LHvq+QUusEB7azql+7jVe819qSS2
P0rUkGaclu5doNLJm2HdZMuWgO0N78lzlQSgd7SO4YaZxIfaE9CHLhab1lUq
IMJ/TAbKUp0RzLOwbxAkq6qs5ASftAZXTOarqef1NkFsI5hjVhA/nFUpCX/+
+iPKqLPFeK5WSGaX+L5xTBjtBMQbIzbWwjonF1bwADZiVaniZeMc+LsI31R6
wz4nb4ryZp5Nr9guTgvgX6TFlFdHyXm5CBq1HzzvxU5fZDfnGQnyF/nkTWaX
9QDuDFoVujTq1ZwdHLDofKLwyyWcEeU2ZBYmLwpLJnQF41pOM+IpMP2aXJy0
JUBftFd+PotAUAi2AFQouA7obaK8t+wWORwFNtdosZZlw4ZiWK05ep1I2SrU
2g2XqDfRp8h+r+a0bLpZo3CEszybT2s2jHV6Q56+WvK1I4TChlQ8nkS9Siow
4PujpOda1vMAezLP35DxdkCzqFc1uVjIbgNC7Bgkkbf+QsIustkMDznQDshY
OdvW8TbO4bgCd4CVhQW5grkC2YFKzQphvkxBOY/mmDJbgquwGIJq0IjTBjh7
NnkT28xI7FebN37RVS/UgwVtkknr/ftpWXdMWO6rr5LkVUr09gy2VlQLah83
BU1nOCbmB0SdCV4QlW7FHDVlep3pCrohuSp6BbqdAmMsWNDmkbOoBVSAyzsQ
AY9ugLyqG7e8TtlC1nSYB1wG//Ef/6FO+iQ5ZqX+0x9W3vyLQ/p8xov8YLtH
WvPOUz85122g9fnnH6DbzpZ9+r3OZxt52U7Q428XtDmn75bAG+rf3eeO2bdo
Owft4jK/f5R81bOl7Bf/ceuEL+Xop+xdinSzBUL1SxWqxPJCinVwuZDuFozM
eB5c6tk70Cqb2pHIhopwl8hRvA11clEKiO3hl4HzJydScky8Ga/PIBwa8j/R
hjIzablwcGUlYoLw21Zn3q2CuzJgM4ibpHZYfWeOrm9diPYqiBkpaFnu31r6
D1d74HIbe9Qoxl/0rliwXqKpq5cd1XT1ndYkNPUcfGQgxnrzxuEFUyfbpSwZ
cPdOrzvChnVstUrpsNbRhpDY7FC4X7OtKey/VvWhO6v0bZlPeXWKjKR8B/og
iupsGS2LiChIIum20ooUGGeuXqChNyvQUCPmMBEOybLV1Nl8RtYMk0+QpFY1
Dwim4IjBVbiaY2DpbJaeZylZ4BZwl+fIYDtDQaHuCa5zWWXCrRPZAGiljpdT
yICZvDzSOq01m/iB179moQeH5s4K4qyDJEtBDOlcrGJU4/VIzcbjRTWW02A5
iVxTsod6Uk0DaSg81nj/g+o7eUN+uoZ8DBkShBJQEw6At/Rd4+w7Ywws2iOl
1yLE53SRT+BJIk1+AHYK+3Uw6BV9TRQ8W5FT8VqDeHCbyKqv9hZP42TTwXPt
VAyWtXwSCRuk89gt3SOmiOADcweKJIko2WYjTwmy6mqJVLv/r/uHwz2y5MGk
4NclBt+gJLFAie9NPi/ptx2Y289rEqLQRzpAgcXFYm45a5AVcVwd0vMcBsIH
dO/+7i73gWzx7FUsNqmShGcBpWOM1vCOyZYaTPoKdSJ6NNESLoHrEtQiXcen
hXXBGjk0yE1yl5BWww2hSYCtyRpoM+W5zPImlBvJ2a7TdyLvLBfNagj0D7su
cs/VKp+msNGweqe3DFNE05q9lqmNF5316K7ATfbfunlWXDXXxFVW6AwK9Ejc
wBKpUR2vSGG88KTAd04IEYnJq3xlqF87WRVdPciONYb5JCeZ6Jsix6k9cL5W
CblW3ZQDg0QpQFM8c0X413WRw1khpd3lgR08JfPp2as6myRHT++dnoOIDJqP
Xhjs7hjnzSJdAo8spqCAlDM7M4FCzgEcgeWxKeFynYcbS3o3t4H++Sp8g85j
YBalK9e6IaE9x9Ap5C95PUmBcqcjsUjHc05mGVmekLp0qdQSJFLtdOWtZ3nt
AhspXA0gxpe45egAwI2jC7ScTFaVWrtQjseFIVW4jk1vdBzofsjfpuO5jsu6
1DEwu08nuARI7Wu3KKf5jGKx8srMTv6eZjH7as3GUNO+w2DEVjyb0ARF2tA1
mGNYClKwyTi9j+Le0KR7XjDffPjGiA058vNxvgSejzHPiY/zKElAIKpbLbNq
Nl8hN26FTWDHIK0262UmuiGbQSKdlryM4uyLjTciSHh+k1yTs4L0Yo6qaL0h
YYmxmYjYYSVmLRihbAqP4vnRMTVnEihdZWKfmuFBCVyc5HzZOFzRfjkOtLlt
8eyuglFOVxMzk1PkEF0nfGywIQ0EYPPHrXtyTc4vdJCQLYA5nq0Z8ZpXGKhA
r+lhVY8321xhWqvCG/TtIbkwfbdu4/udt8OwTNlHdlzxy+yTH2ewc6Pkl4Lu
P4yoEBMOiYakgjjx0ai+qesd2pVpHU04wB7vccfBMqpaKt6B96ZWHZcUJHqB
5Io0+9h+UfOqRtHOs6t0sr7k2VxK2/7xFazx3gMhlR+T3eiHw4dGOZdMOZ0X
eef81+UyRV6v98pv0U6O+Onf+fGPSfTjY9c/VW1ywlO+rcVPLA2N+WHy71lV
1r/xi5fl7HLJJtFoVGdFkVWfHJqMbFVg4PL08npa/aYk/XtnSSToAJ7jvfit
ZzE80T5u68pEjKGOjLxTOPATplHUj3u32z1iHvQ2ncNAKMJmzIEScBLe798/
HCT79w9YpEkpVJUPjBphScZDOtZQiFCJ3c5H2WhAoRd4mV1lBQVBwQUzaygi
squ9DaDNG4p2hMsZLy1i+TAkHcv9j+rvCeKflqsKwzjJ1njW2DRAnSgr4Xok
b+tjoJdm3sv8OIjBGu1BE8olK/PnqfgJBy/Y0keOoxHkK2FSyXbwyA7bxoMr
Z9bmbUFMD/m+Jzm9SWpUmzK0x6PTo5Oh/UicSBkKRg6m6IqZ9pCrH8gIKGhc
ffSMZDfZS/aTg+QwuZ88SL6j774dtv5D337Yhf/sfTj+cP7h2YfT5PTDbc/G
sRbw7yR5lmGSyyP5fRvUghT9ffThtu4lyvdhafjfyXFC4RtRa9vHZyc77JEs
GmnPgnGy6Q79OzmnN89bFx130D90HCS99IxH0erhIZo2gMPBvco9nNLDp8gp
+Rnr7AV1dvsKSUvS14dgXaTfHV2XbgvKCoRoOmzgFyHNp0SayAae5O/g3z+D
SKDE1FxXcByu86trlhTsZqrQQ0OBHhq2H9E53XvEKWBwu7skbAG1g8ZG8Q9s
crnOhLeQKWNGNg04SYUXXqrsCrdTnFxqqHiHdyT6p0AsA+ruCa1jN+B33z88
kEBRYhXSO7OmRgJaQBmrr0k2tiPTkkdrvnQ7v++7xJ4I4yrV9bumVQDBv8p9
aAupMCAGNffI4P9vqxQYd4PcnJww7SlS6F/cMtB1/VmRKgk7iwqUXkiJZxWW
XFEtqbjmLbCwEbk1WbDF5IL9S6CiZHv/Phrrj5U6jok4t3ff7e0SM8MdZwNn
6zCSMzHjcA53rq+f6+u7D3eCuAtaJgw5Nq4VnU5k5LsUzkLS9cPhuOt5HQDD
4if2HuDvJAG344KfH/1LsgDG3nFqUjibKhLMC0hSDbcwCh57pjN6ZjM6bC+I
MK1oJU7tmGF+ASiZdMbw9YMd9U3yy6jEsukDngxPIolguCfhemOzf2tJyUA2
LF13YpRc3jk9nySuEUXosYHdiUVphslrck+FTw/lObq1WtxPF8BPMGCgNkmR
Y9qEkITySY577egtWXEmL9kFEFn2OMjgYdL70C7uIy0Vjulsyukmc9XRZBVJ
JGeTT8wk4O0jyYgy6VxFco3bGXhTaySOuq72YedS1laIYapGCaRB15sqZX5L
596/B7Z/KauPxicfZRbq1pHqafpD684XqfSzvnV9l2b/Vdp3b31QYTwhaZxu
UZMs+D8oWYTf7tJ/SN74o30ndnvLjW7/7T/yLbMeoGj0F4zgHsbvVYPyz91r
McN7G/ruH+OGvtvfbhj55jZP7TrTt1lI6fQSNKrzUdsZP3tv08jbks4tI+/O
8C471r8+0WrQc4cP+3ZWhKtodC1bQP9U+oeIn3MVpW8ZXvdb/GxT1lI639n8
ZrhzySaCvxfvEWxS/2Zu2I5gTTbMtdvvhhF31nLT3P2iIYWpV0MmY+szW837
FqdnOK7FZaMuVDgOOWRHQmbJODmV37ckPDO6C1CKGLO5sOEYnMk8Sy2GhyQC
ccKKSKLCr1iYKI5ztRDBB68dyjKrG739LEZNeD/claBfzzFnzvP9EXpHyAtC
8h3faahZ+3SfkuU7vYNc68aRWGsvEDYYFB5Ntg6vn+CmealR+Z2bktRtEmI1
/k4V6Hla29WD96nzATebBLVwaHSVx2N0MsaNYhpF4HUEU68TevedWgni6KD5
3Pu20E5QUExc3h6tpCJFQyYNIrr9w2SW2vWuK7oNWQCGcWCcW4KRm5Vd2GQN
9TN0MB/JefDBohWHCUxVjhEXinXN/pUZRf+K2GKuL4ky6BKiLk/g13DkfM3e
LVP0jQ0+YUm24CsMcafVxaCmAiQa8jVMhXcxs/WGicAcQubUR7fYOkMTZWx/
3GSf/Bj1yqY0Tip/cEg3vQmaRMiyZUfHfzWPnSRXi4sKf90Sk1qrwy3Y8OWq
0U1Bk43J5GJNFkYg+jR3HViCWpLdNvp+lhXGJltIpiy2Goo4vJiMW1UBwviO
zQTpiLkP2jQldJ/8OdytHlkcprNhov0Q8R4adGVqYEsi1xcbsopG+xhQ2vTR
EZ24/aScNOhQmpfFVRiizDkRHPbe7/5pDRBUjzkmNVlucpTbGX1BTCM6/Oyz
PMkinTtwUdXtBJeu6yGy9lOf15mEGrlp3LBEBBAuQMlx3/iTuPnoK9lr8R04
CSGRg6amCvSEtxkkHqegu44Bw43XpKyxd7RlwIGt52hnDG/+RnlO8ABlzsAl
sb2/tzPwvuLt/X34J5pPJ2+2MdQfk+UHyf6DHd5sWRszuMaZkGnS560ZbR6B
RvcyTQqr1iSz2lE3HKIogVqmd6fEpjeYr1KQBcg+Bb3WJfOtmKPzDHT7gpml
desKfczhVdWqZUAh2wotQZ2zQu+8Dwkvbz713yQvcYI3eZ0Nkp4VrLJ/8CuW
mXWdAu2l+Rw4OGbRapT3oMcephEmw7yABQSlXEiDlPL375F63gEfQQ6jCU49
9DtFM7UEb6M73zXpmyAB+iBKymqrv8LlJxNMsR+1oidZxmx9vo1//5C8XOH9
p+qhWD4jSZJUxu2Xxxc7Se/vLamx8zu8mfz4Y7K/C3+DFDn8iaB2rjLe5fNl
NmEYg+QHmO7O5vf37P0jPDvJtpH6LS/t20s+mPmzXjzwvQVpNieUtvE5oz30
HcPuNeMMuFn4okQhJPhE9OJ9e9EfhQs8z8xu0Q6vHPiW7h/44cNtqm8cDJLb
5v6pnex8ca9LX39vv3awl/xAw/oBLn0Z0wcaTyApf05nyYdtYefEeDYOMZuD
tB68he7gSpYP+NLOhr4+hF/YxL7dNLHuA1Gj/SG/nXnd9vBb/+eJJUZ3H/Zb
8G3ny2/bD39AHZYSjIOhfF6Tb2+NYv4Uo+mMQ6aUTTeMofV4bL/65OPbJ8yu
9ItPPN7+4jMePzGuFPCkO7y332ZLd3j3YANnukMTh23mdId3H3jO8meuaw8J
mesd71KzJfSIlx3sEZE30b6AwjCbxDESbGG+2lg47PUJa6i31/7SqlqrN8YT
pKgmsftPGh5oQmjt0kD+FllAJqGBXexpr1hKvaGsn9QrRxbjE4WniAe/Myh8
kxLX1/x2RplTKhUedeQZEVgGbXnOQnnr5Jqi9tB0XmJmowvjc2L5BmXqC2vn
YIOs6AIpXJErcPe8Y1DVAdRWNPYCJmdr4kzHjteEQNdMFG6Hw1ETI9gn0rPI
cETQWwf7yfbuGC6JXbgpdnd3cBceHMh3e8kefHYoDr0WLSJ7x04ERwOU0GOM
KNNIQFATzo5eHFGGEUaOawZgzcmjLZHwscR6g56Xon8IhVsOi7A475bZlCbK
rvAwwaewcChUJzAxab72X3Vce9CHxfiH2ZdlkQ2culvVoBLr3WKVitxKo6Tt
/68RxjVEb6szhOEgKCpCL8CgXTIsDPiipi9aXTmJeiHTF56a3da7queTkUSG
R+HF+hpGHHFSIX47qTIJuaUmCHriTUbOnwVahUIkN44MlpS7NF9ITgY8jvCk
FsvP85Ssbz1X6OyjMckefoWxYaj6YE9/WeWY1Qiny7mfM8opicKlEf2I0eAs
q3Hgs17ZjU7b/1yDsH3ALMX98Gq8SLaZTbxIfkqe70hGy9UKtKS26isAPmKJ
annsRRGhRjk+1qEtcXJdYhxiU7oK16FI2usYB9nx67R7FB3PtrBslmIO5PPz
Z05BKNni0IJoo8NEaZBkZGNBurL0B6C+bTOAOI6WEiDHhGOdxGBsSil6qDUn
WDG1NKKcRk6tnJ1ePKEeYYBsNrNB0j778SFGw2qCO1xW9YBCi9VCvda0YpwE
KfBVeaUYKtCwH3S9ruFBmnuNqYZs98H57ZBvGlkdHJ+BGKbNKD0rK9szi8P2
yrEiTDqEcGPaYFZmZGM2Lw5bwEWyxHQfUw+rHFurgqQmJESK60Sm/wSOH0EU
ad6iIGsUIpdHGDSCDNBnrpbUrfEKb1CHuY5CoBTlEVhYKaWH4joU2YHuipLT
rRiHwQXJ6ZSFP0jOjy9eSZTL4fcPdj9+3BFsKDkPsETcN2dOO81HmXKGSRNm
F+uy4SUTGONgOF/XZP9F3GiyUksoju2YnGHCCYGrES2fmDM1MDwStc8kiDTA
4dQ+rlZ98GtGmAnRRqr86rrhgIAeQDcyiNCWtTOzYNcprdqSXXw+J3nMvUW6
feTFAGpJDmG7m4Ygm5yOoUFGAggN60TZQ0Q6UBp1qWFxdcNaSIaq0uWmztCj
4NOp7SzgKxz5j8QNohw97QL0TII/DAY2SFhC8gBfmPMQQ2sh20ehVKFE5cGN
13ny/qsqevyjOAQ8zpM/1HF+TRzKrrKrI1dVmqC3TyZLcF7xkolBvghuc3Y3
EDtg5lmXsO8lJZ2silzBSBbjHHgmQdHqPUbCnu+ux23hwlBwPDQrYYXLrNJY
26Ik/oJWuRWjwAULgw/XmaNh12SZpJs5eNjMeMGUBjqnNoIgMhoceQr0jld/
XmukZ17hJYf5WpJwz9ltNkUewchJjgFbxA32l1JIruAoNNcLn/fEwj7Be2PU
Og2G2KM80SJaXKsAPI/mSWZmdsR5IiZhG87hRNAWDedM7jYRtJAJu3Ynwu1a
S9yhk/FatgvVAFuELpSGzBT+DUyBAVcnc4wKpgsQY5WX8xVzsQ7UBw8aIyXx
cblRsZ+131SvIjDNumiOmMHQA/6QUA76oL1iq4KJmJOPNHqOW+VkEMJJhHEj
XmlyROIV/hpBcyjrN/9N0MO0JC0y3Br1w8QD7+y9bIueKoL/RE5QIAhxLW85
Xm+U7agLNdLb7VF8cl8RBIYzpfnIhlpiOoY7NGBlsOjCtQLwd2BbRfbRUlDZ
6BhdcUjGpuANNkSi0WNOYkzlWdYoGV5giWJUVZgs11xHONfeQef8uSM+Ywjb
5CH0PwYwQho5j1wgrd84o2JawX9++TpsphNK6SzFm3qA1wyI7ej0PACleQ5t
488+UH+8dnao8OHh6fHP6ntnpRmDTTTJkE60mVDNcUvN/qivb9fFJRDtIDC2
/rY7Gu3d/51BAG4Z7fF1Cv+3vxsMedEeMrrBSBCJvWCHm0apQsEY4WscuS3k
0sNvMR042duXl+VRYf/LtFbBY6HCqY7QUXPm7k22FVB1n5Hr37//H8dPj+D/
GOv24HsQ7trrpW1tWLCD36NvDsMlRKrkt/T8r8Sn5L2A4pkx3DR5Hjp++teT
J8NT8vIPn6XjbI6jBylskGzVxVYC/7M1QL5zyQ5S6VMbQmSS0kJ8JX4CzQZ8
WLgpudVZzmfDSXCuXYBA+50tmMIqBuIryz0yTY/haer3IzcOLn7hYzHmHQXy
DMQb5gHTDPvGhAj12KsdqM2nwoUGGoRD6YNlyDvpIgqkTbYzWxZD+J/hDYcF
SfBwqkpOz100Ci3w6DqdEJdnvUaw8ykMRJQChc73Hj61AbbPg3i9xwgog0MP
zjjWe4l8seytRENl5WNWIqnfey+TW72X7lbvJcXhIAtmNy20SV16exosK0jH
26YJuInhC6eatJRINpcXpHYiGOwFXpcp3Oo5itXZUAKO/NII5dFNF6LFxHxb
kvhTikon77PHtUfu36QMxUae/6LUUQXwISjNhu0JchMm/V8CE73c2394eXz8
/PLh5fnTo/37D7RD3Ya4w0Q7REVOkQClU4oJ4qWkWBXCgmCTIU+bVgPhAfjG
UejG8P5Amd0zZtogBu1yLKOiDbv/Rg3BdsONUJZACMK4wiM2mfOZv60RyaVg
tE4Lh2rFJvpcLNqGsgmf68mUssnj1W/5+mnnRHJ2fLsOx3MupARSiCn4Q0pP
HkqJpY9iJjV1VoINg/x78qnHgWWWlWrgAlEkQZBnY7gFAdhVALLg2AjcBmYY
CHpMjEoaJWSzAOgC6xEldCgTIP1MTUzheIo1VtS5Tp5f/JJsv4L/3kGYwBy1
9NqVYzHHWjRQlNKdGFKJFSJCpZzwTrCphDEYXA8qA+zP874l1PUGXjKJEcLC
FXsdi4olWthRbs0mK1aWBNMgCoykObRMp4ZfQIvDz3GknFNpL9blqFxQStUA
FFrawxuwQyPgcVGUJTVcKupPODR7tZ3iZa8u0/W8VEvDWIaSXeWFJi+rxTdY
HLNh1Mu08Eh4CiLcjjqlJCdRQGRhiDoCM4XjCiAw5kos3hGoAaHvV+wpCY7I
O1upMP5y5H7F65bg1kj5sgQtf4PrFszL8g0Zgq+pCEZVLivCldYKEy40As3I
6sgOqN5JYkoM8nRv4vNwfCfHakrGOlno7FKEVs8+Wyg4tcLgWNoZo4uTvTvo
gmtk6NkVkdbbGbsKjsYwafJSkhzNxXpJ8lEulXTIcch4Rb6WBtAropEiJPV6
IEFS2pMhOAgEZWs+bKUNXJGaqPuYTTywwGhuYdhrxHBbAcHX6hNaEywVinWI
4SCWYpT5aP7tSXb3whYcGseiPbilBHZTzjkqkmFWXWu1swVj/rBN2t4UJBEa
jqwHeroKeLm8GbgWYE/btinG1mvkCqELLMAxc/mC4HMbMrVHyIcSBYfXWYje
VMNykpM27k2pqGuTJtoMKWkiEAer+ZR4AQy90JsT38AiN8Ri8jdoN+osx0hr
lhw8/PjRsXhQkzLLl6MGjyGQNp4Hvjigl5qtacLW28FlBCiIXP+Mf37/Vcjx
SeNnvXA+oPa/rkOgZQZYRoCsjFtB8z1hTapAEDCbkTPx7CQAnFXTClpnKNmc
W+JgWsyq9aCyQ4+OYq4yRuPlgOo65r94lwrAF+UCoLQmuP2MAamj9mGzfrRf
U94seoPwOayJhVc+yZUtM86g/SqRIE7NMHSbdP6Gc3xZIyYA+HauqbEZ9gxR
5v64Lqtxcnb8/BW8SwSA5Qk/fky2fBmhskx+zq+21LbFBv6KXnr7QPji4eEB
ZbpuCXhk30ujaIE3IGJhCTMBAsSlGxGFmNg5zYCrmEbGVyNmYjI5DfqlIGe+
GBbCQ62G0UDIEko7ZVIOV3J6C2qRIM7KDvbl+jmFCxXfj6/FtUinYSvI9JZL
TGyncRnKKCWN+MoQRIlPNGiajrvdiMH7Hs3aO5vIM8GId0nCgpqtpU2uVRCN
3JSvDJCn3TWe9j/Ut9kotXuRY2R/2/2h7xJhCY8vXplYv2pKlCPZFGz4W4z6
E8BjmTgz8H4HUN9o8h6UbBSD8EATvRMzSemmQoQ2lHo0EIRMnUSotbSwkKoU
qkVJ2vT+v+6JVasHmyYU0aUmgvmVekcEC6v8j1mCXezSInEpwdxcsp07qNGn
zkcMGYGu0BLKsRSYaAMCdpUxwnd8DoD9ialdvwv7sXOxUZDgoTlhpJGaSL+b
QQeuHHQlKjQuNFbOoC9kM8YiHm/yPAhn5+J4lOGlYMDksxervMO51Xzohezf
HtJQz5CVUc7EakH61P3vHtAPoMgLNp7DDB7m1oQczHJFJcjaXezggPV5azMt
7g2VckLyAVFhW7yXb/OU51ry3yn0N1vVnPlMTtbo7uHUFrXAAZWRAc5E1B1v
f3VdmiPSZu1sM7VpYjuhdn+CevGYUFwCCofMoPvarJ1ARSD7jO/zgUE+4uTD
m4grWEmJXEbuc7RvpT6L3veH+7vyI+0lK9Atlvorl+gTNiUnozd5O2LoPBU4
5J/B+TjH/dqARkUxf4IeFWhhmxDz3h7uJFzm4TrHfCYM/Jq3QBflyQc7LBnc
UpPTlwz1mGShsEDsWMpX8qJjNBm2ITEMyOB3NtydakFIQBUrFN9RGtPKVqTb
0g2sCJ2tCz5Al3+i/CKQfdwm84WYfDFTBzaOkN059aTvEg25etx/LRh8WECQ
4fYNJP4tAu07Nkgls+wGAfrwpFX5MlZsWp5AXXJcTmegoWSeQGYAytkih9sA
6w6ky3waBcQQtC4OCAmEGrBD0MLW5OvAJxbWTAAib0/yagLMigJpatFaNnBH
9iiwzGQFFarVPGOh92yT+YhZRO+e8gNs4XdJBNFaIjLGVXvNIn4R6EdhaJNh
aLIcazCxbDNG5p6949jPHttSJFKc4Z24zFJ29cYKnJgzAgdCohjO5vN0idqq
YM0RThlz9sJyDXGTygpQri5nM9o8hJJB/dsnirK+oJPsOph9+iJixniTxobS
jnpx8tdrjt9MJ413hdPB9yjLOCpZ7DHRNQ2YlbsZB6/sDw8waWvRHoFTXFGu
tSqGp1fmLHDuGeLkE7gGq4nWKyUwtgpmdqH7yNjlfJZrEA8R17CUkEl+KtV0
aXEwJ0ewrkNGP3Vdu6u3DPdF/fiyOwQL6j0hI3feDnhBcEfdCH8PeCCkAL9e
D5yr54QBreYHc/OgFQgtD2pR9YUdD9WxJtXa0UKqYTLeg4bUmylGZmug9TJF
P2hqobOJjMJ5I0hBgkh/VGwLrjVR5ysF7yikpk8tpJBZipWHW4fiZj2yt7n2
WG1DUwbbiqnTVkcSX61ha9SDIWqmYVTOrZuKYZFewDQg1b6VKmdBbmOloLg8
KE4LtzlMfXTIXKrP6U0fhW/RoeVcSKGRaywZWXCMbZAqKI1xr495DJh+GE5T
AxcXFJLHWOOOjXJcSjgnqUqrFRs+XpiCHPplewJxome9aE9SFF3xGlzoTVrS
rbu1W4uvTBl0eonGEuiRInnIdiayX5ivyuV2jVFQUI7sHyvnloYplfNYQuK4
pVTJXLdQjVxu+6lchJ7+fUTv1KrkwMwWFCzCbDE+yOR7irlSq9ickmgrg5Wq
TWfvSOob7STBAbObcZljcQ8dHcOCK+C8lthwSKjAo1Ycu+uDmFVf5gpvhsBA
HLgiNr4d9WlHA/5fwWolWl3omcfh8ObCCGJ8e4uCQrcSrHUTP+bd4rwoGoRF
rmIK/OgPHKyCckKNBgG0gaHlmLebENNbYiCXW/Ns1j86jA1Soglan8EdzWzZ
MO/8C3x8M6+Wpg5LqIvOHSFZdxtA43yRqMm9EdgRqpjl1aDGmMQgiYovGimP
CWazRnteyyF/602hYl2bheN8w8E6D6zNt8ENZZPnEeRXbtUWJCQ4XFnKMy9a
j0M7codI+2ZPQd/xkugBZCtgKOGLQSlyO/ouDOJjSeQryoCjbTvjSASPFfBL
MY9FEdJY6nyeByElM7gW2SPCb+seskrk9GsWLho6WooE+vzoeJBkzWS0w+K6
ma9bbXmzYw8AuZiNpVCfXgDB7fHYXas2o6Wz1As6L6+u5L4GGfqqKIErTwJ8
1XbYspiANdkiiFQrGFBAQ5Y5NMDZ7zPgG3N+pPa5SFrDyCeQ8TfAvlXknpP0
pLyxxQQFFgCzwnKtVkXxt04rbnKuFuyOVgzzt1buKy+iQyOyjZJnsmUgCoFY
6KSp/wxYOCbyEBJ+WNLJcdGmYTkbatGm7ZPyfMemrdFKWGIAtuCKCouRKz1L
6zVe+ggBL2tIhevCVYQnW9WsaR873hz0izlK9sDCJSYJYB4Cw+mqO8YqSzG0
DG8Rn9P6DWrWZEcj9UkmoPFe4jMjo3QBTQv6dU5ROHDjk83yzK83Z09FHrbQ
7OUrCtc5KqWEOaoLFGZLkHUI/xoe/XLxVA1V4h5MZyyLk8GL18ziw5BchdIC
mEz0SKKNhyPKr7jsgC8nSNmQ8LCT2oMmNYj5p2W3jOyT2nGbSUTSB4W4sXLr
byIXK3ZsDFqkGFybiZNAtNCUPEXJkjfF9ZXYqZXnURDTM7Rj1854//3RfSQG
3CQfgJeo/46s3iYIeFE3yvWZwIDHYbpPnK1BdVYpMrDOtEFyNmoFGMIMYlQa
C4kaWCgAKO3/tiLDvdTg7eKmBFZEDbvHAJKwzkPRttvRQJI45YudXwojRSPa
mKlmdahTCk7kG0n14ipLORDa1zMheA6/vh3lWwaEw8B+wygwL0OmICCua3LT
Q2uTyWJIoSN1gPjB9ERtkQNh/8DqPghakwZAeBeLU4ytGcdisBQalJuUqFjZ
vCgFjWO3LkjgQOODPBOUerb8WrS9cPZc0LLKRcxdHDvmo3F4QqDKfHqXx3Ei
MFci70DrJosAWpWvqng6ZPoOIujQIxHUhKcCFCQBI93TfDTkMND12BDCeR/I
pXSVua4obn9mBXTHnH9A/M9b45xApHvH0IwsE2nRDu8j8Y6cfJy8kdcYvcWM
lRwXhKuj6B56JoVjRRMdJJa7ZMFmymR1Spsyl0h37/IByd8TGmObCszDtebg
E2wpfVWES99Sp4F2UKV4dpW49b4IuQi2yBHlApYsacXBfS726NCASKkh9G6A
MreJx/QeeyceC/z7Uqzb5BzeyAwSqmQXsQ4VXZ12Iehrlr9K5arlDE+rcrnM
fHliWRS6P6G3TENLHNfIFOJrz/FIK6PponKVj1r6LccqLTBbKZzdn6jnikc6
SpHho5DKbj4WnLKj05+VTaHPFbSMlz8DRVHA3pM2w/sLMjz7Zv/+A/4GuQB9
y0H1+7uXr14++5e9g937A78A7vaLqoesCMfsXw8exPBlqCIbp40nYIWPUtZP
q4BxK/2Fc6EZd6fDHL1jlMXhAmmiQJuKPCAEA+vkuheD3/o7z9zRzPcPRvd1
m8L7RHh6u8fLh/QVxXYrQMSmmOWBv+U4cMJ94UhFmsJQL7ldGobeGgfSrHKx
MDBeHNxIOjaU7N2Site0cvBMO63fEG54u/RquEYUTY0a8oU5eDYHbkdqq6wY
cW6NHgyg8FB8vVqlqPzpvSjT6gHT5OTZJr52+8SHy4fODAPADMgHhBL2VKM8
i3U4CF3I8L60lG6yujp3BK9QiFQQQd7myCJToQBM7JGrGPnYcS9busBcEaqx
IoL5FBvqwRenX6Qor/OkSeHpkxxMAMDtSrm6n/RspVC6QiDnibavJWG+seig
CIW3XGf4Xt+dKBdEdA2If5RL5b0ilwJzaKA0jJzkXFDaM2VRq6UpqpKSiqYq
3vMhi08ccrtaLMUPaMCXxNelnaG6gPWUUZx+Ok0xGQZPCCjYa64tL3XtmGjq
VmUwD3pm1d7fUyGbjwESY5UNO2WHe2K6aHVxUAzR4WIfpABlSD13KyGsjjCs
ITyI7JvUXOQop+JnJkaSs7vlVgtKYcDNiU1Tqep9TJXp0bakWoOE0U6Dysbh
sLhK1hElNyFYWgQ0aFYsOJZClYohYI1YVXIgtu66RXqogfrNQTiYrsMrbFKW
b3KyZmQUkDPw2bOiJhDWDWMHtQ0bIrNLTZCT8jyRZ2ldLZU5r10E+hNWIeVQ
GsbO/OXk1ZCJ1uI9aC3p+berOVpECEUByB/jgu3SVMsEq3mBhDMEXZLt8oGa
Tsa941eccCqGVDxz/YWyKdMJ7RmWVuihRy05f8FlIHpd6KKna4Ka7sVWXN0I
qDDb6jfOnowO29lx3nRjCVN4w8CK0y3mtqQOlFSKvMynWwoBq04ZqVJMOI/F
dFnmRRMG96Py0wZMdAFx/SoxlDWhEWXLINA0zHRRDNSBnmHsb15egbiOLMpf
1Lh5kjMuK6Sorkp050J0x+xBXGQpl6ABzlISY7GoWonfb1HRJoOdoMFmJEU4
JGIj6+TipvQl17mwkw8JSqQWLzOfo8C4hOxewMBpdWqq8Q6DLVcVStdR+WDM
v0WWEwKShK7uIM2b9QIWE7muL4Ztk7FFuZa0KcEfE1+ymKCpgkBy9Fcz7VPN
+XdYhBVHSWpwKdCgSblUJChmeO1ZKlVrxWdWXvlwcr6+WAuxk+DkBFMxTs9o
4Cx+IEwCrhUywErqzDbELIqrWqMjkreIZ7KQPBedOWG8kACdU3VSKa4t8h2/
gi8H1jTQrYA8S0YBbzDtUsxpfqfm7EmA99ANvsgIvUeCmaSHsORqXJd3wBEZ
Gt1EwdTkAE+Os6phPpYFFVjj+rjsMCfpl1lQbZxXbADs/hcHPu42ekmdsPa4
AituyavrEnhdXrO3Z//+/r5EyZ399ZS/+27/+wfEZzB5wAXswi9sT5V1gyan
nQixeRyHhzKAuexzt162LsCGctoazeMCdG5myO0rLO8zP3HJ1o3NRmEAuoba
NlYADqx3jy3E4nC0P9rf4aZliTyoDWcuBwvlLPJc2uXrPRXoNBl/Dz1zuEgW
zpcQOygEJFMk/VhqoaC0XApaswtV44D81QxUiJk+oRPmnsxDhD9hkuoG9wOw
WggUIRfwTZ6lhd++0jMstWrI1t4dielnGkWDIiuF9NaZKUNBLwmpdhrywvb1
sK9RqyRtrGYrwNo1xcfhdPSSkPqcLoREVLDHUdIrvW6kKdojBkOMSFVRrnih
KVg32n9PTc7j7gTvW890d9qLxNMxhNAFz/qgM0IXofuu5+yOVDDfV57HgSxI
TwIu70OALK6uSOlCtUX4G0XYyCoMUFBDAAUvZsYTJ7U85/TcVZNj3A+7721C
Rh4jMhNhtNlNyjmWofAkCTiDcI2swBN+F55BX7jLNHHcUEJeqq2c5HgdIkNy
3n1KDJD4WSzkKW6AEA/pwB7XU8pu4aiG+kgEccA6TX6F6cqzckK7K5tgvI1f
e0wlLnlnbJUY/U/qlkRw3Dzt29BP5XPOs+J/MAzqZ7zFD0Z9MU21H/nJ3QrB
+gN32DlGt76kn2+VH37WODa89NtriRs09vl7XIC1tX1RgRn7kvhelxlE+cBZ
8vctbuzvW34LtSBN+ypr3WTRrdPWCX5VwUd9FT3VWgfh8WsZ57TzddaqQTNw
zYahaa0cRVIRreNTJ1Bv3FYl2pSAMgWSAa68SQNHXsrLym+kw0w1dZtymsOM
552RoZWRqCGJkj2yRrQQ7NxAPJmM72zXJ9x4owO+ypqa4Rr4ndnr7IzBZG2W
PbS4Boc79FTZRRtyfxNsbIiLyoXFNARahNQLGjEaF67ljqEQvug5HRE+ZFat
bq8EpFJkvoq8h9O0dXHRusDKdNblIhJYgiHmBtGSNSHoEZXPCUlJAFJNXmP2
LMe17fqJ0VDE3lJWNFfNIegtcYy9dMsYO5aQ6oYujDxk2Ly8fW0xBGy4W653
BTjeeV3AAxicsyX7colj3fIXcF2ynMeiH0zDStsEQbmxXCiQdwwWZpnfHjzS
9XMwCspjE1gWFArq3xc2YrJnMMLoRN0oCMMNOYsKqcJNJABSjii+pyKoWlbF
UXMF3xWB6GeuRX716xr9xCklEPqHsLdsMc5Q/nbR1knOiBiy6ihohETNIDIH
f5ugKYHMUtF5lS4p2xBessSTmkJEXiICnYXAcvt85aPoMLnOFrQeunk2ANq7
OeqioAB7W7NKsNSVz7D3crdV25ac99rbfDwwapWJNr+QQH8clN87VnKCfWzl
29HY5S2EFMM70UNkBoBQPolGdG8Jj1E4r7LORHetg8pZ1O0NYh/VPrUFLpxc
ckIVyqQpwwMVRPbS4co5N4qjiVKlLo9drMRIpmaBsdrzOHYkNW4g+VSB+XSw
cB6daBM4Ymltf6dzIOT+JaM7QeJQuCMHiSsMXCOUViviATaGJqpAXwdZ/wpz
8utEQJDIrxDAazD9MK0IBsmk8Rc9m3ckrxNPGiVwpGQNdgTFwFnz1VrOsEa9
tsZ0Rgw8wozEs67mSuPK4veoSuHPQvjsk/C5aCJyE3pTgXcT+cGpXwwimwu+
gEbSo3fKz2G+7iw3MWyy1cO9sVjWMeumq1Ywr2ytKAgMj5BHzUPkBVJTk0lW
UWAx5S++ZaehDCQy02qANlvdQtu7yo9AYhmHxaEQEuE7cvCc5Yd4WAqZmD3C
FjsBuSlcVrzNq7Kg5WYuEJvO5aZNFSE+Wi2OF2WvGmonhqS0cQ5iu1BQbYtg
dcbQQyXJpjNIJFiVI2LVGdkejJMYVBnFtNywiKSr1iqlYp4WptSU1YCjwmgT
ORd84AMoWvlpUijs1flfxSeBpKq9KNMMbxTCviTNLXJgmvQCLWEeENMCn2qt
RbU7fH1xYTZdQayF/9od3Zdf2MTIphXyGXfmTY5rJgF17nlTbOQncRKZrTnm
0N5VyZhpYom9QlmYoPstRT0o5M3BMuIPVtY5cke6UbLpGqUTpplTIkGuZsSm
RGXes2FZSXbFI7AGndG+JogPi6NfXmZXKqLEBMayWIgIYlZUluDcMgkmUgEC
phKPKJBNOGKrs/pl1YXhJsPAsVxLquuAXGFmpX76pTApdOyFqOdh2o23VpHo
Z4Hmcrw4vzHgHmSEsmgwEVfxeSkc4fNctbSmbKQsUt2yGEnVTotqVbkpbxgw
UFGp2+jk+t5WPkdFcX5plvQtjtSVhKeA9XtTJCb2EW577IEjmHwQmQnatn04
uJR35HoM9bSWV82joVEQezoupbueGawKxUe4lEOzZZHwdlqduOlFVuiK1cwE
ME8pBKtslTt1ogEH5VbCvUhrSeUKe96g9O7ojaQT1dh2Yqg3qa40H412hVUJ
nOMMrnI2E2Fnyw+V3IzeQLAqyA3RGMZBEaWVA/Ob5XNvE0TJFB3rbBheIhE1
hEElop8sFst44SjPCJPawnaRAQtuUCsY4bnotk/IJxm7WcQl/onIAbXrtmD0
2ONJcQQbAxo4iCAodJqB/B6UOeU9ubzGTdve2xnYDzx/+WE/+AFkBHPwgo4I
OtH2YfAzsNjLcnaJtTPWl8jntu9HvwrG6aW3I24/DB6YeM/U9t5e/w8a6ri9
d7DhAZYTt/fCrmdSmmF7fzf4FrFmOQJmez+cRqj4bu/fD3+Cf97fkYqvtstY
hOix6y8lGz2ULOqrS4y2eIw/3fsmVJHx52/uRcVm9w/F1PQ4Mj/Cewz5mpsn
s/3m3gObRJ392+PgTaSboQb7iL2s260SG+zmrMaYyi96ORj8p19mf2eyrUu0
EywibTF6MEOKfeR/C9jT4+5LITUHL7FctOmlDinzm6fF9OXsFL9E33/ve10i
fxTUXT+1b3te7qFz7Dbw2Apbvf3dYJLhu5/okM/No9ZL7F7peVWPVNgZfLQI
Ss8bXeZB777Ibs752wv6sudNf1Cj3v6arX+hb/0rH0EvnK4ft0/oY49fzZnc
em64+hLBIlryP1YQSwlF0WMxpvObdF2Tfh0crORHkJfZY+2VqNDCarrbILR0
0qtmNQvLM4F8iVcJG9bToCWfZNNYkDaW3uhtkR2F8BRf41gSI+hk1AtoshGP
VatsRFFnOd6SOFfD6rzguAROg7ZEJ9YqIwDcUbusFg17pNXrPJr+PnUcThAl
D7bPwu1Jmfp5wQRCFXuqzLNTkWCqTO9oGPUORsCzvLOqZoIxEL7kfXP7Dr5B
s20NGsU8rXJMLdMogmVZN8MuAobXMr2Lz6Mvu9Dx155YZHs2S1NQMo4sK+1E
K7byWaz+fM0y3YbhydOwH/O1u+XBTTFlir+WbBt+N2ZgY/jufL2DtkHY3EuR
kWhWEkaixKFRJVGdsmAzR06ovjv2yLRL8QV1D+WLNtwZyCDpDK117FS1Ds6b
FT0KzR4dZPa5xAkVnS6iA99T9P62VkkX1qy83ob7M0wSaGmVRTNBFzNaMRSJ
AUONku0LgShKpRQLQ27cw1pEN/m0obTOaQZ3/w5HBqlxRAXnnphZ084xCTqb
pEG6olC9i8IhBv40zFYVCuwSoilvB2EOkYff5GGttkQ1UsxdKY3u+rCJoXek
26L5qEOn0WQ9PcFks3cIxJwRn+iP1RwlR266SudDBqhU/nHP+/G9w89MToOW
Ws52PITBERZjLFDt4KRchFqYKBZyp3FhT2Hh4WMafxUGFogrlmz2tS/Lor+H
r2txeg0uUOhJVShE1tSQ679xUUq+fstlihFgr7HA1eK3g/3fRUTGdx5KiYlz
DFj7DX7CH0BGPI4iATnEnwXDskJhsV/GbnWvPmEpkQmX9PsEpPjB/v2D5OPj
5N49Wou3yOW1BR5kUtH/eGlCptCJbP0B62Ts/7TpQTYF4EP7//pwuPdTLL7T
RwZhDQTLIQkOlwyR/8M+trL3YHhbdwuMLqGxLbLmupzWP+xZ3/aSSZ5BGMcP
D6V1ffBjLEuT1BQv5yNHl7RliLUrtYszi+V7q+mKth950iVJcCkT7zUMDkFR
NRAO2UEFBmKFmevHJIG1ZgSTQ4xm4qPXRq3EkxZsD2EbqNgdECMKQemgEe8Z
sM784AYh9vGWPoARTXM4rtAZYsVCI2woCAzHbMwn+4MHxvF+ux7bFrTSmq1k
etHtgvZLCaAfBSLSQRhTgJMRzEgOl9T2lpbFYX6HLVtK3dZ6yyWBIQWjD6PY
j5YnfScAHWsdN975VqDFezyAcAoPtNIwkQYOJaAKK8wURL+RA7AzWFCzGgpW
Dh7eDesi71Osd5Lsvptlsxn9Qn9Ok21y6jSyX1QZRVvd4e5YmqDHJxomgeRW
+kpZJt85xzwDT8W5RJVTIU/dH45U93bhKRDmFd6uJKzBtTUPC9QkbYOhIKRo
Cjd5DmyGMCn+m92FnNfA/nLNJ2dINJ/H3q4fvZu0EEI7vA5n9rfgjCvmO0cB
czKRbj0FPdohTYHMxCVC/hCK0NhyMxBu0AbsS3hR2skioxhsOg1AsUMSwKfs
eMuLsAuEqFGa942koAlQEqr2eXZCxEeXHzbowzIjnwGDX4LEx3TbSHkJ1kqS
l3p6qfpoSNTUZTd6yN05eii6NHC1j7zsQtb2OMhXiy50w55UKeIORmxXP+m7
1gN5Wg3MiiIWlEVULs7BWOoSw1HcaqjebGp30c224cg8ZhcDP+Oz+IYv//rj
vyiOvWQEbr7/NrQN7wRWmU3PvH80rpKPUoPabESxxGXLGj4RAkqqVT2NjLOu
5/Euj+hjqI7ABYmXMiMbGFZvUBpejNA99uco/wzP72uFoF53XRbv328qKvOR
fI1aLMV239J0dIeCUto9ZU8M9LQv+Q74dpg0Ms6vrkKsLHIKbsbD9SgqOgMJ
M/YVKuNY9Ajbsk/5ZNQY10kdHrCVCL5QvHrKwQjMNDh7C2COcL5XNdfHITCo
VokcC3MKs3N6tS71VRP42TTn6YVqp8Re+8SeF+Tz4MqPCrGGQel88fHfXjeS
UAdLDlAg10IiF2tor7uDBPfgqy/TKegq6+2auV07BEisuL5oQAoO1hwLx4U+
7papGu736zAnlmGwJR6Wt8REV321Nmmmbbvm1qRil2J86jM7fbV5cgJ98eQc
8wLXtJ8Xnc3Wwc/+CN1ZQbWmwDiRwnE1xCsygNFytJbix90o9VSm9KNeD7S6
fXYiQarX1GorYES0JNDoZtDgjNDWSUecKTvtTu06PWal0N97y1CoKKmG12ra
PNVQNMz47tstw4p3FnNxa7zPGcotp/hUdmXDF1XPSWNzQgfIXVdBXfyScxuG
CNkc5KBF/uZays+Rc1HPex9T5PQWRuY1TyCxQi2J16qWIMkmrQp3mGYp0STd
9WKfEuV1twu6WHk+Cs8huwdH10RWaa1mia7XKWecz4kCtVxAV2pwn5QadHrM
NRhbcB1MMMw5TmWhSAs1qJme5ZRLyijbJ4UG5m+rmORDQ9mpXJUUXem/XvOl
FSTsUluzOcIOEpNYWXUHXB2s/hEog+RZoLwVXNabcmOtETqC1rwesEeRF19M
8FQ6ytnlY2XdSDw4hbG/nCXkxkrQj9WSaQIPcsrBRUD4sHepmY3oXHUsR/be
IxpP7CsLpSMN4icABUsPJl1MGXFfhPIjQzej06gQHuRpIPxNWOVWp2JZtxz6
qA6as0AscvNJqFBY2JjVKt8n3UBlXa8HBkvD8Digjb5leWVhiEXAG7N2rnjT
GqCzoF+BtUrO49A9Kt1OtGKQJbRgjOq7h0IgWj9zQhUqCalBCNK4koZ89bx/
gBc/hav6sAOkYZBJQgAvDzveOwaU9ShfjEOV+vrxsPi4HVLPiaP6akXoImQB
zLZNCNmPUv8EIcUQ7jnK0RZpQkVr1Lit42Gl0QfHsstPRiLxVzhklFUI5oD8
GvSSIIVJyRFrkd7h9FmpEIoVwUAH2T4nhBZK2KGHpZ4D7z9tjCrOAU71jusN
FnlCDKN27WpeoWycXMFiLP197GU7uzW5FQR64D8TCmPyCZs9vD/yK2F8HgaL
Z1IShQLnTN6yG9cif4wPsAaJ72FhLmBuQxkLLEqQ6qrHK1FUWp8OuxhjFJeH
f6ES3nmDJnidlnMfODTtg+aafRBygD86ik+dfHAfKBHr26F8un/4Dz5NxlL6
73f6B38TatDRc60XulFXtz0daISDvjCBQY/7P/pu0HXXD8wNT13v9U/nC5po
jb3tuodHMX0t2HnNWmPS7lFMj4M9H2FO2utskVZvuMhDm4h8+hh8wy2S5UJk
6KWgCQWYEUOQXa5SThfC8tHJ9t7Oo6TjaJSDojWcLaqPqje06J1wqDjDmYyv
Kn4rHILlgHCREWm6rPwR6ixbpM/JC1SEcow2TOD/WM1hjvDQZq8hABfvsv3Z
bH81atbQb/YuJdde1z09n0PTVVDJnDuUGoicc1FIgDw05EseC0sPICUDeCZ0
FXx28qf/SBroZ+Vdbvr4E+025GJ+1ueDMGCg4k2PaEc/fd5o/rRZbfj8YHxL
Pl3W8zmz6ulbY4T7RvOnTesP7FU0re5o6XPXzbrzvALW/Xmvvu/h7x8/a6fj
Zro3wjcfv3Cn49a++YLRRA3w5fHNxzuTyHu9bja/2qL2346CyF6Upb/5nfaw
PZ87fMKp983qM5sJN8LPK3rkjrTZnezv//XMJfz8BtfP719Ccj271mKZ3alG
w/lpQzut7HkqDiLCx/NYMhZBnp5oSeDbdLu28iN2UCyhiIcvZljRcn+LFshL
9m9dYorPZ36ixYZG6jf49qUO8xLxvOo7jgQboJF8Y08Yad6VId6ZHSZ9a3Fn
9qMNhVO5G11+MVvecEQ+g5dFnz5O9lkv9n4iJtbLfT6D+YQL2Htk7ziSP2k+
/Z/bONUXMqovZVN35FJwhm9jUt5tTor4q/O/BjrLtmopm9jV3aVxE8ZDvAM8
Wz4M/j+V9XzGp80Ev4iThiPZ7uz0Dj0TsMG7jO9P4YJ/gPPdjX1u4HxfKEkm
Eb+567ntl+fu1n/4+f/5YPj535sPUqxM1TS3MUM0Vfyf+BymJxsb/BOY3Rd/
7r4jv7VNP79/+VnbMJI/pxUhl/bnjifmzxhJfF9GKQtDziL6FNFsMrch6VgK
0QAf89mnZ1MJkiHtOvpeCtOmmhvillR0j4Lj21098j5x75bmPHI0sWPikeP2
JEyb7XoS1kL2dPbZXeSLjC2S0zYC9PuvGv5x2Krw+pEr8JwTFutzhh6Fpwm5
aChQpIqOLdADkg7QBL21kk4EMMOHd4RlgjoQdDqyuM+PEWLcp0jg03fZh+TV
69NXR6/PXvylh+qChn7yVmx8rfPoh03/+MSjt4/1Q/uLT7anX/3MkQoU6cBU
/Wc1/vcP9/60Kd1tTc9PX5zgRiUffhh2Pnfpqf3kp3uP5nTr6xLw0L8rmz5R
77Rnva9jREbgFdBKpeHr8mvv6/Lb7b1vGulnDn7z6+dZGPTB6POf+zrQ3Bf2
/vkb1/v63ckmcg3CK78enV0w0XZpdiPRciM/tXu/oDXL3i0JF27z4D90h3KX
uX+IvviwYer/Wa9/Gw36Q2sen1o6PX4SzPKBvkqnIeVhzZHjv/Yd2O3n6Xqc
8TGDR3biMc4xcfETRLD5+MF32lPYezz39ncoh1C3/Sy891h8nvAUP7WJUuKn
YnL8YcNWgBR39uLs/Onpya3vb+6/b23uffh775L1E1H/qYwE3HPNtoloo/Xe
a080uGeRPNkrn0RIq7eJQqHoo3CqsTx0TbHlK4QRrjGhDX+sH3lxZaDX4UBZ
zIBwnnTxOf2SwvtMwqFGerNAyT1+cw0/E+6YR9pkuN4oCEqyD30kpd5IM+8+
TxBWDeN9HYdMksN7kayWLFqHa7GNVdzW6lEOf5J3OQhnRwJKBMo+M2mAJuVn
G33dO1efro8/ch/Z1PXNQhJtWw1cp0ESRBDU7oBIas5/ev8+nbwZLuorzHfy
pcUzSYqntCwJ08KINgoXsFidsnLtONbacl4wNV4Ko1DyC/SJOcEvJX7LWnH0
KD2CekP/SjBKIJVWaV/NrrXceo/pcl9YTCJRqUYiZu8ERit6XirehGgAKgHI
bfZo407l7VI3rR02tEjfdB0EJwySdPqPlQKVVdkwxfopnH7WHY1sHv2DM3Bq
2MGBnuFVVVhl6PaCSMZZJ0o5ndaqnEWE8EgDZgUyncI15DnyMql4J4S5nWLm
OkVTaKqF4CcPMUQQh6krtHkZ6YnyTsu4KlIqCY5hnJxtp1Ezn1jgzur2LSM2
F69k8ku0LPGaWACY9L1hxhPMsJxTsHSL9fIosxz1Y6aABcWWwXoqGyXoPYkd
xp5vUm8QCANzuPOIREPue3AbPbTCn2WLW/Qhy3ProbhtK2MK/6xDcfueBdTT
2jNJAuG4H4SPqiSXSfKSaDuXDaNtQCvTFRv1IqAGynDg+E4JGxVsSuESa8WZ
x+Xh4zLl2GhKJTQ8US6VJDHVcFq+roPEDV7pGy5xMi9rTC473LBVkmBQlwvi
8YRmP7vt3nsEdMMkmVv+RhzLNQuSXbqEextFJRtuo4JBD7WINGW9JIltNG5k
l2JaMsEoeSXMhugT398GKuKgTPkluJ4kz46WZRbdOooSbQPYoYh5KlLbVJqP
1V8knQq/4YnTAjStxLKY21HkWhBerShx1I4P3VXy2g78UjtSk5qCWxVPubMi
cdUqxvOTZyPip+KYnI1AkkyiEg9SZ1F2TlSMizFgxqa4KM1NLve4gpI+P39m
KBX4KCHo7n73PWIAchS6DMqk7kDyCTMvtaBNmDHCYlbZQqCOKFZgJUL9iVFU
YKN6y4dbNUFBpeN4xyX8TSWsZkQ+mSAnISa50zIAId4ehU1jfHsSgH5zlDC9
iTIYA9+wHOb8luPvMAsLQvV5Ub1FKeUu0EhwLNzBYice986QLEIdntOwcMTg
Tcfl20yygoi4SPwyKZE2qDUgH/3Mcc+d0R39C5yZLG0i7tkekOwPnnoez7LK
y8pAB5dBJbggE6o7GDhyGaasoBxJmYo+qL8KNzRWZ4i75xWTjIrQQbXiAQe9
T1Y+F7Gv5vuI7c1s3/gbiV1aYoLBfD3qPz0CMiu2V3MtNAkxb6VY8c2lcMfT
bDkv15T7FIAMW/FKaVcSDOlupN9HyXNYJszNQglNVpKfxewGxHhg5lXR7QLD
xSuIoRMIobjmA64htXA9EKoEYpCnBKtQWqo1NovwtpJS0l7nssQiXZM3lKzh
Uu0LthDG9gZW8BdCsOygLxEh+ukPrQI1dHCv5MosFR74vGDMFooZGJdSw72V
QDHoZLKJGoNHP9VSafNoPWGKe7u7u8miltq2K6qLaKlZacMZDjFlDFBbRKjM
MsBKerArAKU15Vc64IXJg/3vHzJbxL8+foQb512+WC12uGK0nhabt0B50gFz
VsGYCRUzPyvKJMGLys+hporGtm2gz3yD2DHcDm6wtb6B0AZYePqa4r8LrJQ8
XGK1ZBQhKdtseF0u8SheJ/UkK4CoyzqsWUxX7RkqY0VGB/rimsh/+6y82IGz
39yU1ZsaW0OmwWNZh9NA/G/MfUHl5n+eDU9GedbMhqDjD5t5vXcwzMtmKOvC
aSg4sJKKdbSJgpg3zsWSvmAQuqgjXJjXWTon+0hQ0zAcl660H1gHgx1BM6i8
soB0DM9fX7zCscMu3//uwSEC4KZ2R6qlpUTh63B3d1Frqv9ju5YmcKRLESUV
72WaEZ6GwrMX2RDU2GQOnKuYAFtxpOmEkFrJPjaO4HA6Q7/dnGNDpMpCrEs4
sfNtxqlJ1i5LAMbDDCuXZebe87g9C6hPizQkZ8ensiYPDw/vf/zo03MoO4ke
M8nXI9+aFEhpfywj7Dh/5F9fXAw6bCQ45nuj+wZ2DXuETnXNHnVpvxqBU+5v
UFKo6IZaVVQJIuQdfKOmYR53qDhRRZV2jgPOA5adwXfcOIuVrQHyG4HdyRdZ
kCJq+O9yA3AV4XC2KOhSIc9pmy+Khpg2zsSNI0Hfps3nrC+SnabzrMhQMhLO
xkXv93aDXnpWorsjUqWQYT0cPyobq1w4BEiMpbQOKmNP7RUWYBuSM7AgKsuU
GQhHE2QDLrjtsPJ461RTSgznHfPZgV0WLHvPF5xyxYvjV0iy/+uXs+MIksnX
4t4b7SsAELucucgDtL4VUBthkTfXWg2Tx7JltSEGJjiSv9ndcnFzvn8KJ2aS
iXzyDMtjapDCOaZQiw+8VZyqQCUgnzfDvAhblnImlDhImdb878dOVwbvzSDX
EdesrleZbZqHzMtYkEdAGVzikTNcDBp1DnwGlmbAF4e9NhwmBNnD6aZhNU/4
BeQZFxcCJfsnSsFtDS/l31VF4NyhonEIJFdMtChNnP4pl1SwHphmOM4wACKh
pKLsao1QJaoL8l0D4wyzo1WrVZWB7ijUgjyMCOWvBiwBrz3Na9JAtSQwjmJp
eUzz+nc+7nC2V6KC+SICEdytz7kKJDuuDcQwQiHj9rhYzKi/+36fLq+gPReg
0Cg7f/jd91LllL94sPvgwUcDwGJ9kFnFlgAbh3i8q2q+5eFqGDLAsF586Rm1
GBjcAcz1lyKnKruvpfxv8gzL8pagzm7/8vpZvUOXEEq9kdIYTscKiXDmcpCM
TN3RjinHU20qRICI8APCOBT1jKjtiABuUDnpBSOt2/Eqw+C9sLI7VwQVzZVo
zNdrR6IsNUt2Qz9s226H75A92EKEyBrYihIis1NPlJBz90fJq7gvLfCwQot9
I5NwzjJVNUdYBrxWRBlB6p9SheCMixixXoHl2RmLEkUOrQwORwDrewZvxF6p
ugVcM87wIJGo2jbWtMN2nvizQtZVg8rn6hppN9aKq6V1E5Z8aV1EPLhlrAQm
jIhCJMFNucACiH9zw3Pp6sW1iEgBi1E0iEhn89awGehiXNXLVr8lhKjRekqa
HVU2iizSiuohFh7k2c6THtmX6D4g0wnKiSjKKyIqlYWxxSQxm46ZjrpDmJ5R
Mrf2Kas3aU5aOrmxiLfJcDtbQ4aWUfIM5FxGOEvdxgFs3sDuENoL5nQEvQfA
16BhMDnCN+TKDJjo3Au5guBENL5bwvdg5n3Re/4GnFEFXBmaocoG+B0Eya+S
xhqh5PCqiW4lRa0+ZQSvHkbWO2e9AvLibTnHo9dlSChOUImraV4ZNW9iknR3
E+MdmmuADah5FQD88dFydrSs0jgBO5FFTi9OLPPBdESWTfbexMYMswUpdpEX
mhEf1GrWDzjxmhFabtsTL4BRiWjvcpBSXHLRtTfag10hjqgyR1q7aIG8j6Fh
VuIingp7eYzfs7dqyhxlgiWJCHk+YiItFmVFHmdZNsWCwd4H5JFu5uUVyMyq
s0V3oeCsB3huUuZakXl8DXr+IXr9k1z58w4x7a0vvhNINtECaw58D9ON5oR3
Fwl+BBIlgCtazAiYMJGkVI3tKXtwSfUf0T2DKFnAKTnWNmKTZnFWoaM7P+en
xU/eSjyCZ2FDnwJ3nmbe/9W++y2k95pgSMZGWYkWASSFacPV1rsWXUg9YkMC
3NNJSaVtMyuwShJAybc/aLtOErQxPI/2nBcK6jNCNMH6OqzvauVEN8JlocOA
HkF7K1l+zLJG+1k/ChHhBm3gMjrBroVbhgMJ1COrolNlCzTa1xl5x96iMBTV
Y2wHYaS+ylv/KvVZ+T3UF0fVICXXWNQs6wdRu06nPmpDCqsyjRp4lwmopHSk
c5QTmuvFptpRh6MDxtIKvulUk2phuTLNRJDazxA+L3kFjDB/55w29p3C+yqu
g2yXGoee/vXkyRD0eRjAkFtA5d2ljMZHAMP5O2xhiwyRyRYbWkOUYnSO0cPn
T4+ePUOH0daUHt7S+gCwgStkopjHJcBVODZQLm9wJU3UR9ow4vQ2ETO9Feik
TPM58STEtX/s9XGNgHIhBb3JsiVfZKRhzmWgpDjC6UQWIJA4VO42bzIbGmv0
FCm2RcBWyM1ZG1a7LSpJW/i7nOEjQjXzR9XPgH+J7ix2jkW2MqpTOWCvmuJX
rV05mawqLwwz7ySvRFDRzR+gXjA+AdO9IWZGJZbTKp+vxXyBpbRogKILGv4g
FwKh3/xVIYgss5nwaInkDIFnqYir1UWtw/oWTS+i306P808GI2VFyYaQMnIR
F/RCcCm63u22GKfT+NaLa8fNQVOeu6DcG/Ns5tVk5wKJnzQmdNBRrfSG8GFC
WqTFkKA72kFU1BDwyk/v8YYSDqhi84WBxrng6qImI85X51doYc6qCjX7sgqL
1E3mJZ4mBXxT1RBbglssOfKlbcRufipF/DCGgAH4ahcgCLMYO5Sbd5nmFQOl
WZVO9G+QFRCDyNiGCtIY34ah0fo6XcLkTPTEa+capNp7VAnt31YgNWaNj67D
QhzqcxYBUgRqUgvrfM6bm2LpCrRgFlGpPmHnhdSlx32Uosi+wDeOwEAHa6NH
MftW2bgssYodsSjqFCeQmpFWVoRYPJ6DFiAyeXN/3KUaow6hgtRTYFIMsJo8
e0uQ7YxjXVhBxagCEU5HCk93FowmmjeBAFdoz2EqL0FgaklYBDkzOKHW0Klq
iAJGwoXUVCVnJFmpx3Bk5i/XvbkmS8ICsbu4LmyF16SaKthVT/WapWglSWY9
5S3H66T1iMSNeSHJxAxFIuUnuR4nAeD1RBAcWUVNEvFdx42+qZS4gF8zrVEM
k/hlovVAXDYE96XjsarDSwxtHVLVs30CXYgaymiGGpEVrp7oGiRCKHYgaK2z
4TJtru/BIUcdyaAJuTo3b2CLoDAOscIorfHaYjdAAET3S0Aytam4HAFCFm2u
heUPZhmWKhIVJejJTCv+EsBxxc5YC9YTGpI6vShkBP4wWftarzk56KbuFmHY
guDeuRZ1UzALxjNJddJwHvDaXOGcfTlMHT86PBQLzGZSVqTvQuc1g4FhTFiF
fhtQH1D2whYEcNTkj4EGxLTNGwxoiELF8dlJbaREMuL9YbOCp6U2cLoYA+sF
kiBBD/g3xybAnf80ZkGbUwe1eIxaSnPhPtZS2mZnGGpnyJApVa2OrGAtgUw3
U6yDhcRWBdBlTmUoLBSveldgYsF0C1zp/aj+rhxHsjox2/T1miIfh7y9S/F1
XAHXzKQS+bNPwI9ikZE4eXuWs+ORF8lm+tZn5Dr0fexTYXQLGHeGN86Rhhp6
j+aBK3Y7TtFpOlefHZWk4ipAZDPnU0emRCSSfIKn/yYLxMKhOJ+VGhnnuFbw
fgfHAPFh0X+UbMko97aYuZHvaOuUV2Bg6wRyZTMZoaj6pXhulpXhOBHkri/z
W875rdvwCCIzxDgV24FO+ePuzicyof/5h/7xab+3v72NJ2Gn9eWXQD9Ic62h
3+1t+egW3+HtHviHPzLyvS8ZeWhq+gN97+/cjhaxGRxBD/Cdeu/YDv7I2A++
cMdVcPkjfR/u+MO21302OGzItn/7BCbHJ1f54Atm+t9xrv5fdjJuefaTW3b4
/92D4bz80fmE11C4UZ1971mR9v4EA27P/0u2TgZ9/4sWj475fgugBWSaIQUO
S26kiptkHOiHllVlCl/D7Ei0RLDAwbHBIpCC9IVPv/8qwNB27giFmnxJ4ocP
rtUmg2wJKhptzgj4W9rDODaUwiNLnyKhk1ketMlgmKPkVzUJsELA6pZ3Ersw
cHoY1miXageznK1OXnw0v4eqFFT+SLxwVviKwkN5cI1ORiS6Zbqel+mUE1tY
XOUgt9lqPoPFrlnQq8q5VZ0lZaRdr1PLSWkKAppYcfxvJai2yZbkK8+8Rbht
Wk7VTYiqzA1WAiDbO7aUcuYjR1KuKjVpz/NZxtHQs5a6NpK8UnHH2W5aeTUu
PULmH3O+5ZIWQq7lyKaN8jvlMua+5p0UI0Q1NL8q0BzBTU/DZaRO20kvGtXm
qdoK8uo+T3wge0B44e4+omP7TbRn27s7Wk2OlalVYcXCg2zVC03J5MPbXFdZ
1vuo7vggKdIFqruRpSeEFeeWkHI7+MCjnnHu+XGi+mH9efV3ReD4BJhPZKSM
lswNEsrEkHHADGawYMDMJqAqmnqI5n7qEsML3+RLArSf6YxNbzSHcEm5HL5K
Q9+w9//YsP/+GxP475em83ZGb6E6oZ1aSN7GrmGbgcFB4yP74N35xS/BeA9d
etwKO4r51FPsHoey8LIH1WdbcQRGbMFSaa0nDrpcVmw9DSLxZW2Il1CQj+il
4hucWg05G0XPnh3Eeyb87rP3LFxu3b+//34ZDLO1hZe7I3Y2IReTkXJ7fT5M
3bZNYRdqK+YWNsFM7fRN/BA3iSuv3mUJcNae0j5vyi+S7Rc/7WKlwV9q8TJT
6DAZUVr8MLWAiwRNMIwm8Il7S40kZIMuYK8rvDj1NkuDqJCWrUsqCDGchiZl
Gb59MC6HC8NXaFG2og7CsWnAXBBvwNZuJ4WZcvHFalfU5IyMMFh4mkbMAYve
jBWtj9SPvamwKpr3jrRcOeRBc3itUcgGPMzGc9+SryYZe5+CO5KNc+EpC1zw
7HjqcRR/pxVD9eaGdgSLC0U4LVFigprYp6JJYhynNwPGtUj+MND/F1iFOiah
tt1HXB236wqBuP4ln88yC7Xl8c51+0V9B/PzJp5boKiDmX7e0mz8fJZFqV8J
+XKdnT93H3kvlukf6Xv/7qsWgsb/1/Xdhar/r553cnfQ6819e3tctJzx810i
x1d7VyL8PRjkH5rtZ1oNP4nI+kfW6sCv1cFG2Hz8dNfqS+0qn2XE+1Sdhj86
6c2vn2OiDOmcc8r2G41G3Ye3KSy/W4noVPGz/9DS3G4say9NBw72T6KHQ5ds
QHDFTy89/MFVDUajNp0/tpC3G6/+U2ns0C/k/TseLHi1Yzdj4epWw5mPFQnz
jthqRgY5JdL3X6mHkeXDwJVqagTjyIJmsCxzttOYYUXxp5T2JXXHSeyJj80C
Wd57VE3X8tANI+qZAwJcX+1WDCFBT2NKr6S+DjIFp+Gw1sts4KTexhStbjjY
i59Pkm1UOMsaYy/27++IwkZu8FpzCwgkN6OIhumUU77irEdfNDJ0SVNOBCoJ
dcNZJU5ya3woUFi6FpWFzloF2LUgQa9AxXkfohDCIy+4+DA/fyle2R92RyPW
9356TM9/xNE8prZc/CgWJk+tOJ43B9ZaRA/n3VseNEw7dYZjKGmyKOYrTXQ2
W4Jy/J4bggZsAzSFuX+rBaZ9kucYVOcqS2u2e5AttCc32CKIQn9+dyrdWN06
CcpyR6BpHLKRFa53oKPkJc6Ck1mmWTqdl5M3tN8YWwq6y1EY4LA5t4QzDTSB
pm98tqRrKz6pgQyN1oPFsTbX7TrFvmTbCdmNYrodcK8UBTGhwuNhIjEm5GKi
I4XqCJ6YhLb6MLl2uVLJScWwCgxufIPGXkvd3WnnaoQRhzHESV+5PIlLiEM2
KA/KJyh5OKwYvWm7xnjOo8mEIk2vOG+DEBrtDQnz4IBUXE5eEkrtoPjtQAfS
yG3Fv3GR9SzYnM5bYmsME2mphHFhtW4bZzU12zSOxJVOKDANQ0poNzBsbZ6l
urs5I5XSeY7B4jQVxGfGBohUmOhmFUzbBOKT3ImBUSAM53oRAoeg6cRcvM3J
gM+WyIk5j7hejf9B3oeS042n2TxdM1wjImzwyvu0Twy01PrGFxy7Qsa0uo9X
tY4NHg45NZk/N2kIcrBcJ2Zn0uncdmSsVw3TtzKO3pQk9cwdaOKYol0i58A6
khqkHfhdJDur1jsmSvny1wkt1CSVqtAcmDfloOyghqzC0dfLtCB+Z/k4GuV3
WxychXQST8AfBPSUVWvcn4hyC7SggYZDvg1cmQYhO8PUXKlujXc+1Zic4o7j
E5lGA1l9S5sTtCXQMPSQi+A0kO50Tff5SMFMJWeOWKlsxFphOBjkqHuahKwp
4Gmd6IGlTaobp2xQvUDUiKbSUWiu53Xj6FWQHtJ8juGgo/5D1XsTtPr3jbho
BJJocS7f4fnUkvdFB6GVgsXRBAkHoFpxaZ/caC9AerLZmqMywILrhOAXstWp
8EjGxmzz4LSJRYLbpT4gilkK93p7k+giZh4Bh7jKAlQZblYKWqNMhtuNaCLs
hIOZ+WlzRmzexoyx2MG1TY8RWcUjcVMmk7yarBaSxkt1Yn/VPIjAnKyXVyBK
+HPNODMsuaB4ozHJPhhRYl03XuAkd/DjKB51X1jm2cT7PmUz/e0fDjpGGVOk
hNSQGQhuiZ0rPrrVJTZZpp66ha+A4H+URcixpy0hF15XMRfu4a0z3zBFCF6j
SEMubPQYIzJtZvAbBN+CVj1ELUkF3gRvn717h9FsO8Cs7PygLA32YDDWm0bT
FuHo8xZhNgxzS/iCjqMUJP0lbaHQssTPWLQ4JO5V04OQctGrAW2k1TiHEaKD
7C/5W2srxstSUByTr6n2fOgwoqrcxnmoijln/237QuCIcEQItLhvsgyS2I4S
BK7su3yRRsHMPF6KVbjORKQnlAngBzW62sk1jd/AGYxypXxULjEdfhD5whA2
HK8lxi9n8R17k9/sR8XF5lDjOMgXlf8jreMNUk6NcCuoVeBBQuiXr2sKlbCX
iSOtfYobBlJthwhWiIg21Oc+fnxs3owHo70R2ecIdISQjUpCjALZhI4IcZ29
ewdeUeqDaZTNGdhVrFICwS4DZxFoMhbcA7HWxRAkZxb0T+KF5jQaDHMQSq09
xe1FkoSTYOYWwl8gAurd5okrjG7nziJAWAKxeNoS02tR203I2VCgmq8d0EwR
Szf0+AgmMkvjX3fcoV3XNYqugZSKGpWKZIJPVPvB8eo74WHq1tOa1CxIjDO7
DKbhGowYL5yczHUPqp3hGCBeBG6BR0Vgb5vkk5jELN2GkJW55BrRrbZiRQqB
UMebN1azf3vnhIA5WF0bdTX1sfkI8FogaBjIpB8wgfGI0H2HLk4XA9RxdpGs
lgrL3URXvcUQL6ghnIKSMh0rGheH7YTUAqNG3FwipN5T1JUTcPFDzT82ZIQ+
XHQi470SgVmVM0df+kopIha221yUfIWwIsToA3riN+EcEpoBRgEU6/DilbwG
VutmOcLKimXJ6xgkHtNmRRH+NAojqMCI55ibr2rBVpDcletUsHrq5YrRq2Iu
+xj1AEpfRTileQ4sDQ1iG+YzS9+SDqHJULrOnNRgppPbQSx+vc7nItltiniw
2leSpn9Pk+a1CJagRlngjiY+UB4pbZ+wuxZqQeqhPBTvxifkE9P3v1O2lOIE
rPQduhu+5n8qikA2/doPpZ+ts11MUEB8Hx56wRsOUPb0YEC2JguiT1rjSVXW
AvbolXjkOGZZCvkgnybdKrzOinVkHnUB4/abUVZSGzTY4oBRrgqLHIniGBSA
kpMQJQVq3KoKEeA3C+3Y8ok+n8iRCRJO2gqs5mg6XhkTyYu++Cdb6RjxlrD0
09CLPEp+jlKFCNNOknJwd3pjq/yjdTrLWswjZzh+XAoaKEaOpAsYy3THikbI
TGwVIoDr0EbVuiKCaiQYuMhyrt7qY4JozJV0iP+CqhWljONdnE6wtQ5IoUp5
ejsg7CmNAu/+txp+GaRexZlXiuXruRgSAGcKvzbT1K1qbJhnSivhdVIhDZWk
XWjS7dbDCM3vStBkc3Esmt3gZRapAaXAFS8UPxMEoVWzqrJuKpovQSCoy4GW
PM9Sybnl3EuDQo91ZtPBxO/QYZ6uuzgeEjNAV+YCDP61Xkt3nD2XB8AybbYP
6he0PnkTA8XUmpucF/KD+iy4skg/CqCfIYPpRUJvb8UR4mZcnaGvOAODKKXe
kNnrGGBQbI3Fcmm9cY3xJsTILZqbhCcRKTOwg9M02E1XKQlMUeq1qZiONBPG
QVQLskXAcXbnRKLc5ogDEQyLdsx1OfGm4i7ofEAgpGlCKOODtuwf8FUvGjm6
+jj7VAatUhdyjSLhhHG92trjM0mXgVpUvDUcIbXyaXfMBE4yNNckr7UQBN1h
MS6FQhp3zDEWjEx2GYwtx6Zahh+qhwXEi3B8VUlKJ0O+DCNnZSyeew0pqKXF
FBxGp4mOxgyX5Gg6fR4YsOUxLZc8SzPmkIaXKUsPTrHQHbUZ16zQZhFu1qWs
lVHiJmUn4N1XavByGx07xRGQs1Nj9WPV++a6nNu+dcnaTOYS915r4PuIzUsG
mpJ7GOoA7NhpUm+99vjTFvbqAa4Z/bYiV3WVTvPSnsbnbjBpOq2dPc8Y2L7B
YAdIGmLTDiN2k5Ry0d0ipVwGCudVp7jdYopIlmt7AJ3FqJSsCrIZEGYsq7Lq
5GrLJ20qCDOL5daEZXpCwBbJ3sHARc4tJcbAWCp9yuk9TLYD30dzvRm9j90r
zN1yky+ajlyBzeXFqo33q2B1ncBjhJyaYVw0HkRGZ0AhRBDV22Q0AfFC+AAh
nyITQDk3YUG3JsBFziRXOB9PVi3OLhBtXTkaLqw4u8OsLZbgwa4yNa1TUgcZ
mhjWG09brycWfy1KD9XrIcpsFKaqtuw5qClabtAsnWDKDw6QHSG4nQW7+HGx
378PvyiuMIr2Vv+xXQuaV4QoBBTFXVbOl3kJFssDadi59j+qPyyag/h/4+AI
LDJAmi37l4hxMRuCM7ZDbjTSqTSf6R7dYUFK06btJRiDjQHb5RxX0nxtReTF
QH/hNt94hl9R802Ik2U4sVDyh5Ux5YhiQIBcRLJCTXOxbMKErua6rH00i6y4
BW9LPbDO/jEcu9fUxUGDAdl6dDW5hxraYdEdDRsl9y9uTAbARq5dzoaeejha
RFa76WaWiUBqYjEVx/I7zs5Hglyw+2a8VnHH/MecliW8wL9N8muUPdXKjFNf
P3qLpLaMgbhDH0PRrFtvCZGGXBAmj5swW82dh7xgD4ZObaWZB3YIfFw6/Ev6
QuCxa7w8g/Dz/txCwQIKesaFDNjxSg4+dslnrr0+AfdHJ5D5hmBVZnN29WhA
jQDSzKIw+T8cCS9RQ/eGn/+R8pmbq/j2fT70vXQmWTPeWNz7UvL3O4zuHubL
3jUM9X+HSNL/ni3oi6vseem/YAvgFTsXsKTb3yZtM9rG95ODT8Au/Ofv4ZdF
mdJQJm9u731T+Ha8dj0zsmjQbpt+Ce+2cDrocKe+4NMaOqxA/3NdSjn8b93p
dmCtvzV6I2u9/CpBtB64NTk78aJtZOYLTGkSbphdlYQbx5aBLZ+edZlPQ3D+
9+/NmYmDoxH6h4f5FFOoJcgA3SyOglC9DHgMYzKVXON3ooBbCcFxpPBuQLEN
QlOzAgR9H5g6yaeX5jfb3gVBBr+psQLw9h78a3v//v0dCUsNW/4Fm33M214u
U+AG0c8c1PqQYlr7I2LDp2vstBsI237sF5EYqGceUmu+EjULrblHcJOxWlGL
NERmAgLP8nGvIiMFC0saPi8prBp1FrWldRNVZKEGPc4v69KBMxZFtypztKJc
5HGlFgZxTWxFe7AlGIdUeHgWduPUwNPpYybVK9ne6W17Z6pAck9uy/ZWexHK
M1xBaEipDoVZ6WwEp2tcwXE5lTDhqF6QCotDcXtNeU1ERhI1CqV0stnqQ13j
nxkmSYugiEIaqwCeieKwps2i/HyQSan4Gzlz2YekMbek5LwDoZBeHgUDN1WM
znEct7gJAzoIr+2JZpbYJl7JaT4V95YwiD7+4MuGOMtfbbOVINxWbfS0KxHK
fWvAPUUGI8WzrxzFjUbPxF2FTLHbrNYp4UTeBDTSuShKM3HiV6u5atebEllN
P9xaFRpEdSlLvuUI1nRzXSkODPUcMiuyEPkbA8/oVwQ/5MrpZn1nfHM7u+Zi
X64qtLeh2QXfEuleKs6gkz1fSp2J/6e7a91u20jS//EUOJ4fQzkkJVGS7di5
mJHkWGM79kpKsjM+GRkkIQprEGAAUDJj+wH2nfbfvNjWtbtwoZw4e3bP2WQy
iQn0BX2prqqur74NYf4rWGAP8O7rAsWZiqiOQRcxpW+CfEE/F1+aOSE1i0uM
sBx27DrD9dmVNX/ic9pGQXNNc4IJWtZGHNigXOmWSLYch9JHkQ8xAVJrL8mB
dUsKf15nNoWpTgSKJwJdrDJJXoI5cDnoAb3Xkmo6iF2zLi1Iay7J4YgH4ewa
PXroJjJ4FwxXFry3Ukv0/eGqcQ7IITLlaKc+DqUJR6Aboc2p4s0YXpKTggSL
Hc6+SUua5dxnzts8tMMK8kz6SQMmvZEFgnvsVv4KdFjKlvPOCpeykg3uKLxT
5fkFOoNoCXqF/k7Y42zOshwPRluh7sUuMcpRNCz83O63XBoVYyGaYjEKDkmy
XN52i9iojdYQDlpAR0mtwplHzkcTzIC7Qdi0ZY0TNXjFUdcGVXN8/5eazjYQ
H8RHJCmm/C/dngmlNySXmQ48B1vj11NoNUayOCYPF3FxXus8nBmGaYoQ/pfC
cRP8LgXThbfiaY6aYhPqYK7TfcaZ/0NEv4Xx92oD8fXB70Xz/zEj6n8GkY8e
fsxWvFX7hFs62fVxX3Adn2MEfh64vtGJ3Z3/5YR4vh+fnt/uvz4/Id6fafvP
ZrT7M227vz4zo12zbQuLar5jl6uuj/a3+2euS/6nW3pwGxQ+RCDY2z/7aU1/
g3nna/nrm9/ZV33fd69R95/sa82VoQdKlx8Dj5TjGkoYD0b0acCRyroF55zz
52MluAIfyCDefcJ3YQS6I+yr7BkcmRgvrJfuAVsfjoTJdKtaH29iMa+FCICB
ViSMRvbRPUx15PJFlVCBBFnq3Q2BUV2uM74Ez2vAVnvcU9ofDk92xFmRZ3ii
UE2860TtN2MOVL2LsR3iTz2LoYWEzSKOheVbr8A9ICYM/jw0QVcU7LcskoUE
OGb1xDvndJOCT9cuJV+U4pU2Vze17YRFlAh6W6GbpBBj7EScoa8eg0VB8CfT
GF/yCmOhLI9Y32qx5BR7UovC8toJ9mcU5kGBB4HL1oScHIgJa7ZYY9/pyuM0
ywnwyrGSRA1Rb42mmwyA61WaaZxxHh7lZ0yOYAnDmHqSDjlXfeirj1u1cyxj
QC4TDImhBPgh7iNKy1hyRLeqqRg+VsZEvCZZywLHJ00Mm9Snc43vaPTHmKa+
K4HrikcTMH5jnudEgFByOkahe5AbLO6gxnWXNISwQq8oNopdK0lhKcihX4dC
/al+omWB0HrJOAl6XtAcHE4uQJFONlKGrh8wrxRHUFRJbAB/LrchVeUD5vGP
Az/sMf5HUi4CprHVIAxYOrRHujJU7WmGKmREHR2MRh8/UqyQaY6+zJGgGAft
X0vcRwWHKw6cJSCBtQ4CzZR1a/Kt1aEPuIEJuAeGPhFFeZBZKK3LgmMCWmT1
4yXFrA2TtdwrU3llLqrWS8HF46ZI0pJQNSYZ2vQqhuXohBlmQ0DgHI4+fYh8
t0btC3MJk1jI4mCplsznCHTHfqwyAwsQ2BgSTQqiB0F3K3Z/MgdgS0R4A3vC
8LHCMWpqUATWRUwWGllw2xrAO+Y4ZYkRc5412EjwFdMqRwk7TgVRYWaaAKic
XNMEvfDFvmPwLSQ+UTk/fG4HG3g6iUN3vc/oRZopH+5bW9IBQZbLFSZXI8OH
jiDbqlXsJSi7tAkGgkrzCDIzqaecpv0mTlrDVqxhVRb5RMd/mSV0XFDEli5C
DyrzKQAjXDC4HOt4EL8Lk8r4qC2vBYh39cwpMQfobX4V9t14YWhFjpg4CzWT
oaO0sRoJDSJjEWVEvxOYV2mXuYVfG/OONUM7SBYFObCxQ4HyjJQEvR0wXC4q
+6HkW4T3KHRpUFG800D0BRwL+hb6WkcuyG2bvYWfwbuQSQWZsh02cCypBpiJ
zMcw410T14lkxU7GKe/uu7iYJgx1m6+IpDB0mA+MxM2Lt+x05zQZ5x3nl4OS
iHhjcSOqlQe9t1KLDpkBmRVD69MQMlphgFXXmNTO4HBVA1z1lsTmEfnWacny
LdvMFNZUnwTY8ype46OCWQdaXzq8MXJKr/RwocpQ0JFdCle6CfDCM0chOxKs
7RI2uMIW28cxoUIswwS9NWqdCmTgI1SqWXCK19I7YWSNWtTfMDwGxYIDjoT+
qqLcrZGLuYJlSn7maIbaQyS0zgwhwyjYAUZ4ujyPeRGIOMH4KgpEIekvCo2o
Z9CRwkl8k0GBxhavtgKmrYWNFlG0eI2gJ0LBsiIGSh0lHnWKKwp7mPPEAXME
PBqFP4zRhpgk5CPd4hHHE1bSKoAkxBDkfFVyQohAupxQ6M0UM1QUnrBOoK0a
eV2uFwv0ySDoq4ks8oE6yW/krXJ5umMi3ZVYIz6yfA5P2oIZDD5ywkZrmWPF
bLACHsxXEZwlVRyXdSee0MUyWBpG0tENMkSKEksLCZJs3OD3tk9teCHKxVu9
JzNIOYr0Ja7JvIUpXbM0ecs9auypfldq0homU1zeAW0r1m8cBuM25zLKMBko
B1Bo9Y0GdGdwen7OVhdioTkZVJ8eGU64gJYQrmD//iPMRu50xgc1dsotNW68
1MxcHHcA+3vg4uixUwPTKXfw9NFBO419qicNFibpFijiup4YRVdiEWuspKSD
x2bYYigJJhbc0jKLz7wAZWiOHWa4dya+da9NLeK44jQOtZBJVcVJsZXTxBmU
HJOcXEfTmlYvpzD6CmrLHGNmweQmw2TJfPBRVU8ta94fsX37ST+0SWHeD1zK
6TImck0nojl1A+ZFPhGi62YIu/GFq3tD/OKaeRjB7A6nauLH8Rb9EoToqvCo
Dvx4Cdxrt6gvEJCY3RYG7K+ugqs4wl3aAzPS+1u2hoEzjLEAsx+66urZsONG
VTwYpaeHE5ShdmzII9QIj2/kL9RVGXk4uAln8Wo17nN/vIJRwPdS9A5eiGoK
6MIf4XKPSDSPM04VhGKzJoG0g+4U5VQxnnS6oYwkqCpex10LFa8sqByciQvU
4acxUpDmpaAZmBzMsT3rCPPYZK5JxKJeiU4ghzIyJvKhXDuFKbo39XfWi8Uq
k5M9MGRccJQjsJPui91dIpyd0MaqqDhvGn+LnHO8xkhIkJbCEbukP2yE8Jqo
ZvyeywIxFHwLptfepMWI2kY8pUYnI+Z5ZAjtVUahrjH2BTXGPrrV58jqW0nZ
Jae2yyzI+gXuvvItTai7lqVc4F5zhjfznH1Iq4Tx7hwxUtp0PG79eMnHKiur
9Mjhi51DWa38Zr3374sshnPAEyCCZXyNijGB4ghEtm4pXt609yNdWwCKYWa3
V6NRB0LMTV4wXhGPRGGUtgPm8GNGXk/T6wvxjlAUVS63gxTCoCQU0aSMFR9e
70nojZ1heAbbc0qkrlSnczAgoTqGzPDoEOAqZgJGMVD6IIHSZekVyva4BWbc
4GwzWa82dqiWyB6TwHlH7pHXGMT3XHiyaj56OOAq0n3Ng1OgSwyaFz2HpVmt
fRa7jk0Cl7vxH3vIcDRlaD8Z0YayRZn/iBGAZZNbFqJbNqwMkT+WZ5bkQ+Cn
WLBPvD5kkbshkO7Z3JIeTI4rSeHo5LYyKC+2ndzhYD2UZOUYLIN+4FrVN8Pi
6xBeFic8teny7BalgzZrmzHsMz+U6BnWplRTCIIz+rPDkWQVe1a8zu/DYDQA
h44aWRTYqNTF84vZ8wLzMk2FU0zQj2yQbpSNLBVcJ6O/BE6LXthAXQ2ipk5X
JD/59KU0Dgm6QCrkuNHm8OSRafyhxpTr0h7woZDGEbvUIoZZxx707MxirOQl
nmTj4/GR8BewPChXS2wYoUljf11A6rPN/e8y4zExJCzi2ZBqPY0XdLJKPbQN
b2LoJt+4MECnzp1TS8pzt309jhPkQxtIjykr+EjiGcWX+VbQX6bfDV9gsB1Y
ru/oqJHvgxMgtmqcG0px5eDEq1/S+7PwpVdnz5oOryIWo9zV0iA0uoLdExXT
q3W4qkAr+Y2dZ1n7RecxZE1UVRNlEWp2+CV0cAFm6Kx+nQUbOp+pNSAwHeYr
gnep4HgmAZN19xE9O2seNaSBqQjjbaY4tggEDKGXzFY754Qb0xUhfnlkSqdv
6wom0a1GEqpRVFMrP4rq3rTxfBQTa4gSD5iLTlHmutIC3X2yR8ZuBGf5TQZr
bRaHXbZQGBlbg65UycQQO8/ngdofklWObu3lMl1LzhgheKJytauG9+9ZqF3h
Ah3IBiQXq9OmZTwbxVoN75kyuHw40SelbqlZZZ+q50saGpzJk/EP49YFI/0o
eH/GWwjnFOd0pKbZCypmxB389EP2Sp+vl/EdMBLnICINLtYgy/rWiWU4avtO
vXcpR8LRvSHZlMIzJpXdwbEevHyGEYTpakEn/Z2/3xnK9zS7LuQygfgNfO0M
Id4bDe7tOY+zfcGR18qbej2nY4Hb4fbBukM21KagN455S7LADeIYfynvhG78
aEj46w9Gn2xOCL1XPj0c1eqts/rsNGbC06vhQHdp4b3z7462GBzfjEfUR20X
pQoD4Q+vTWXQnEqWNziZm751NuNqT58cKn2OmPCWX+6QiXjOSNKfyvfCxOUS
UUkv+gRpFADHsU/jbE01KJUP1aBuRXG3ilKJuhxVRnsfvcay+3EAOEtS2eEQ
8HcefOiqEOYbdqxhKUsW/ZjFHA45ao68BA3rt85zxPRdke0nzMLr86cnZzhe
XgKcvzx6+QvGyhEDNIoCDaTgsIozOoZWhfAiooQgDYS5EkXKq9JS55Zmne86
dj4s2UqUiVXqkUVCOoXP9YJH2HM8wjaCN1TAUJUer6F9/0nEfBrPwfy9kDzm
Ivz96xgyvXtPlPSvDYkOPth/4FR6yYDeKpjG2by68j8LFEUTp7zG1fAqRaBA
/K4a8tu/aGR27eEmnIpWKcLotho/MTQSH/5bDCbBay54kV9eLDEAJJvXenUC
u7n4ZNekZ6uMltfF1ax4fQ1WGermv7SGxOkNMhevOwaDd6ppcifcDUfhXrgf
HoT3wvv02xeDxt/064cd+Hv3w+GHsw/PPxyHxx9ue7cRZYvox+fxPM5mD+U5
etJASvf5C7iu7VBmGzcV/zk8hH8Gjdp6oExtaSpGqc+65RhteUYlGxqWNNDd
dewkFXrOvWi08ABtaViRE7AoqYVjepl4Tfkd1xjTANw+QlKTtPXBjIu0u6Xj
0q6he7XYrfbod+2zjzXagkcBR0j7E8wFfOHLDVwZaVh6wF6cHp8dn/50fIQA
Mw89YzpIehOxZu4BeyXlwcg84Eop+mHdrnvPvAl60YUYEBd8F9zbN49hqeHW
YyZKNKN6B61mMBlGRyv3atXonvK3+b0H9hO97dzb7fhEMDou1PzzTeyOuqvQ
zvR29zaM1sUsz2xF+xsq4iHs7R60p2NDl+xnX0p4Z2+0s6H+VZH6sqPdDW9h
jN6qNC/a70YDQgyQlKbIvGc/H/vLSntvZD9XyZLBJr7qjQ7sI4tpdKv5nGR1
99apvRSChnxBkh0fbd+13CL4+O52bXON9vWQCu1fUG6yltzB6gholITNahif
H5mSpKi5iCwQ/umso1k9BGGlX5Zx9ejzCpvOf7qwsC73dIi27EGKs4/Jeuy+
f+ifmbCaR+1CdpWbQibevaNQa5tzyeNs9vLyGH9EBauzXHtfP+wMdO8o3LFh
sdl2Mtzby5qPtGU/0SBv7IeNQuyK6SiqO9k2FvqQ8o4SbcFKZZuZhjpK+o1a
a82h1n2Rj6Bez9aPmjtUdqdsjYaiyW+LrnMKRfLF673RL6bMAzFEyA55DY/w
ASzpw5rbi20MXsdwoMPa7hYJG/Rc9W58Hb4PQej0Rwd7IVj729u0c67RLaM1
cCfRnIV/tdQ1qU+HOiFE9d7om00vcoiNgV2Hrb+kE16J98MhFtYFfX351UiA
2Lc1t1gW0rdFXF3ls/KrXQ/51kJuo5hwt68etPiOaluftQzKMtk58p9BpdQF
7XoRZRHnwutSX/6/weK7GvsDcNWA6cayKF2XHLfz3FnUh4cvwh+Fgmw6XQwm
mJS0/MihIO/ffyueDDI6378fH3/Hzz+qu5Dt47Wx0dEVu9LERwHa5Rfj47OL
3dGDC2hs6OPNKdsjmu3qE/AU6nI9L0Eoru6Ag7MpUNdfSH7amidXiLoCZhLI
pEa3elX0FlGHCR0Frd5jdqNv4T8G4x/Gz/9+dnL29dHLk+HuDvxv5/723uBg
f2ewd2//y9Hg/sV9TCUmXxWxTT+JZAIowaU2xZe16ClPK3lqO+KuFOl6t+CE
Xzi+Mi4a1xwYVAW6daf4/xl7pHQeh+JxcJXTJUm5XkwwRIb41fm2XX3yvbuw
X2bJNVMO9LbFaRW/W+YZjTa/9U/4fZmu8C69IA9tKbFXsBjBooXzCJ1DmBEs
nsWE7T23bqNAe0Dh2eiBxg9+GAQV/MN4SvS5O79P/d6giub4lWBxleZWiIVi
P6SlBfMHn5511jYhOjHnO9pcU+ZrSl1N/sKL6ikdLJRvFzlJGRK432CKtl87
ymnUnl5HThXkwpkIhS0coSGK3xVuJibRDhlSAo1QPmHxkvnqtVp2yvKtv6mW
U11qQrEg1Cxe1x09hVfnJqG67EQFFVNOQ46ttx2U7kHNGzrYVaslOsQ+C8qJ
ewtVuQRo0luKVDECrrlxoQLColN8MGdG1PQc9fkLMGhFLk2S7DpPr9n1xyHk
hDGIfGZeXiSl5mldC8cHZreoOEg/sL1i1ELNVVny/vSCVTKt+91fliCe4N+B
LChxo0B1cK7s6KqjSxRdc7S6STrIa/tsrsBAPemQanwVW+VgqzWHQ523dlQk
I8tqEeSXzMbiu9TwytIdJ24o6mS/4+Wpc1oF5j2NcKq/u1SXmq2SpM6ukHiY
gZNAfvSuuutUvsHlVYl13iQCCtAUmr49lwbRNRX05Jzqh29GKeiIMK67b5TH
UhtxmJ86xq0xJoHkAOT0/8Tikokg8kj22nkmJzYf0o3D7iNPa+PXPm5e2C2L
UCL8aucWnE1ONMd+03F0b1wEFEDCfFYaYMy0nNcR2PQIu7im62cMSIBlsyzj
1SxnbZggBCsJq++9On21hfG/GLWs6VoeMja9B8N4N/x165+jcBtGM+O8Gk8o
XWKFd/yVbQ8X8uDejl7J0w7TnmsUk716oSNWD1UXpsd37dKBX8OvcBpHe9zy
uc6vl2mSZV5xdD7hDJZyIsvdg1BgMecqCig9IT5BLhsMV5EULTrEhFLizPsc
0VCYr3XIJhkHqI++XlbHidNsauvCKTyyIvx1hlsLu5+/FrKNsw9zjPPTMcXX
NLNV+EXIk927hv/8dasx5Si95zlURAxUIrl4N/sRyXH+D+73a+JVx4dSKTgl
B9PLvqnekBh5k70hrYK0RBB4LIQYM4Cx0AKzTZM5xTXwCrmOlXqW8xRbHA0U
kVO0kLgMneSIsmKTEIDzJaabeBEAshBFWCw1aqZjTdIAybrcHx7wAP3o8mxq
zFC6Hvg5m3mZRusSFa83v/L3E8sApX+lAaVIloBjf1ZLzLAs50QWvrl+ozUM
D7Cnm3aDD7QLLFatsTuGB7fuj7BrfwSfvz94dcj+kF3RpcJfPJDNQoE8QrcM
C6f+zsXZ0/Ho4F797pJ0ZbqDb9ep53k/YPFE70q0UJe+6g+T6ut7+1sOP1SX
+mr5tBUaaLKJZmCtv8vo8tw2DqFQh2Fij9RVCPoq7KWuY0axzxoC5UthD+/t
k96s2BSlXGscjBJsJC14gfXRd41iQYjmsvXNjr/DS4tA7To/FnrVGylFlp3F
0iDp3dInFbSgUOWSFxtlI5tWUeVxUEZmqKbj1iMG6K3SyO1h2r/3efOOSw1T
k8ufUndQyQmqk7SxQvomHuZKaYKYVSRAOC5SNKOwUu4XSxVlDeyOSmg/NcKD
6JzAlO20YYRjie7Z0czDhWxQHRI3mFAingyB6kEbx857uGVsSlgRb6LrJL7h
ZbJx92nydIkzDhrdG4ZnCtpKMfZ18y72LDqll9eBwe7Doi3pkt6EdfOiWPsU
8Bxxi8cPFJtreLnK+cvArSIR88qTQ24MJrp0PM8SQsPoXGdLYXYtmiIDmzeJ
/Skdoc/O0GKYNYw3NiYcBG5gQXQiMzUIyK9iK3350PfY5iyof4CDgPpvwPhK
D4WWqRFfhfIXkCuqnhUufJVUlzCDJbE86KRoDEpEgaOlBizSODlOE2yHAdDw
mCL7yVBhyELAaT8FQ+NgvD0N3ThUxLrij/oKP9JdionA0GceOEZlaY66w1kj
+sL+geGBBPo+ysN1vtIM4+lak4G5WGAXck7Brg3WYMVtUjgzGLoEiqYB+TZs
MDJTqFIzoTl63zx3g6Ii2bIXMBdDBEjMJJcgO3BrzWzXDTlGRyizg9HjluoZ
rjzi/dI/oXu1ntH+/XulwGjwysDIf3vbwLX6YIiGdCxNUCM0fOMoWAmTZUhh
/1hDFh5Qq0SmgmLLeToc1Sxx1ksyTslnKXO0sGPM0vgqv+HQcDKU8XcFxDIe
Q90zeK4qqDNBz7rgiOOZ/SC+PvJHr2NH1KhWPqsTR+ItslDACZ451hMNcQJS
9/q3tH2fgpTKi3UQYOTY8dHJ+cvTh+Gr58fjs+Pw9PjFy5+Ow/On+M/JWXh2
fHh+8vKHIOjd3XIUMJS2hPEu1FkcRw5cbW1ijF47Pn8SHhXRZVUGM/zXYH+E
Xy0AmxSkdWrDNn1ai1RTAOQ4KYQfC/1dBk3HoXbD0bk2eTSYgxYq2SUvC65r
SmywjPOlYG5y1jMwf4BLRsJ0yojvdJuAG4yWTJltyX+w9h2XK4dmNPsr9mRA
uV+vYt+LyuDFWeufMH/qLhgLIWPe2afBR9osPD0/p5bH8GaGljOuqCmcLOQZ
J6pVsUMSBXvVwsfJGYPNg+z0ocM0f5wJUjLhQm+jYrGFTUkufoo7nDaCYmUK
d0hVokycMCjYG/LQNAOd5NoDnf1J1oSbcJw2V8Gh2Byw69DDPK0qYt+xD5rI
BGwhcin5gXDwA/xw1yIGedsIdigNp+8kmYEuSjkjmbbMJHulXYxQYf8TbALX
cHgTFZRtkls298AuxG+OJMUUow5Ffiyla2W1hnWnd5UcpdpnIFANBuoaO5Io
ZhI3DdB498daFC83LskCBD8uv54oCjKGMzsnGgmB2gioFcfkO+jXs2i2estl
HJihwsQMZui7aDbsLE15jUzFDRkxfR6JemIfIqSFXAgOKA5V6OooOFiuUTJe
5Wls192aa6EzgXzNtU2nnzqThCxUZ40EZpLPV6We3z5Rh0h/joDHD0+jd6Ek
JKYPt0PLqRs404J/diq6I/vurRWjsbHOT9lGbblNrN8ak82vAbQW50SJZVyS
CG3bRQOn5SBPZwNFKA1maMlQtj7awrKl974M/EIRmqV9TTQA0hSOrHnGfO04
avLGnsZmumoeQDXfWfazRgYMXNcDP+ee2V4u2VYZC3ep7v5DePtJ8o6esT0I
atA0Fta4m5hFNdTny9zDMpRIya9sQVwM3aExUwXYx8FXuXJqgmCfyoe6nLkS
XU7LFz9CWzvA1j6BvybI24JAAy4u2MVrB35bzVZsHpin2KtP1D6UIboUcqxd
LEPDUrlEPQ7Gks0yt1RN/NMujUzXhqKh9c+iJgYqXyzFXexnYA/H5BllCAFT
iO0EhVMTPkTE1TA8QTU8/Mv9kS88wsLH3TKJRGtNlPhyu7eUQyWJhFU2k2Gi
pcCyqWNOcARhncD/RjtU6FWernf3dg58czsPzVqSbcxIv6DjaCJ3zaXwzdEl
gi/MpRxOvoMTwWVy1prHS3QAwZyPwzt/JGT9jnZ/9OVDV5lFpm3GkXrFAPcJ
mFbNbz5eLK8iurwSBMliCaMqOskin+FdIupFnNXedeQBdkRDeSarxZKhHMhQ
aPnNiP0IVVaRY24iRiQi4DDLC8yRRImZOCpbAf3cw2Hn93KKeqlqZx8k54jF
x2qiFs6G/lARh/t0VexBYQISeqYmRIhVNSJj0MqFf1KLjbBN8swp15Pe8daT
E0hkhKTEwiMhBX2X3aFoWcg4ylqqlR2SoPGFXXf0Uoa5Axn5n2KWE/Hw1ISs
lwSKZ6J08/5LdqkZp/jN3HtVblJZInTU+Gb4EEtLTG42MeciJydhh3HUNvF8
qzskA9HF5w2OIHgFw0GiqmaAUBfH9fNMB26w+6UOnk50LbeQaTBgzUKUeSnP
F0UuZQ3aSuiFSeG0HwaqCDZIqyx8s0WFZQu5XE4uHbUvqEkBKSw0IS2glWm6
jQ31CTq9qmYwavTruZdiTelApjda7WhY/iwptb4H3W4JA+Mp3G41Nb2ZKQ5q
SeJJkX24StQgpImlxFrS0JwaSsSXgiqEWM6DRZSkgZrcX8GB+RiPz2FezL8Z
2p6pB51r4r1Ve8g6d1CuJqKEiw1HHUsogfxXV1W1LB9ub9/c3OwOtZ1t7MIi
yrZTUh8u823oxTdBMC6mV5TaVWlTk9LFdVySThxVDwNbZ73KQcQVbN/EE6xy
W/KvbiO95LvhVbVIv1FqnQp6vILTEITTCzRaxeZlUnR9zBfYjtqwBmbXm/y1
JF40VMkUVIHc4K0EMbXtQikw3PWtHK6zxjsUThTcksGAEngsacCZYJdME6zz
3348OWwm//pZMsYFnJyArv6yty70CMZDB79dWhdbUtAqG4ZPYOu+C77/139l
JIhwQF6gczfDFHmLkjvnR9IGsjDm1UflfRzWXKR9lKuc2q7WUbmFuAvH+TVo
jmCA/Ue0oA39fZ7PU/b0wJNJnD2e0y9DOGr5soILYs9A8jzJYQ9XCbw/LhZ8
qUbWDD8eyuPHYPW3KsgnCVTwfZ7NYKChyNNVdBNjTRU9Gc75yWP5N65OW54G
LdRBg2LH50/Df6yKhOA4uIwfX+Ir8xVFmxVD3CC2Av1oZ3qO30ZQDETR9CrL
03yekMR6i08fw3cN49nKlj/BIwo+eVVeR6B/BpjLlu/M2MTEBIOgl8jjxzdx
epU3B6E+zVDoRf5bkqYRfQE+Glb86PEcv6hZ/PCqQEcbGX1jWJR5jmOP2Zlj
VFbwMJhGN/DrY7wTaM3h36Hpf0+yd+wSdeO/pp/w18dX9Fuz3FO8LIHxo6v/
5szTwyE/rM87Rpg2WbSDnzvXZ/g3OFHpQH4aLRZwovShuSJD5p/xJJ9EtEfG
2WwdHq4ydJFcRQuzrVDQMGabL7xAJDqLAq+BujeFHABn38PJxIbMxhof6swd
rd6CanNcJG/DZ3j+9sMnBdFhT6PwVZTmi0mSJf3wOdKXH2MK16of/iO6gqX0
22+w2rLwLCre4k3c3/Ir+MN0NSNKyn/9J6zj8Kd1NsXqT/MJgpd/TtIKt/Rp
jgWPQNqmyU2/sY774QsQ1tE6fLaawrKIbuBzpa8/JfMclKXVO46eGqfXUYEE
M6C6R8F/A0B+Fdk64wEA

-->
</rfc>