rfc9147.original.xml   rfc9147.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- [CS] updated by Chris 05/11/21 -->
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.3 --> <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.3 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> <!DOCTYPE rfc [
<?rfc rfcedstyle="yes"?> <!ENTITY nbsp "&#160;">
<?rfc toc="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc tocindent="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc sortrefs="yes"?> <!ENTITY wj "&#8288;">
<?rfc symrefs="yes"?> ]>
<?rfc strict="yes"?>
<?rfc comments="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="pre5378Trust200902" docName
<?rfc inline="yes"?> ="draft-ietf-tls-dtls13-43" number="9147" obsoletes="6347" updates="" submission
<?rfc text-list-symbols="-o*+"?> Type="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true"
<?rfc docmapping="yes"?> sortRefs="true" symRefs="true" version="3">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="pre5378Trust200902" docName
="draft-ietf-tls-dtls13-43" category="std" obsoletes="6347" updates="" submissio
nType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" vers
ion="3">
<!-- xml2rfc v2v3 conversion 3.5.0 --> <!-- xml2rfc v2v3 conversion 3.5.0 -->
<front> <front>
<title abbrev="DTLS 1.3">The Datagram Transport Layer Security (DTLS) Protoc ol Version 1.3</title> <title abbrev="DTLS 1.3">The Datagram Transport Layer Security (DTLS) Protoc ol Version 1.3</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-dtls13-43"/> <seriesInfo name="RFC" value="9147"/>
<author initials="E." surname="Rescorla" fullname="Eric Rescorla"> <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
<organization>RTFM, Inc.</organization> <organization>Mozilla</organization>
<address> <address>
<email>ekr@rtfm.com</email> <email>ekr@rtfm.com</email>
</address> </address>
</author> </author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig"> <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Arm Limited</organization> <organization>Arm Limited</organization>
<address> <address>
<email>hannes.tschofenig@arm.com</email> <email>hannes.tschofenig@arm.com</email>
</address> </address>
</author> </author>
<author initials="N." surname="Modadugu" fullname="Nagendra Modadugu"> <author initials="N." surname="Modadugu" fullname="Nagendra Modadugu">
<organization>Google, Inc.</organization> <organization>Google, Inc.</organization>
<address> <address>
<email>nagendra@cs.stanford.edu</email> <email>nagendra@cs.stanford.edu</email>
</address> </address>
</author> </author>
<date year="2021" month="April" day="30"/> <date year="2022" month="March"/>
<area>Security</area> <area>Security</area>
<workgroup>TLS</workgroup> <workgroup>TLS</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>Communication Security</keyword>
<abstract> <abstract>
<t>This document specifies Version 1.3 of the Datagram Transport Layer Sec urity <t>This document specifies version 1.3 of the Datagram Transport Layer Sec urity
(DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the (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 mess age Internet in a way that is designed to prevent eavesdropping, tampering, and mess age
forgery.</t> forgery.</t>
<t>The DTLS 1.3 protocol is intentionally based on the Transport Layer Sec <t>The DTLS 1.3 protocol is based on the Transport Layer Security (TLS)
urity (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of o
1.3 protocol and provides equivalent security guarantees with the exception of o rder protection / non-replayability. Datagram semantics of the underlying trans
rder protection/non-replayability. Datagram semantics of the underlying transpo port are preserved by the DTLS protocol.</t>
rt are preserved by the DTLS protocol.</t>
<t>This document obsoletes RFC 6347.</t> <t>This document obsoletes RFC 6347.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default"> <section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name> <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 GitHu
b,
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, <t>The primary goal of the TLS protocol is to establish an authenticated,
confidentiality and integrity protected channel between two communicating peers. confidentiality- and integrity-protected channel between two communicating peers .
The TLS protocol is composed of two layers: The TLS protocol is composed of two layers:
the TLS Record Protocol and the TLS Handshake Protocol. However, TLS must the TLS record protocol and the TLS handshake protocol. However, TLS must
run over a reliable transport channel - typically TCP <xref target="RFC0793" for run over a reliable transport channel -- typically TCP <xref target="RFC0793" fo
mat="default"/>.</t> rmat="default"/>.</t>
<t>There are applications that use UDP <xref target="RFC0768" format="defa <t>There are applications that use UDP <xref target="RFC0768" format="default"/>
ult"/> as a transport and to offer communication as a transport
security protection for those applications the Datagram Transport Layer and the Datagram Transport Layer
Security (DTLS) protocol has been developed. DTLS is deliberately designed to be Security (DTLS) protocol has been developed to offer communication security prot
ection
for those applications. DTLS is deliberately designed to be
as similar to TLS as possible, both to minimize new security invention and to as similar to TLS as possible, both to minimize new security invention and to
maximize the amount of code and infrastructure reuse.</t> maximize the amount of code and infrastructure reuse.</t>
<t>DTLS 1.0 <xref target="RFC4347" format="default"/> was originally defin ed as a delta from TLS 1.1 <xref target="RFC4346" format="default"/> and <t>DTLS 1.0 <xref target="RFC4347" format="default"/> was originally defin ed as a delta from TLS 1.1 <xref target="RFC4346" format="default"/>, and
DTLS 1.2 <xref target="RFC6347" format="default"/> was defined as a series of de ltas to TLS 1.2 <xref target="RFC5246" format="default"/>. There DTLS 1.2 <xref target="RFC6347" format="default"/> was defined as a series of de ltas 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 nu mbers is no DTLS 1.1; that version number was skipped in order to harmonize version nu mbers
with TLS. This specification describes the most current version of the DTLS pro tocol with TLS. This specification describes the most current version of the DTLS pro tocol
as a delta from TLS 1.3 <xref target="TLS13" format="default"/>. It obsoletes DT LS 1.2.</t> as a delta from TLS 1.3 <xref 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 <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 implementat ions that speak only DTLS 1.2 (using DTLS 1.2 of course), just as TLS 1.3 implementat ions
can interoperate with TLS 1.2 (see Appendix D of <xref target="TLS13" format="de can interoperate with TLS 1.2 (see <xref target="RFC8446" sectionFormat="of" sec
fault"/> for details). tion="D"/> for details).
While backwards compatibility with DTLS 1.0 is possible the use of DTLS 1.0 is n While backwards compatibility with DTLS 1.0 is possible, the use of DTLS 1.0 is
ot not
recommended as explained in Section 3.1.2 of RFC 7525 <xref target="RFC7525" for recommended, as explained in <xref target="RFC7525" sectionFormat="of" section="
mat="default"/> and <xref target="DEPRECATE" format="default"/>.</t> 3.1.2"/>. <xref target="RFC8996"/> forbids the use of DTLS 1.0.
</t>
</section> </section>
<section anchor="conventions-and-terminology" numbered="true" toc="default"> <section anchor="conventions-and-terminology" numbered="true" toc="default">
<name>Conventions and Terminology</name> <name>Conventions and Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SH <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
OULD", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
document are to be interpreted as described in BCP 14 <xref target="RFC2119" for "<bcp14>SHOULD NOT</bcp14>",
mat="default"/> <xref target="RFC8174" format="default"/> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
when, and only when, they appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in BCP&nbsp;14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
<t>The following terms are used:</t> <t>The following terms are used:</t>
<ul spacing="normal"> <dl spacing="normal">
<li>client: The endpoint initiating the DTLS connection.</li> <dt>client:</dt><dd>The endpoint initiating the DTLS connection.</dd>
<li>association: Shared state between two endpoints established with <dt>association:</dt><dd>Shared state between two endpoints established
a DTLS handshake.</li> with
<li>connection: Synonym for association.</li> a DTLS handshake.</dd>
<li>endpoint: Either the client or server of the connection.</li> <dt>connection:</dt><dd>Synonym for association.</dd>
<li>epoch: one set of cryptographic keys used for encryption and decrypt <dt>endpoint:</dt><dd>Either the client or server of the connection.</dd
ion.</li> >
<li>handshake: An initial negotiation between client and server that est <dt>epoch:</dt><dd>One set of cryptographic keys used for encryption and
ablishes decryption.</dd>
the parameters of the connection.</li> <dt>handshake:</dt><dd>An initial negotiation between client and server
<li>peer: An endpoint. When discussing a particular endpoint, "peer" ref that establishes
ers to the parameters of the connection.</dd>
the endpoint that is remote to the primary subject of discussion.</li> <dt>peer:</dt><dd>An endpoint. When discussing a particular endpoint, "p
<li>receiver: An endpoint that is receiving records.</li> eer" refers to
<li>sender: An endpoint that is transmitting records.</li> the endpoint that is remote to the primary subject of discussion.</dd>
<li>server: The endpoint which did not initiate the DTLS connection.</li <dt>receiver:</dt><dd>An endpoint that is receiving records.</dd>
> <dt>sender:</dt><dd>An endpoint that is transmitting records.</dd>
<li>CID: Connection ID</li> <dt>server:</dt><dd>The endpoint that did not initiate the DTLS connecti
<li>MSL: Maximum Segment Lifetime</li> on.</dd>
</ul> <dt>CID:</dt><dd>Connection ID.</dd>
<t>The reader is assumed to be familiar with <xref target="TLS13" format=" <dt>MSL:</dt><dd>Maximum Segment Lifetime.</dd>
default"/>. </dl>
<t>The reader is assumed to be familiar with <xref target="RFC8446" format
="default"/>.
As in TLS 1.3, the HelloRetryRequest has the same format as a ServerHello As in TLS 1.3, the HelloRetryRequest has the same format as a ServerHello
message, but for convenience we use the term HelloRetryRequest throughout message, but for convenience we use the term HelloRetryRequest throughout
this document as if it were a distinct message.</t> this document as if it were a distinct message.</t>
<t>DTLS 1.3 uses network byte order (big-endian) format for encoding messa ges <t>DTLS 1.3 uses network byte order (big-endian) format for encoding messa ges
based on the encoding format defined in <xref target="TLS13" format="default"/> based on the encoding format defined in <xref target="RFC8446" format="default"/
and earlier (D)TLS specifications.</t> > and earlier (D)TLS specifications.</t>
<t>The reader is also assumed to be familiar with <xref target="I-D.ietf-t <t>The reader is also assumed to be familiar with <xref target="RFC9146" f
ls-dtls-connection-id" format="default"/> ormat="default"/>,
as this document applies the CID functionality to DTLS 1.3.</t> as this document applies the CID functionality to DTLS 1.3.</t>
<t>Figures in this document illustrate various combinations of the DTLS pr <t>Figures in this document illustrate various combinations of the DTLS pr
otocol exchanges and the symbols have the following meaning:</t> otocol exchanges, and the symbols have the following meaning:</t>
<ul spacing="normal"> <dl spacing="normal" indent="6">
<li>'+' indicates noteworthy extensions sent in the previously noted me <dt>'+'</dt><dd>indicates noteworthy extensions sent in the previously n
ssage.</li> oted message.</dd>
<li>'*' indicates optional or situation-dependent messages/extensions t <dt>'*'</dt><dd>indicates optional or situation-dependent messages/exten
hat are not always sent.</li> sions that are not always sent.</dd>
<li>'{}' indicates messages protected using keys derived from a [sender] <dt>'{}'</dt><dd>indicates messages protected using keys derived from a
_handshake_traffic_secret.</li> [sender]_handshake_traffic_secret.</dd>
<li>'[]' indicates messages protected using keys derived from traffic_se <dt>'[]'</dt><dd>indicates messages protected using keys derived from tr
cret_N.</li> affic_secret_N.</dd>
</ul> </dl>
</section> </section>
<section anchor="dtls-rational" numbered="true" toc="default"> <section anchor="dtls-rational" numbered="true" toc="default">
<name>DTLS Design Rationale and Overview</name> <name>DTLS Design Rationale and Overview</name>
<t>The basic design philosophy of DTLS is to construct "TLS over datagram transport". <t>The basic design philosophy of DTLS is to construct "TLS over datagram transport".
Datagram transport does not require nor provide reliable or in-order delivery of data. Datagram transport neither requires nor provides reliable or in-order delivery o f data.
The DTLS protocol preserves this property for application data. The DTLS protocol preserves this property for application data.
Applications, such as media streaming, Internet telephony, and online gaming use Applications such as media streaming, Internet telephony, and online gaming use
datagram transport for communication due to the delay-sensitive nature datagram transport for communication due to the delay-sensitive nature
of transported data. The behavior of such applications is unchanged when the of transported data. The behavior of such applications is unchanged when the
DTLS protocol is used to secure communication, since the DTLS protocol DTLS protocol is used to secure communication, since the DTLS protocol
does not compensate for lost or reordered data traffic. Note that while does not compensate for lost or reordered data traffic. Note that while
low-latency streaming and gaming use DTLS to protect data (e.g. for low-latency streaming and gaming use DTLS to protect data (e.g., for
protection of a WebRTC data channel), telephony utilizes DTLS for protection of a WebRTC data channel), telephony utilizes DTLS for
key establishment, and Secure Real-time Transport Protocol (SRTP) for key establishment and the Secure Real-time Transport Protocol (SRTP) for
protection of data <xref target="RFC5763" format="default"/>.</t> protection of data <xref target="RFC5763" format="default"/>.</t>
<t>TLS cannot be used directly over datagram transports the following five reasons:</t> <t>TLS cannot be used directly over datagram transports for the following four reasons:</t>
<ol spacing="normal" type="1"><li>TLS relies on an implicit sequence numbe r on records. If a record is not <ol spacing="normal" type="1"><li>TLS relies on an implicit sequence numbe r on records. If a record is not
received, then the recipient will use the wrong sequence number when received, then the recipient will use the wrong sequence number when
attempting to remove record protection from subsequent records. DTLS solves attempting to remove record protection from subsequent records. DTLS solves
this problem by adding sequence numbers to records.</li> this problem by adding sequence numbers to records.</li>
<li>The TLS handshake is a lock-step cryptographic protocol. Messages <li>The TLS handshake is a lock-step cryptographic protocol. Messages
must be transmitted and received in a defined order; any other must be transmitted and received in a defined order; any other
order is an error. The DTLS handshake includes message sequence order is an error. The DTLS handshake includes message sequence
numbers to enable fragmented message reassembly and in-order numbers to enable fragmented message reassembly and in-order
delivery in case datagrams are lost or reordered.</li> 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 <li>Handshake messages are potentially larger than can be contained in a single
datagram. DTLS adds fields to handshake messages to support fragmentation datagram. DTLS adds fields to handshake messages to support fragmentation
and reassembly.</li> and reassembly.</li>
<li>Datagram transport protocols, like UDP, are susceptible to abusive b <li>Datagram transport protocols are susceptible to abusive behavior
ehavior effecting denial-of-service (DoS) attacks against nonparticipants. DTLS adds a
effecting denial of service attacks against nonparticipants. DTLS adds a
return-routability check and DTLS 1.3 uses the TLS 1.3 HelloRetryRequest message return-routability check and DTLS 1.3 uses the TLS 1.3 HelloRetryRequest message
(see <xref target="dos" format="default"/> for details).</li> (see <xref target="dos" format="default"/> for details).</li>
</ol> </ol>
<section anchor="packet-loss" numbered="true" toc="default"> <section anchor="packet-loss" numbered="true" toc="default">
<name>Packet Loss</name> <name>Packet Loss</name>
<t>DTLS uses a simple retransmission timer to handle packet loss. <t>DTLS uses a simple retransmission timer to handle packet loss.
<xref target="dtls-retransmission" format="default"/> demonstrates the basic con cept, using the first <xref target="dtls-retransmission" format="default"/> demonstrates the basic con cept, using the first
phase of the DTLS handshake:</t> phase of the DTLS handshake:</t>
<figure anchor="dtls-retransmission"> <figure anchor="dtls-retransmission">
<name>DTLS retransmission example</name> <name>DTLS Retransmission Example</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
Client Server Client Server
------ ------ ------ ------
ClientHello ------> ClientHello ------>
X<-- HelloRetryRequest X<-- HelloRetryRequest
(lost) (lost)
[Timer Expires] [Timer Expires]
ClientHello ------> ClientHello ------>
(retransmit) (retransmit)
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Once the client has transmitted the ClientHello message, it expects <t>Once the client has transmitted the ClientHello message, it expects
to see a HelloRetryRequest or a ServerHello from the server. However, if the to see a HelloRetryRequest or a ServerHello from the server. However, if the
timer expires, the client knows that either the timer expires, the client knows that either the
ClientHello or the response from the server has been lost, which ClientHello or the response from the server has been lost, which
causes the the client causes the client
to retransmit the ClientHello. When the server receives the retransmission, to retransmit the ClientHello. When the server receives the retransmission,
it knows to retransmit its HelloRetryRequest or ServerHello.</t> it knows to retransmit its HelloRetryRequest or ServerHello.</t>
<t>The server also maintains a retransmission timer for messages it <t>The server also maintains a retransmission timer for messages it
sends (other than HelloRetryRequest) and retransmits when that timer expires. No t sends (other than HelloRetryRequest) and retransmits when that timer expires. No t
applying retransmissions to the HelloRetryRequest avoids the need to applying retransmissions to the HelloRetryRequest avoids the need to
create state on the server. The HelloRetryRequest is designed to be create state on the server. The HelloRetryRequest is designed to be
small enough that it will not itself be fragmented, thus avoiding small enough that it will not itself be fragmented, thus avoiding
concerns about interleaving multiple HelloRetryRequests.</t> concerns about interleaving multiple HelloRetryRequests.</t>
<t>For more detail on timeouts and retransmission, <t>For more detail on timeouts and retransmission,
see <xref target="timeout-retransmissions" format="default"/>.</t> see <xref target="timeout-retransmissions" format="default"/>.</t>
skipping to change at line 223 skipping to change at line 223
length. Thus, a recipient in possession of all bytes of a handshake length. Thus, a recipient in possession of all bytes of a handshake
message can reassemble the original unfragmented message.</t> message can reassemble the original unfragmented message.</t>
</section> </section>
<section anchor="replay-detection" numbered="true" toc="default"> <section anchor="replay-detection" numbered="true" toc="default">
<name>Replay Detection</name> <name>Replay Detection</name>
<t>DTLS optionally supports record replay detection. The technique used <t>DTLS optionally supports record replay detection. The technique used
is the same as in IPsec AH/ESP, by maintaining a bitmap window of 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 received records. Records that are too old to fit in the window and
records that have previously been received are silently discarded. records that have previously been received are silently discarded.
The replay detection feature is optional, since packet duplication is The replay detection feature is optional, since packet duplication is
not always malicious, but can also occur due to routing errors. not always malicious but can also occur due to routing errors.
Applications may conceivably detect duplicate packets and accordingly Applications may conceivably detect duplicate packets and accordingly
modify their data transmission strategy.</t> modify their data transmission strategy.</t>
</section> </section>
</section> </section>
<section anchor="the-dtls-record-layer" numbered="true" toc="default"> <section anchor="the-dtls-record-layer" numbered="true" toc="default">
<name>The DTLS Record Layer</name> <name>The DTLS Record Layer</name>
<t>The DTLS 1.3 record layer is different from the TLS 1.3 record layer an d <t>The DTLS 1.3 record layer is different from the TLS 1.3 record layer an d
also different from the DTLS 1.2 record layer.</t> also different from the DTLS 1.2 record layer.</t>
<ol spacing="normal" type="1"><li>The DTLSCiphertext structure omits the s uperfluous version number and <ol spacing="normal" type="1"><li>The DTLSCiphertext structure omits the s uperfluous version number and
type fields.</li> type fields.</li>
<li>DTLS adds an epoch and sequence number to the TLS record header. <li>DTLS adds an epoch and sequence number to the TLS record header.
This sequence number allows the recipient to correctly verify the DTLS MAC. This sequence number allows the recipient to correctly decrypt and verify DTLS r ecords.
However, the number of bits used for the epoch and sequence number fields in However, the number of bits used for the epoch and sequence number fields in
the DTLSCiphertext structure have been reduced from those in previous the DTLSCiphertext structure has been reduced from those in previous
versions.</li> versions.</li>
<li>The DTLSCiphertext structure has a variable length header.</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 se
quence 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 header.</li>
</ol> </ol>
<t>DTLSPlaintext records are used to send unprotected records and DTLSCiph ertext <t>DTLSPlaintext records are used to send unprotected records and DTLSCiph ertext
records are used to send protected records.</t> records are used to send protected records.</t>
<t>The DTLS record formats are shown below. Unless explicitly stated the <t>The DTLS record formats are shown below. Unless explicitly stated the
meaning of the fields is unchanged from previous TLS / DTLS versions.</t> meaning of the fields is unchanged from previous 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"> <figure anchor="dtls-record">
<name>DTLS 1.3 Record Formats</name> <name>DTLS 1.3 Record Formats</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="tls-presentation"><![CDATA[
struct { struct {
ContentType type; ContentType type;
ProtocolVersion legacy_record_version; ProtocolVersion legacy_record_version;
uint16 epoch = 0 uint16 epoch = 0
uint48 sequence_number; uint48 sequence_number;
uint16 length; uint16 length;
opaque fragment[DTLSPlaintext.length]; opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext; } DTLSPlaintext;
struct { struct {
opaque content[DTLSPlaintext.length]; opaque content[DTLSPlaintext.length];
ContentType type; ContentType type;
uint8 zeros[length_of_padding]; uint8 zeros[length_of_padding];
} DTLSInnerPlaintext; } DTLSInnerPlaintext;
struct { struct {
opaque unified_hdr[variable]; opaque unified_hdr[variable];
opaque encrypted_record[length]; opaque encrypted_record[length];
} DTLSCiphertext; } DTLSCiphertext;
]]></artwork> ]]></sourcecode>
</figure> </figure>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>legacy_record_version</dt> <dt>legacy_record_version:</dt>
<dd> <dd>
This value MUST be set to {254, 253} for all records other This value <bcp14>MUST</bcp14> be set to {254, 253} for all records other
than the initial ClientHello (i.e., one not generated after a HelloRetryRequest) , than the initial ClientHello (i.e., one not generated after a HelloRetryRequest) ,
where it may also be {254, 255} for compatibility purposes. where it may also be {254, 255} for compatibility purposes.
It MUST be ignored for all purposes. See <xref target="TLS13" format="default"/> It <bcp14>MUST</bcp14> be ignored for all purposes. See <xref target="RF
; Appendix D.1 C8446" sectionFormat="comma" section="D.1"/> for the rationale for this.</dd>
for the rationale for this.</dd> <dt>epoch:</dt>
<dt>unified_hdr:</dt> <dd>The least significant 2 bytes of the connection epoch value.</dd>
<dd>
The unified header (unified_hdr) is a structure of variable length, as shown i <dt>unified_hdr:</dt>
n <xref target="cid_hdr" format="default"/>.</dd> <dd>
The unified header (unified_hdr) is a structure of variable length, shown in <xr
ef target="cid_hdr" format="default"/>.</dd>
<dt>encrypted_record:</dt> <dt>encrypted_record:</dt>
<dd> <dd>
The AEAD-encrypted form of the serialized DTLSInnerPlaintext structure.</dd> The encrypted form of the serialized DTLSInnerPlaintext structure.</dd>
</dl> </dl>
<figure anchor="cid_hdr"> <figure anchor="cid_hdr">
<name>DTLS 1.3 Unified Header</name> <name>DTLS 1.3 Unified Header</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0|0|1|C|S|L|E E| |0|0|1|C|S|L|E E|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Connection ID | Legend: | Connection ID | Legend:
| (if any, | | (if any, |
/ length as / C - Connection ID (CID) present / length as / C - Connection ID (CID) present
| negotiated) | S - Sequence number length | negotiated) | S - Sequence number length
+-+-+-+-+-+-+-+-+ L - Length present +-+-+-+-+-+-+-+-+ L - Length present
| 8 or 16 bit | E - Epoch | 8 or 16 bit | E - Epoch
skipping to change at line 312 skipping to change at line 331
]]></artwork> ]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Fixed Bits:</dt> <dt>Fixed Bits:</dt>
<dd> <dd>
The three high bits of the first byte of the unified header are set to 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 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 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 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; 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-con nection-id" format="default"/> such multiplexing is only possible when CIDs <xref target="RFC9146" format="defa ult"/>
are in use, in which case DTLS 1.2 records will have the content type tls12_cid (25).</dd> are in use, in which case DTLS 1.2 records will have the content type tls12_cid (25).</dd>
<dt>C:</dt> <dt>C:</dt>
<dd> <dd>
The C bit (0x10) is set if the Connection ID is present.</dd> The C bit (0x10) is set if the Connection ID is present.</dd>
<dt>S:</dt> <dt>S:</dt>
<dd> <dd>
The S bit (0x08) indicates the size of the sequence number. The S bit (0x08) indicates the size of the sequence number.
0 means an 8-bit sequence number, 1 means 16-bit. 0 means an 8-bit sequence number, 1 means 16-bit.
Implementations MAY mix sequence numbers of different lengths Implementations <bcp14>MAY</bcp14> mix sequence numbers of different lengths
on the same connection.</dd> on the same connection.</dd>
<dt>L:</dt> <dt>L:</dt>
<dd> <dd>
The L bit (0x04) is set if the length is present.</dd> The L bit (0x04) is set if the length is present.</dd>
<dt>E:</dt> <dt>E:</dt>
<dd> <dd>
The two low bits (0x03) include the low order two bits of the epoch.</dd> The two low bits (0x03) include the low-order two bits of the epoch.</dd>
<dt>Connection ID:</dt> <dt>Connection ID:</dt>
<dd> <dd>
Variable length CID. The CID functionality Variable-length CID. The CID functionality
is described in <xref target="I-D.ietf-tls-dtls-connection-id" format="default"/ is described in <xref target="RFC9146" format="default"/>. An example
>. An example
can be found in <xref target="connection-id-example" format="default"/>.</dd> can be found in <xref target="connection-id-example" format="default"/>.</dd>
<dt>Sequence Number:</dt> <dt>Sequence Number:</dt>
<dd> <dd>
The low order 8 or 16 bits of the record sequence number. This value is 16 The 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> bits if the S bit is set to 1, and 8 bits if the S bit is 0.</dd>
<dt>Length:</dt> <dt>Length:</dt>
<dd> <dd>
Identical to the length field in a TLS 1.3 record.</dd> Identical to the length field in a TLS 1.3 record.</dd>
</dl> </dl>
<t>As with previous versions of DTLS, multiple DTLSPlaintext <t>As with previous versions of DTLS, multiple DTLSPlaintext
and DTLSCiphertext records can be included in the same and DTLSCiphertext records can be included in the same
underlying transport datagram.</t> underlying transport datagram.</t>
<t><xref target="hdr_examples" format="default"/> illustrates different re cord headers.</t> <t><xref target="hdr_examples" format="default"/> illustrates different re cord headers.</t>
<figure anchor="hdr_examples"> <figure anchor="hdr_examples">
<name>DTLS 1.3 Header Examples</name> <name>DTLS 1.3 Header Examples</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" 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 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| | Content Type | |0|0|1|1|1|1|E E| |0|0|1|0|0|0|E E|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| 16 bit | | | |8-bit Seq. No. | | 16 bit | | | |8 bit Seq. No. |
| Version | / Connection ID / +-+-+-+-+-+-+-+-+ | Version | / Connection ID / +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ | | | | +-+-+-+-+-+-+-+-+ | | | |
| 16 bit | +-+-+-+-+-+-+-+-+ | Encrypted | | 16 bit | +-+-+-+-+-+-+-+-+ | Encrypted |
| Epoch | | 16 bit | / Record / | Epoch | | 16 bit | / Record /
+-+-+-+-+-+-+-+-+ |Sequence Number| | | +-+-+-+-+-+-+-+-+ |Sequence Number| | |
| | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | | 16 bit | | | | 16 bit |
| 48 bit | | Length | DTLSCiphertext | 48 bit | | Length | DTLSCiphertext
|Sequence Number| +-+-+-+-+-+-+-+-+ Structure |Sequence Number| +-+-+-+-+-+-+-+-+ Structure
| | | | (minimal) | | | | (minimal)
skipping to change at line 379 skipping to change at line 398
| | DTLSCiphertext | | DTLSCiphertext
| | Structure | | Structure
/ Fragment / (full) / Fragment / (full)
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
DTLSPlaintext DTLSPlaintext
Structure Structure
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The length field MAY be omitted by clearing the L bit, which means that the <t>The length field <bcp14>MAY</bcp14> be omitted by clearing the L bit, w hich means that the
record consumes the entire rest of the datagram in the lower record consumes the entire rest of the datagram in the lower
level transport. In this case it is not possible to have multiple level transport. In this case, it is not possible to have multiple
DTLSCiphertext format records without length fields in the same datagram. DTLSCiphertext format records without length fields in the same datagram.
Omitting the length field MUST only be used for the last record in a Omitting the length field <bcp14>MUST</bcp14> only be used for the last record i
datagram. Implementations MAY mix records with and without length n a
datagram. Implementations <bcp14>MAY</bcp14> mix records with and without length
fields on the same connection.</t> fields on the same connection.</t>
<t>If a Connection ID is negotiated, then it MUST be contained in all <t>If a Connection ID is negotiated, then it <bcp14>MUST</bcp14> be contai
datagrams. Sending implementations MUST NOT mix records from multiple DTLS assoc ned in all
iations datagrams. Sending implementations <bcp14>MUST NOT</bcp14> mix records from mult
iple DTLS associations
in the same datagram. If the second or later record has a connection in the same datagram. If the second or later record has a connection
ID which does not correspond to the same association used ID which does not correspond to the same association used
for previous records, the rest of the datagram MUST be discarded.</t> for previous records, the rest of the datagram <bcp14>MUST</bcp14> be discarded. </t>
<t>When expanded, the epoch and sequence number can be combined into an <t>When expanded, the epoch and sequence number can be combined into an
unpacked RecordNumber structure, as shown below:</t> unpacked RecordNumber structure, as shown below:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="tls-presentation"><![CDATA[
struct { struct {
uint16 epoch; uint64 epoch;
uint48 sequence_number; uint64 sequence_number;
} RecordNumber; } RecordNumber;
]]></artwork> ]]></sourcecode>
<t>This 64-bit value is used in the ACK message as well as in the "record_
sequence_number" <t>This 128-bit value is used in the ACK message as well as in the "record
input to the AEAD function.</t> _sequence_number"
<t>The entire header value shown in <xref target="hdr_examples" format="de input to the Authenticated Encryption with Associated Data (AEAD) function.
fault"/> (but prior to record number The entire header value shown in <xref target="hdr_examples" format="defau
encryption, see <xref target="rne" format="default"/>) is used as as the additio lt"/> (but prior to record number
nal data value for the AEAD encryption; see <xref target="rne" format="default"/>) is used as the additional
data value for the AEAD
function. For instance, if the minimal variant is used, function. For instance, if the minimal variant is used,
the AAD is 2 octets long. Note that this design is different from the additional the Associated Data (AD) is 2 octets long. Note that this design is different fr
data om the additional data
calculation for DTLS 1.2 and for DTLS 1.2 with Connection ID.</t> calculation for DTLS 1.2 and for DTLS 1.2 with Connection 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 "> <section anchor="demultiplexing-dtls-records" numbered="true" toc="default ">
<name>Demultiplexing DTLS Records</name> <name>Demultiplexing DTLS Records</name>
<t>DTLS 1.3 uses a variable length record format and hence the <t>
demultiplexing process is more complex since more header formats DTLS 1.3's header format is more complicated to demux than
need to be distinguished. Implementations can demultiplex DTLS 1.3 records DTLS 1.2, which always carried the content type as the first
by examining the first byte as follows:</t> byte. As described in <xref target="demux" format="default"/>, the first byte de
termines 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"/>.
Implementations can demultiplex DTLS 1.3 records
by examining the first byte as follows:
</t>
<ul spacing="normal"> <ul spacing="normal">
<li>If the first byte is alert(21), handshake(22), or ack(proposed, 26 ), <li>If the first byte is alert(21), handshake(22), or ack(proposed, 26 ),
the record MUST be interpreted as a DTLSPlaintext record.</li> the record <bcp14>MUST</bcp14> be interpreted as a DTLSPlaintext record.</li>
<li>If the first byte is any other value, then receivers <li>If the first byte is any other value, then receivers
MUST check to see if the leading bits of the first byte are <bcp14>MUST</bcp14> check to see if the leading bits of the first byte are
001. If so, the implementation MUST process the record as 001. If so, the implementation <bcp14>MUST</bcp14> process the record as
DTLSCiphertext; the true content type will be inside the DTLSCiphertext; the true content type will be inside the
protected portion.</li> protected portion.</li>
<li>Otherwise, the record MUST be rejected as if it had failed <li>Otherwise, the record <bcp14>MUST</bcp14> be rejected as if it had failed
deprotection, as described in <xref target="handling-invalid-records" format="de fault"/>.</li> deprotection, as described in <xref target="handling-invalid-records" format="de fault"/>.</li>
</ul> </ul>
<t><xref target="demux" format="default"/> shows this demultiplexing pro cedure graphically <t><xref target="demux" format="default"/> shows this demultiplexing pro cedure graphically,
taking DTLS 1.3 and earlier versions of DTLS into account.</t> taking DTLS 1.3 and earlier versions of DTLS into account.</t>
<figure anchor="demux"> <figure anchor="demux">
<name>Demultiplexing DTLS 1.2 and DTLS 1.3 Records</name> <name>Demultiplexing DTLS 1.2 and DTLS 1.3 Records</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
+----------------+ +----------------+
| Outer Content | | Outer Content |
| Type (OCT) | | Type (OCT) |
| | | |
| OCT == 20 -+--> ChangeCipherSpec (DTLS <1.3) | OCT == 20 -+--> ChangeCipherSpec (DTLS <1.3)
| OCT == 21 -+--> Alert (Plaintext) | OCT == 21 -+--> Alert (Plaintext)
| OCT == 22 -+--> Handshake (Plaintext) | OCT == 22 -+--> DTLSHandshake (Plaintext)
| OCT == 23 -+--> Application Data (DTLS <1.3) | OCT == 23 -+--> Application Data (DTLS <1.3)
| OCT == 24 -+--> Heartbeat (DTLS <1.3) | OCT == 24 -+--> Heartbeat (DTLS <1.3)
packet --> | OCT == 25 -+--> DTLSCipherText with CID (DTLS 1.2) packet --> | OCT == 25 -+--> DTLSCiphertext with CID (DTLS 1.2)
| OCT == 26 -+--> ACK (DTLS 1.3, Plaintext) | OCT == 26 -+--> ACK (DTLS 1.3, Plaintext)
| | | |
| | /+----------------+\ | | /+----------------+\
| 31 < OCT < 64 -+--> |DTLS Ciphertext | | 31 < OCT < 64 -+--> |DTLSCiphertext |
| | |(header bits | | | |(header bits |
| else | | start with 001)| | else | | start with 001)|
| | | /+-------+--------+\ | | | /+-------+--------+\
+-------+--------+ | +-------+--------+ |
| | | |
v Decryption | v Decryption |
+---------+ +------+ +---------+ +------+
| Reject | | | Reject | |
+---------+ v +---------+ v
+----------------+ +----------------+
| Decrypted | | Decrypted |
| Content Type | | Content Type |
| (DCT) | | (DCT) |
| | | |
| DCT == 21 -+--> Alert | DCT == 21 -+--> Alert
| DCT == 22 -+--> Handshake | DCT == 22 -+--> DTLSHandshake
| DCT == 23 -+--> Application Data | DCT == 23 -+--> Application Data
| DCT == 24 -+--> Heartbeat | DCT == 24 -+--> Heartbeat
| DCT == 26 -+--> ACK | DCT == 26 -+--> ACK
| | | else ------+--> Error
+----------------+ +----------------+
]]></artwork> ]]></artwork>
</figure> </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 determin
es 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>
<section anchor="sequence-number-and-epoch" numbered="true" toc="default"> <section anchor="sequence-number-and-epoch" numbered="true" toc="default">
<name>Sequence Number and Epoch</name> <name>Sequence Number and Epoch</name>
<t>DTLS uses an explicit or partly explicit sequence number, rather than an implicit one, <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 carried in the sequence_number field of the record. Sequence numbers
are maintained separately for each epoch, with each sequence_number are maintained separately for each epoch, with each sequence_number
initially being 0 for each epoch.</t> initially being 0 for each epoch.</t>
<t>The epoch number is initially zero and is incremented each time <t>The epoch number is initially zero and is incremented each time
keying material changes and a sender aims to rekey. More details keying material changes and a sender aims to rekey. More details
are provided in <xref target="dtls-epoch" format="default"/>.</t> are provided in <xref target="dtls-epoch" format="default"/>.</t>
<section anchor="processing-guidelines" numbered="true" toc="default"> <section anchor="processing-guidelines" numbered="true" toc="default">
<name>Processing Guidelines</name> <name>Processing Guidelines</name>
<t>Because DTLS records could be reordered, a record from epoch <t>Because DTLS records could be reordered, a record from epoch
M may be received after epoch N (where N &gt; M) has begun. M may be received after epoch N (where N &gt; M) has begun.
Implementations SHOULD discard records from earlier epochs, but Implementations <bcp14>SHOULD</bcp14> discard records from earlier epochs but
MAY choose to <bcp14>MAY</bcp14> choose to
retain keying material from previous epochs for up to the default MSL 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 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 intention here is that implementers use the current guidance from
the IETF for MSL, as specified in <xref target="RFC0793" format="default"/> or s uccessors, the IETF for MSL, as specified in <xref target="RFC0793" format="default"/> or s uccessors,
not that they attempt to interrogate the MSL that not that they attempt to interrogate the MSL that
the system TCP stack is using.)</t> the system TCP stack is using.)</t>
<t>Conversely, it is possible for records that are protected with the <t>Conversely, it is possible for records that are protected with the
new epoch to be received prior to the completion of a new epoch to be received prior to the completion of a
handshake. For instance, the server may send its Finished message handshake. For instance, the server may send its Finished message
and then start transmitting data. Implementations MAY either buffer and then start transmitting data. Implementations <bcp14>MAY</bcp14> either buf fer
or discard such records, though when DTLS is used over reliable or discard such records, though when DTLS is used over reliable
transports (e.g., SCTP <xref target="RFC4960" format="default"/>), they SHOULD b e buffered and transports (e.g., SCTP <xref target="RFC4960" format="default"/>), they <bcp14>S HOULD</bcp14> be buffered and
processed once the handshake completes. Note that TLS's restrictions processed once the handshake completes. Note that TLS's restrictions
on when records may be sent still apply, and the receiver treats the on when records may be sent still apply, and the receiver treats the
records as if they were sent in the right order.</t> records as if they were sent in the right order.</t>
<t>Implementations MUST send retransmissions of lost messages using th e same <t>Implementations <bcp14>MUST</bcp14> send retransmissions of lost me ssages using the same
epoch and keying material as the original transmission.</t> epoch and keying material as the original transmission.</t>
<t>Implementations MUST either abandon an association or re-key prior to <t>Implementations <bcp14>MUST</bcp14> either abandon an association o r rekey prior to
allowing the sequence number to wrap.</t> allowing the sequence number to wrap.</t>
<t>Implementations MUST NOT allow the epoch to wrap, but instead MUST <t>Implementations <bcp14>MUST NOT</bcp14> allow the epoch to wrap, bu t instead <bcp14>MUST</bcp14>
establish a new association, terminating the old association.</t> establish a new association, terminating the old association.</t>
</section> </section>
<section anchor="reconstructing" numbered="true" toc="default"> <section anchor="reconstructing" numbered="true" toc="default">
<name>Reconstructing the Sequence Number and Epoch</name> <name>Reconstructing the Sequence Number and Epoch</name>
<t>When receiving protected DTLS records, the recipient does not <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 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 opportunity for ambiguity. Because the full sequence number
are used to compute the per-record nonce, failure to reconstruct these is used to compute the per-record nonce and the epoch determines
the keys, failure to reconstruct these
values leads to failure to deprotect the record, and so implementations values leads to failure to deprotect the record, and so implementations
MAY use a mechanism of their choice to determine the full values. <bcp14>MAY</bcp14> use a mechanism of their choice to determine the full values.
This section provides an algorithm which is comparatively simple This section provides an algorithm which is comparatively simple
and which implementations are RECOMMENDED to follow.</t> and which implementations are <bcp14>RECOMMENDED</bcp14> to follow.</t>
<t>If the epoch bits match those of the current epoch, then <t>If the epoch bits match those of the current epoch, then
implementations SHOULD reconstruct the sequence number by computing implementations <bcp14>SHOULD</bcp14> reconstruct the sequence number by computi ng
the full sequence number which is numerically closest to one plus the the full sequence number which is numerically closest to one plus the
sequence number of the highest successfully deprotected record in the sequence number of the highest successfully deprotected record in the
current epoch.</t> current epoch.</t>
<t>During the handshake phase, the epoch bits unambiguously indicate t he <t>During the handshake phase, the epoch bits unambiguously indicate t he
correct key to use. After the correct key to use. After the
handshake is complete, if the epoch bits do not match those from the handshake is complete, if the epoch bits do not match those from the
current epoch implementations SHOULD use the most recent past epoch current epoch, implementations <bcp14>SHOULD</bcp14> use the most recent past ep och
which has matching bits, and then reconstruct the sequence number for which has matching bits, and then reconstruct the sequence number for
that epoch as described above.</t> that epoch as described above.</t>
</section> </section>
<section anchor="rne" numbered="true" toc="default"> <section anchor="rne" numbered="true" toc="default">
<name>Record Number Encryption</name> <name>Record Number Encryption</name>
<t>In DTLS 1.3, when records are encrypted, record sequence numbers ar e <t>In DTLS 1.3, when records are encrypted, record sequence numbers ar e
also encrypted. The basic pattern is that the underlying encryption also encrypted. The basic pattern is that the underlying encryption
algorithm used with the AEAD algorithm is used to generate a mask algorithm used with the AEAD algorithm is used to generate a mask
which is then XORed with the sequence number.</t> which is then XORed with the sequence number.</t>
<t>When the AEAD is based on AES, then the Mask is generated by <t>When the AEAD is based on AES, then the mask is generated by
computing AES-ECB on the first 16 bytes of the ciphertext:</t> computing AES-ECB on the first 16 bytes of the ciphertext:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
Mask = AES-ECB(sn_key, Ciphertext[0..15]) Mask = AES-ECB(sn_key, Ciphertext[0..15])
]]></artwork> ]]></artwork>
<t>When the AEAD is based on ChaCha20, then the mask is generated <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 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 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> block function (<xref target="RFC8439" sectionFormat="of" section="2.3"/>):</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
Mask = ChaCha20(sn_key, Ciphertext[0..3], Ciphertext[4..15]) Mask = ChaCha20(sn_key, Ciphertext[0..3], Ciphertext[4..15])
]]></artwork> ]]></artwork>
<t>The sn_key is computed as follows:</t> <t>The sn_key is computed as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
[sender]_sn_key = HKDF-Expand-Label(Secret, "sn" , "", key_length) [sender]_sn_key = HKDF-Expand-Label(Secret, "sn", "", key_length)
]]></artwork> ]]></artwork>
<t>[sender] denotes the sending side. The Secret value to be used is d
escribed <t>[sender] denotes the sending side. The per-epoch Secret value to be
in Section 7.3 of <xref target="TLS13" format="default"/>. Note that a new key i used is described
s used for each epoch: in <xref target="RFC8446" sectionFormat="of" section="7.3"/>. Note that a new ke
because the epoch is sent in the clear, this does not result in ambiguity.</t> y 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 <t>The encrypted sequence number is computed by XORing the leading
bytes of the Mask with the on-the-wire representation of the bytes of the mask with the on-the-wire representation of the
sequence number. Decryption is accomplished by the same process.</t> sequence number. Decryption is accomplished by the same process.</t>
<t>This procedure requires the ciphertext length be at least 16 bytes. <t>This procedure requires the ciphertext length to be at least 16 byt
Receivers es. Receivers
MUST reject shorter records as if they had failed deprotection, as described in <bcp14>MUST</bcp14> reject shorter records as if they had failed deprotection, a
<xref target="handling-invalid-records" format="default"/>. Senders MUST pad sho s described in
rt plaintexts out (using the <xref target="handling-invalid-records" format="default"/>. Senders <bcp14>MUST<
/bcp14> pad short plaintexts out (using the
conventional record padding mechanism) in order to make a suitable-length conventional record padding mechanism) in order to make a suitable-length
ciphertext. Note most of the DTLS AEAD algorithms have a 16-byte authentication ciphertext. Note that most of the DTLS AEAD algorithms have a 16 byte authentica
tag and need no padding. However, some algorithms such as tion
TLS_AES_128_CCM_8_SHA256 have a shorter authentication tag and may require paddi tag and need no padding. However, some algorithms, such as
ng TLS_AES_128_CCM_8_SHA256, have a shorter authentication tag and may require padd
ing
for short inputs.</t> for short inputs.</t>
<t>Future cipher suites, which are not based on AES or ChaCha20, MUST define <t>Future cipher suites, which are not based on AES or ChaCha20, <bcp1 4>MUST</bcp14> define
their own record sequence number encryption in order to be used with their own record sequence number encryption in order to be used with
DTLS.</t> DTLS.</t>
<t>Note that sequence number encryption is only applied to the DTLSCip hertext <t>Note that sequence number encryption is only applied to the DTLSCip hertext
structure and not to the DTLSPlaintext structure, which also contains a structure and not to the DTLSPlaintext structure, even though it also contains a
sequence number.</t> sequence number.</t>
</section> </section>
</section> </section>
<section anchor="transport-layer-mapping" numbered="true" toc="default"> <section anchor="transport-layer-mapping" numbered="true" toc="default">
<name>Transport Layer Mapping</name> <name>Transport Layer Mapping</name>
<t>DTLS messages MAY be fragmented into multiple DTLS records. <t>DTLS messages <bcp14>MAY</bcp14> be fragmented into multiple DTLS rec
Each DTLS record MUST fit within a single datagram. In order to ords.
avoid IP fragmentation, clients of the DTLS record layer SHOULD Each DTLS record <bcp14>MUST</bcp14> fit within a single datagram. In order to
avoid IP fragmentation, clients of the DTLS record layer <bcp14>SHOULD</bcp14>
attempt to size records so that they fit within any Path MTU (PMTU) estimates 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 obtained from the record layer. For more information about PMTU issues,
see <xref target="pmtu-issues" format="default"/>.</t> see <xref target="pmtu-issues" format="default"/>.</t>
<t>Multiple DTLS records MAY be placed in a single datagram. Records ar e encoded <t>Multiple DTLS records <bcp14>MAY</bcp14> be placed in a single datagr am. Records are encoded
consecutively. The length field from DTLS records containing that field can be consecutively. The length field from DTLS records containing that field can be
used to determine the boundaries between records. The final record in a 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 datagram can omit the length field. The first byte of the datagram payload <bcp
be the beginning of a record. Records MUST NOT span datagrams.</t> 14>MUST</bcp14>
be the beginning of a record. Records <bcp14>MUST NOT</bcp14> span datagrams.</
t>
<t>DTLS records without CIDs do not contain any association <t>DTLS records without CIDs do not contain any association
identifiers and applications must arrange to multiplex between associations. identifiers, and applications must arrange to multiplex between associations.
With UDP, the host/port number is used to look up the appropriate security With UDP, the host/port number is used to look up the appropriate security
association for incoming records without CIDs.</t> association for incoming records without CIDs.</t>
<t>Some transports, such as DCCP <xref target="RFC4340" format="default" />, provide their own sequence <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 numbers. When carried over those transports, both the DTLS and the
transport sequence numbers will be present. Although this introduces transport sequence numbers will be present. Although this introduces
a small amount of inefficiency, the transport layer and DTLS sequence a small amount of inefficiency, the transport layer and DTLS sequence
numbers serve different purposes; therefore, for conceptual simplicity, numbers serve different purposes; therefore, for conceptual simplicity,
it is superior to use both sequence numbers.</t> it is superior to use both sequence numbers.</t>
<t>Some transports provide congestion control for traffic <t>Some transports provide congestion control for traffic
carried over them. If the congestion window is sufficiently narrow, carried over them. If the congestion window is sufficiently narrow,
DTLS handshake retransmissions may be held rather than transmitted DTLS handshake retransmissions may be held rather than transmitted
immediately, potentially leading to timeouts and spurious immediately, potentially leading to timeouts and spurious
retransmission. When DTLS is used over such transports, care should retransmission. When DTLS is used over such transports, care should
be taken not to overrun the likely congestion window. <xref target="RFC5238" for mat="default"/> be taken not to overrun the likely congestion window. <xref target="RFC5238" for mat="default"/>
defines a mapping of DTLS to DCCP that takes these issues into account.</t> defines a mapping of DTLS to DCCP that takes these issues into account.</t>
</section> </section>
<section anchor="pmtu-issues" numbered="true" toc="default"> <section anchor="pmtu-issues" numbered="true" toc="default">
<name>PMTU Issues</name> <name>PMTU Issues</name>
<t>In general, DTLS's philosophy is to leave PMTU discovery to the appli cation. <t>In general, DTLS's philosophy is to leave PMTU discovery to the appli cation.
However, DTLS cannot completely ignore PMTU for three reasons:</t> However, DTLS cannot completely ignore the PMTU for three reasons:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The DTLS record framing expands the datagram size, thus lowering <li>The DTLS record framing expands the datagram size, thus lowering
the effective PMTU from the application's perspective.</li> the effective PMTU from the application's perspective.</li>
<li>In some implementations, the application may not directly talk to <li>In some implementations, the application may not directly talk to
the network, in which case the DTLS stack may absorb ICMP the network, in which case the DTLS stack may absorb ICMP
<xref target="RFC1191" format="default"/> "Datagram Too Big" indications or ICMP "Datagram Too Big" indications <xref target="RFC1191" format="default"/> or ICMP
v6 <xref target="RFC4443" format="default"/> v6
"Packet Too Big" indications.</li> "Packet Too Big" indications <xref target="RFC4443" format="default"/>.</li>
<li>The DTLS handshake messages can exceed the PMTU.</li> <li>The DTLS handshake messages can exceed the PMTU.</li>
</ul> </ul>
<t>In order to deal with the first two issues, the DTLS record layer <t>In order to deal with the first two issues, the DTLS record layer
SHOULD behave as described below.</t> <bcp14>SHOULD</bcp14> behave as described below.</t>
<t>If PMTU estimates are available from the underlying transport <t>If PMTU estimates are available from the underlying transport
protocol, they should be made available to upper layer protocol, they should be made available to upper layer
protocols. In particular:</t> protocols. In particular:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>For DTLS over UDP, the upper layer protocol SHOULD be allowed to <li>For DTLS over UDP, the upper layer protocol <bcp14>SHOULD</bcp14> be allowed to
obtain the PMTU estimate maintained in the IP layer.</li> obtain the PMTU estimate maintained in the IP layer.</li>
<li>For DTLS over DCCP, the upper layer protocol SHOULD be allowed to <li>For DTLS over DCCP, the upper layer protocol <bcp14>SHOULD</bcp14> be allowed to
obtain the current estimate of the PMTU.</li> obtain the current estimate of the PMTU.</li>
<li>For DTLS over TCP or SCTP, which automatically fragment and <li>For DTLS over TCP or SCTP, which automatically fragment and
reassemble datagrams, there is no PMTU limitation. However, the reassemble datagrams, there is no PMTU limitation. However, the
upper layer protocol MUST NOT write any record that exceeds the upper layer protocol <bcp14>MUST NOT</bcp14> write any record that exceeds the
maximum record size of 2^14 bytes.</li> maximum record size of 2^14 bytes.</li>
</ul> </ul>
<t>The DTLS record layer SHOULD also allow the upper layer protocol to <t>The DTLS record layer <bcp14>SHOULD</bcp14> also allow the upper laye r protocol to
discover the amount of record expansion expected by the DTLS discover the amount of record expansion expected by the DTLS
processing; alternately it MAY report PMTU estimates minus the processing; alternately, it <bcp14>MAY</bcp14> report PMTU estimates minus the
estimated expansion from the transport layer and DTLS record estimated expansion from the transport layer and DTLS record
framing.</t> framing.</t>
<t>Note that DTLS does not defend against spoofed ICMP messages; <t>Note that DTLS does not defend against spoofed ICMP messages;
implementations SHOULD ignore any such messages that indicate implementations <bcp14>SHOULD</bcp14> ignore any such messages that indicate
PMTUs below the IPv4 and IPv6 minimums of 576 and 1280 bytes PMTUs below the IPv4 and IPv6 minimums of 576 and 1280 bytes,
respectively.</t> respectively.</t>
<t>If there is a transport protocol indication that the PMTU was exceede d <t>If there is a transport protocol indication that the PMTU was exceede d
(either via ICMP or via a (either via ICMP or via a
refusal to send the datagram as in Section 14 of <xref target="RFC4340" format=" refusal to send the datagram as in <xref target="RFC4340" sectionFormat="of" sec
default"/>), then the tion="14"/>), then the
DTLS record layer MUST inform the upper layer protocol of the error.</t> DTLS record layer <bcp14>MUST</bcp14> inform the upper layer protocol of the err
<t>The DTLS record layer SHOULD NOT interfere with upper layer protocols or.</t>
<t>The DTLS record layer <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 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> IPv4 or via <xref target="RFC8201" format="default"/> for IPv6. In particular:< /t>
<ul spacing="normal"> <ul spacing="normal">
<li>Where allowed by the underlying transport protocol, the upper <li>Where allowed by the underlying transport protocol, the upper
layer protocol SHOULD be allowed to set the state of the DF bit layer protocol <bcp14>SHOULD</bcp14> be allowed to set the state of the Don't Fr agment (DF) bit
(in IPv4) or prohibit local fragmentation (in IPv6).</li> (in IPv4) or prohibit local fragmentation (in IPv6).</li>
<li>If the underlying transport protocol allows the application to <li>If the underlying transport protocol allows the application to
request PMTU probing (e.g., DCCP), the DTLS record layer SHOULD request PMTU probing (e.g., DCCP), the DTLS record layer <bcp14>SHOULD</bcp14>
honor this request.</li> honor this request.</li>
</ul> </ul>
<t>The final issue is the DTLS handshake protocol. From the perspective <t>The final issue is the DTLS handshake protocol. From the perspective
of the DTLS record layer, this is merely another upper layer of the DTLS record layer, this is merely another upper layer
protocol. However, DTLS handshakes occur infrequently and involve protocol. However, DTLS handshakes occur infrequently and involve
only a few round trips; therefore, the handshake protocol PMTU only a few round trips; therefore, the handshake protocol PMTU
handling places a premium on rapid completion over accurate PMTU handling places a premium on rapid completion over accurate PMTU
discovery. In order to allow connections under these circumstances, discovery. In order to allow connections under these circumstances,
DTLS implementations SHOULD follow the following rules:</t> DTLS implementations <bcp14>SHOULD</bcp14> follow the following rules:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>If the DTLS record layer informs the DTLS handshake layer that a <li>If the DTLS record layer informs the DTLS handshake layer that a
message is too big, the handshake layer SHOULD immediately attempt to fragment message is too big, the handshake layer <bcp14>SHOULD</bcp14> immediately attemp t to fragment
the message, using any existing information about the PMTU.</li> the message, using any existing information about the PMTU.</li>
<li>If repeated retransmissions do not result in a response, and the <li>If repeated retransmissions do not result in a response, and the
PMTU is unknown, subsequent retransmissions SHOULD back off to a PMTU is unknown, subsequent retransmissions <bcp14>SHOULD</bcp14> back off to a
smaller record size, fragmenting the handshake message as smaller record size, fragmenting the handshake message as
appropriate. This specification does not specify an exact number of appropriate. This specification does not specify an exact number of
retransmits to attempt before backing off, but 2-3 seems retransmits to attempt before backing off, but 2-3 seems
appropriate.</li> appropriate.</li>
</ul> </ul>
</section> </section>
<section anchor="record-payload-protection" numbered="true" toc="default"> <section anchor="record-payload-protection" numbered="true" toc="default">
<name>Record Payload Protection</name> <name>Record Payload Protection</name>
<t>Like TLS, DTLS transmits data as a series of protected records. The <t>Like TLS, DTLS transmits data as a series of protected records. The
rest of this section describes the details of that format.</t> rest of this section describes the details of that format.</t>
<section anchor="anti-replay" numbered="true" toc="default"> <section anchor="anti-replay" numbered="true" toc="default">
<name>Anti-Replay</name> <name>Anti-Replay</name>
<t>Each DTLS record contains a sequence number to provide replay prote ction. <t>Each DTLS record contains a sequence number to provide replay prote ction.
Sequence number verification SHOULD be performed using the following Sequence number verification <bcp14>SHOULD</bcp14> be performed using the follow
sliding window procedure, borrowed from Section 3.4.3 of <xref target="RFC4303" ing
format="default"/>. sliding window procedure, borrowed from <xref target="RFC4303" sectionFormat="of
" section="3.4.3"/>.
Because each epoch resets the sequence number space, a separate sliding Because each epoch resets the sequence number space, a separate sliding
window is needed for each epoch.</t> window is needed for each epoch.</t>
<t>The received record counter for an epoch MUST be initialized to <t>The received record counter for an epoch <bcp14>MUST</bcp14> be ini tialized to
zero when that epoch is first used. For each received record, the zero when that epoch is first used. For each received record, the
receiver MUST verify that the record contains a sequence number that receiver <bcp14>MUST</bcp14> verify that the record contains a sequence number t hat
does not duplicate the sequence number of any other record received does not duplicate the sequence number of any other record received
in that epoch during the lifetime of the association. in that epoch during the lifetime of the association.
This check SHOULD happen after This check <bcp14>SHOULD</bcp14> happen after
deprotecting the record; otherwise the record discard might itself deprotecting the record; otherwise, the record discard might itself
serve as a timing channel for the record number. Note that computing serve as a timing channel for the record number. Note that computing
the full record number from the partial is still a potential timing the full record number from the partial is still a potential timing
channel for the record number, though a less powerful one than whether channel for the record number, though a less powerful one than whether
the record was deprotected.</t> the record was deprotected.</t>
<t>Duplicates are rejected through the use of a sliding receive window . <t>Duplicates are rejected through the use of a sliding receive window .
(How the window is implemented is a local matter, but the following (How the window is implemented is a local matter, but the following
text describes the functionality that the implementation must text describes the functionality that the implementation must
exhibit.) The receiver SHOULD pick a window large enough to handle exhibit.) The receiver <bcp14>SHOULD</bcp14> pick a window large enough to handl e
any plausible reordering, which depends on the data rate. any plausible reordering, which depends on the data rate.
(The receiver does not notify the sender of the window (The receiver does not notify the sender of the window
size.)</t> size.)</t>
<t>The "right" edge of the window represents the highest validated <t>The "right" edge of the window represents the highest validated
sequence number value received in the epoch. Records that contain sequence number value received in the epoch. Records that contain
sequence numbers lower than the "left" edge of the window are sequence numbers lower than the "left" edge of the window are
rejected. Records falling within the window are checked against a rejected. Records falling within the window are checked against a
list of received records within the window. An efficient means for 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 performing this check, based on the use of a bit mask, is described in
Section 3.4.3 of <xref target="RFC4303" format="default"/>. If the received reco rd falls within the <xref target="RFC4303" sectionFormat="of" section="3.4.3"/>. If the received rec ord falls within the
window and is new, or if the record is to the right of the window, window and is new, or if the record is to the right of the window,
then the record is new.</t> then the record is new.
<t>The window MUST NOT be updated until the record has been deprotecte </t>
d <t>The window <bcp14>MUST NOT</bcp14> be updated due to a received rec
ord until that record has been deprotected
successfully.</t> successfully.</t>
</section> </section>
<section anchor="handling-invalid-records" numbered="true" toc="default" > <section anchor="handling-invalid-records" numbered="true" toc="default" >
<name>Handling Invalid Records</name> <name>Handling Invalid Records</name>
<t>Unlike TLS, DTLS is resilient in the face of invalid records (e.g., <t>Unlike TLS, DTLS is resilient in the face of invalid records (e.g.,
invalid formatting, length, MAC, etc.). In general, invalid records invalid formatting, length, MAC, etc.). In general, invalid records
SHOULD be silently discarded, thus preserving the association; <bcp14>SHOULD</bcp14> be silently discarded, thus preserving the association;
however, an error MAY be logged for diagnostic purposes. however, an error <bcp14>MAY</bcp14> be logged for diagnostic purposes.
Implementations which choose to generate an alert instead, MUST Implementations which choose to generate an alert instead <bcp14>MUST</bcp14>
generate fatal alerts to avoid attacks where the attacker generate fatal alerts to avoid attacks where the attacker
repeatedly probes the implementation to see how it responds to repeatedly probes the implementation to see how it responds to
various types of error. Note that if DTLS is run over UDP, then any various types of error. Note that if DTLS is run over UDP, then any
implementation which does this will be extremely susceptible to implementation which does this will be extremely susceptible to
denial-of-service (DoS) attacks because UDP forgery is so easy. DoS attacks because UDP forgery is so easy.
Thus, generating fatal alerts is NOT RECOMMENDED for such transports, both Thus, generating fatal alerts is <bcp14>NOT RECOMMENDED</bcp14> for such transpo
rts, both
to increase the reliability of DTLS service and to avoid the risk to increase the reliability of DTLS service and to avoid the risk
of spoofing attacks sending traffic to unrelated third parties.</t> of spoofing attacks sending traffic to unrelated third parties.</t>
<t>If DTLS is being carried over a transport that is resistant to <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 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 because an attacker will have difficulty forging a datagram that will
not be rejected by the transport layer.</t> not be rejected by the transport layer.</t>
<t>Note that because invalid records are rejected at a layer lower tha n <t>Note that because invalid records are rejected at a layer lower tha n
the handshake state machine, they do not affect pending the handshake state machine, they do not affect pending
retransmission timers.</t> retransmission timers.</t>
</section> </section>
<section anchor="aead-limits" numbered="true" toc="default"> <section anchor="aead-limits" numbered="true" toc="default">
<name>AEAD Limits</name> <name>AEAD Limits</name>
<t>Section 5.5 of TLS <xref target="TLS13" format="default"/> defines limits on the number of records that can <t><xref target="RFC8446" sectionFormat="of" section="5.5"/> defines l imits on the number of records that can
be protected using the same keys. These limits are specific to an AEAD be protected using the same keys. These limits are specific to an AEAD
algorithm, and apply equally to DTLS. Implementations SHOULD NOT protect more algorithm and apply equally to DTLS. Implementations <bcp14>SHOULD NOT</bcp14> p rotect more
records than allowed by the limit specified for the negotiated AEAD. records than allowed by the limit specified for the negotiated AEAD.
Implementations SHOULD initiate a key update before reaching this limit.</t> Implementations <bcp14>SHOULD</bcp14> initiate a key update before reaching this
<t><xref target="TLS13" format="default"/> does not specify a limit fo limit.</t>
r AEAD_AES_128_CCM, but the analysis in <t><xref 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 <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> same confidentiality protection as the limits specified in TLS.</t>
<t>The usage limits defined in TLS 1.3 exist for protection against at tacks <t>The usage limits defined in TLS 1.3 exist for protection against at tacks
on confidentiality and apply to successful applications of AEAD protection. The on confidentiality and apply to successful applications of AEAD protection. The
integrity protections in authenticated encryption also depend on limiting the integrity protections in authenticated encryption also depend on limiting the
number of attempts to forge packets. TLS achieves this by closing connections number of attempts to forge packets. TLS achieves this by closing connections
after any record fails an authentication check. In comparison, DTLS ignores any after any record fails an authentication check. In comparison, DTLS ignores any
packet that cannot be authenticated, allowing multiple forgery attempts.</t> packet that cannot be authenticated, allowing multiple forgery attempts.</t>
<t>Implementations MUST count the number of received packets that fail <t>Implementations <bcp14>MUST</bcp14> count the number of received pa ckets that fail
authentication with each key. If the number of packets that fail authentication authentication with each key. If the number of packets that fail authentication
exceed a limit that is specific to the AEAD in use, an implementation SHOULD exceeds a limit that is specific to the AEAD in use, an implementation <bcp14>SH
immediately close the connection. Implementations SHOULD initiate a key update OULD</bcp14>
immediately close the connection. Implementations <bcp14>SHOULD</bcp14> initiate
a key update
with update_requested before reaching this limit. Once a key update has been 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 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 than closing the connection. Applying a limit reduces the probability that an
attacker is able to successfully forge a packet; see <xref target="AEBounds" for mat="default"/> and attacker is able to successfully forge a packet; see <xref target="AEBounds" for mat="default"/> and
<xref target="ROBUST" format="default"/>.</t> <xref target="ROBUST" format="default"/>.</t>
<t>For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305, the limit <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 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 f or the AEAD_AES_128_GCM and analysis in <xref target="AEBounds" format="default"/> supports a higher limit f or AEAD_AES_128_GCM and
AEAD_AES_256_GCM, but this specification recommends a lower limit. For 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 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> 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, d oes not have a <t>The AEAD_AES_128_CCM_8 AEAD, as used in TLS_AES_128_CCM_8_SHA256, d oes not have a
limit on the number of records that fail authentication that both limits the 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 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, to the risk of denial of service; see <xref target="ccm-short" format="default"/ >. Therefore,
TLS_AES_128_CCM_8_SHA256 MUST NOT be used in DTLS without additional safeguards TLS_AES_128_CCM_8_SHA256 <bcp14>MUST NOT</bcp14> be used in DTLS without additio
against forgery. Implementations MUST set usage limits for AEAD_AES_128_CCM_8 nal safeguards
against forgery. Implementations <bcp14>MUST</bcp14> set usage limits for AEAD_A
ES_128_CCM_8
based on an understanding of any additional forgery protections that are used.</ t> based on an understanding of any additional forgery protections that are used.</ t>
<t>Any TLS cipher suite that is specified for use with DTLS MUST defin
e limits on <!-- [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 <bcp14>MUS
T</bcp14> define limits on
the use of the associated AEAD function that preserves margins for both the use of the associated AEAD function that preserves margins for both
confidentiality and integrity. That is, limits MUST be specified for the number confidentiality and integrity. That is, limits <bcp14>MUST</bcp14> be specified for the number
of packets that can be authenticated and for the number of packets that can fail 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 ana lysis upon which values are authentication before a key update is required. Providing a reference to any ana lysis upon which values are
based - and any assumptions used in that analysis - allows limits to be adapted based -- and any assumptions used in that analysis -- allows limits to be adapte d
to varying usage conditions.</t> to varying usage conditions.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="dtls" numbered="true" toc="default"> <section anchor="dtls" numbered="true" toc="default">
<name>The DTLS Handshake Protocol</name> <name>The DTLS Handshake Protocol</name>
<t>DTLS 1.3 re-uses the TLS 1.3 handshake messages and flows, with <t>DTLS 1.3 reuses the TLS 1.3 handshake messages and flows, with
the following changes:</t> the following changes:</t>
<ol spacing="normal" type="1"><li>To handle message loss, reordering, and fragmentation modifications to <ol spacing="normal" type="1"><li>To handle message loss, reordering, and fragmentation, modifications to
the handshake header are necessary.</li> the handshake header are necessary.</li>
<li>Retransmission timers are introduced to handle message loss.</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> <li>A new ACK content type has been added for reliable message delivery of handshake messages.</li>
</ol> </ol>
<t>Note that TLS 1.3 already supports a cookie extension, which is used to <t>
prevent denial-of-service attacks. This DoS prevention mechanism is In addition, DTLS reuses TLS 1.3's "cookie" extension to provide a return-routab
described in more detail below since UDP-based protocols are more vulnerable ility
to amplification attacks than a connection-oriented transport like TCP check as part of connection establishment. This is an important DoS
that performs return-routability checks as part of the connection establishment. prevention mechanism for UDP-based protocols, unlike TCP-based protocols, for wh
</t> ich
TCP establishes return-routability as part of the connection establishment.
</t>
<t>DTLS implementations do not use the TLS 1.3 "compatibility mode" descri bed in <t>DTLS implementations do not use the TLS 1.3 "compatibility mode" descri bed in
Section D.4 of <xref target="TLS13" format="default"/>. DTLS servers MUST NOT e <xref target="RFC8446" sectionFormat="of" section="D.4"/>. DTLS servers <bcp14>
cho the MUST NOT</bcp14> echo the
"legacy_session_id" value from the client and endpoints MUST NOT send ChangeCiph "legacy_session_id" value from the client and endpoints <bcp14>MUST NOT</bcp14>
erSpec send ChangeCipherSpec
messages.</t> messages.</t>
<t>With these exceptions, the DTLS message formats, flows, and logic are <t>With these exceptions, the DTLS message formats, flows, and logic are
the same as those of TLS 1.3.</t> the same as those of TLS 1.3.</t>
<section anchor="dos" numbered="true" toc="default"> <section anchor="dos" numbered="true" toc="default">
<name>Denial-of-Service Countermeasures</name> <name>Denial-of-Service Countermeasures</name>
<t>Datagram security protocols are extremely susceptible to a variety of <t>Datagram security protocols are extremely susceptible to a variety of
DoS attacks. Two attacks are of particular concern:</t> DoS attacks. Two attacks are of particular concern:</t>
<ol spacing="normal" type="1"><li>An attacker can consume excessive reso urces on the server by <ol spacing="normal" type="1"><li>An attacker can consume excessive reso urces on the server by
transmitting a series of handshake initiation requests, causing transmitting a series of handshake initiation requests, causing
the server to allocate state and potentially to perform the server to allocate state and potentially to perform
expensive cryptographic operations.</li> expensive cryptographic operations.</li>
<li>An attacker can use the server as an amplifier by sending <li>An attacker can use the server as an amplifier by sending
connection initiation messages with a forged source address that belongs to a connection initiation messages with a forged source address that belongs to a
victim. The server then sends its response to the victim victim. The server then sends its response to the victim
machine, thus flooding it. Depending on the selected machine, thus flooding it. Depending on the selected
parameters this response message can be quite large, as parameters, this response message can be quite large, as
is the case for a Certificate message.</li> is the case for a Certificate message.</li>
</ol> </ol>
<t>In order to counter both of these attacks, DTLS borrows the stateless <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 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 the client sends its ClientHello message to the server, the server
MAY respond with a HelloRetryRequest message. The HelloRetryRequest message, <bcp14>MAY</bcp14> respond with a HelloRetryRequest message. The HelloRetryReque
as well as the cookie extension, is defined in TLS 1.3. st message,
as well as the "cookie" extension, is defined in TLS 1.3.
The HelloRetryRequest message contains a stateless cookie (see The HelloRetryRequest message contains a stateless cookie (see
<xref target="TLS13" format="default"/>; Section 4.2.2). <xref target="RFC8446" sectionFormat="comma" section="4.2.2"/>).
The client MUST send a new ClientHello The client <bcp14>MUST</bcp14> send a new ClientHello
with the cookie added as an extension. The server then verifies the cookie 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 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 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 defens e with spoofed IP addresses difficult. This mechanism does not provide any defens e
against DoS attacks mounted from valid IP addresses.</t> against DoS attacks mounted from valid IP addresses.</t>
<t>The DTLS 1.3 specification changes how cookies are exchanged <t>The DTLS 1.3 specification changes how cookies are exchanged
compared to DTLS 1.2. DTLS 1.3 re-uses the HelloRetryRequest message compared to DTLS 1.2. DTLS 1.3 reuses the HelloRetryRequest message
and conveys the cookie to the client via an extension. The client and conveys the cookie to the client via an extension. The client
receiving the cookie uses the same extension to place receiving the cookie uses the same extension to place
the cookie subsequently into a ClientHello message. the cookie subsequently into a ClientHello message.
DTLS 1.2 on the other hand used a separate message, namely the HelloVerifyReques t, DTLS 1.2, on the other hand, used a separate message, namely the HelloVerifyRequ est,
to pass a cookie to the client and did not utilize the extension mechanism. to pass a cookie to the client and did not utilize the extension mechanism.
For backwards compatibility reasons, the cookie field in the ClientHello 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 server is present in DTLS 1.3 but is ignored by a DTLS 1.3-compliant server
implementation.</t> implementation.</t>
<t>The exchange is shown in <xref target="dtls-cookie-exchange" format=" default"/>. Note that <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 the figure focuses on the cookie exchange; all other extensions
are omitted.</t> are omitted.</t>
<figure anchor="dtls-cookie-exchange"> <figure anchor="dtls-cookie-exchange">
<name>DTLS exchange with HelloRetryRequest containing the "cookie" ext <name>DTLS Exchange with HelloRetryRequest Containing the "cookie" Ext
ension</name> ension</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
Client Server Client Server
------ ------ ------ ------
ClientHello ------> ClientHello ------>
<----- HelloRetryRequest <----- HelloRetryRequest
+ cookie + cookie
ClientHello ------> ClientHello ------>
+ cookie + cookie
[Rest of handshake] [Rest of handshake]
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The cookie extension is defined in Section 4.2.2 of <xref target="TLS 13" format="default"/>. When sending the <t>The "cookie" extension is defined in <xref target="RFC8446" sectionFo rmat="of" section="4.2.2"/>. When sending the
initial ClientHello, the client does not have a cookie yet. In this case, initial ClientHello, the client does not have a cookie yet. In this case,
the cookie extension is omitted and the legacy_cookie field in the ClientHello the "cookie" extension is omitted and the legacy_cookie field in the ClientHello
message MUST be set to a zero-length vector (i.e., a zero-valued single byte len message <bcp14>MUST</bcp14> be set to a zero-length vector (i.e., a zero-valued
gth field).</t> single byte length field).</t>
<t>When responding to a HelloRetryRequest, the client MUST create a new <t>When responding to a HelloRetryRequest, the client <bcp14>MUST</bcp14
ClientHello message following the description in Section 4.1.2 of <xref target=" > create a new
TLS13" format="default"/>.</t> ClientHello message following the description in <xref target="RFC8446" sectionF
ormat="of" section="4.1.2"/>.</t>
<t>If the HelloRetryRequest message is used, the initial ClientHello and <t>If the HelloRetryRequest message is used, the initial ClientHello and
the HelloRetryRequest are included in the calculation of the the HelloRetryRequest are included in the calculation of the
transcript hash. The computation of the transcript hash. The computation of the
message hash for the HelloRetryRequest is done according to the description message hash for the HelloRetryRequest is done according to the description
in Section 4.4.1 of <xref target="TLS13" format="default"/>.</t> in <xref target="RFC8446" sectionFormat="of" section="4.4.1"/>.</t>
<t>The handshake transcript is not reset with the second ClientHello <t>The handshake transcript is not reset with the second ClientHello,
and a stateless server-cookie implementation requires the content or hash and a stateless server-cookie implementation requires the content or hash
of the initial ClientHello (and HelloRetryRequest) of the initial ClientHello (and HelloRetryRequest)
to be stored in the cookie. The initial ClientHello is included in the 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 handshake transcript as a synthetic "message_hash" message, so only the hash
value is needed for the handshake to complete, though the complete value is needed for the handshake to complete, though the complete
HelloRetryRequest contents are needed.</t> HelloRetryRequest contents are needed.</t>
<t>When the second ClientHello is received, the server can verify that <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 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 given IP address. If the client's apparent IP address is embedded
in the cookie, this prevents an attacker from generating an acceptable in the cookie, this prevents an attacker from generating an acceptable
skipping to change at line 905 skipping to change at line 933
number of cookies from different addresses where it controls endpoints number of cookies from different addresses where it controls endpoints
and then reuse them to attack the server. and then reuse them to attack the server.
The server can defend against this attack by The server can defend against this attack by
changing the secret value frequently, thus invalidating those changing the secret value frequently, thus invalidating those
cookies. If the server wishes to allow legitimate clients to cookies. If the server wishes to allow legitimate clients to
handshake through the transition (e.g., a client received a cookie with handshake through the transition (e.g., a client received a cookie with
Secret 1 and then sent the second ClientHello after the server has Secret 1 and then sent the second ClientHello after the server has
changed to Secret 2), the server can have a limited window during changed to Secret 2), the server can have a limited window during
which it accepts both secrets. <xref target="RFC7296" format="default"/> sugges ts adding a key which it accepts both secrets. <xref target="RFC7296" format="default"/> sugges ts adding a key
identifier to cookies to detect this case. An alternative approach is identifier to cookies to detect this case. An alternative approach is
simply to try verifying with both secrets. It is RECOMMENDED that simply to try verifying with both secrets. It is <bcp14>RECOMMENDED</bcp14> that
servers implement a key rotation scheme that allows the server servers implement a key rotation scheme that allows the server
to manage keys with overlapping lifetime.</t> to manage keys with overlapping lifetimes.
</t>
<t>Alternatively, the server can store timestamps in the cookie and <t>Alternatively, the server can store timestamps in the cookie and
reject cookies that were generated outside a certain reject cookies that were generated outside a certain
interval of time.</t> interval of time.</t>
<t>DTLS servers SHOULD perform a cookie exchange whenever a new <t>DTLS servers <bcp14>SHOULD</bcp14> perform a cookie exchange whenever a new
handshake is being performed. If the server is being operated in an handshake is being performed. If the server is being operated in an
environment where amplification is not a problem, the server MAY be environment where amplification is not a problem, e.g., where
configured not to perform a cookie exchange. The default SHOULD be ICE <xref target="RFC8445" format="default"/> has been used to establish bidirec
that the exchange is performed, however. In addition, the server MAY tional connectivity,
the server <bcp14>MAY</bcp14> be
configured not to perform a cookie exchange. The default <bcp14>SHOULD</bcp14>
be
that the exchange is performed, however. In addition, the server <bcp14>MAY</bc
p14>
choose not to do a cookie exchange when a session is resumed or, more 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 generically, when the DTLS handshake uses a PSK-based key exchange
and the IP address matches one associated with the PSK. and the IP address matches one associated with the PSK.
Servers which process 0-RTT requests and send 0.5-RTT responses Servers which process 0-RTT requests and send 0.5-RTT responses without a cookie
without a cookie exchange risk being used in an amplification attack exchange risk being used in an amplification attack if the size of outgoing mes
if the size of outgoing messages greatly exceeds the size of those that are rece sages greatly exceeds the size of those that are received.
ived. A server <bcp14>SHOULD</bcp14> limit the amount of data it sends toward a client
A server SHOULD limit the amount of data it sends toward a client address address
to three times the amount of data sent by the client before 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. 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. A client address is valid after a cookie exchange or handshake completion.
Clients MUST be prepared to do a cookie exchange with every Clients <bcp14>MUST</bcp14> be prepared to do a cookie exchange with every
handshake. Note that cookies are only valid for the existing handshake. Note that cookies are only valid for the existing
handshake and cannot be stored for future handshakes.</t> handshake and cannot be stored for future handshakes.</t>
<t>If a server receives a ClientHello with an invalid cookie, it <t>If a server receives a ClientHello with an invalid cookie, it
MUST terminate the handshake with an "illegal_parameter" alert. <bcp14>MUST</bcp14> terminate the handshake with an "illegal_parameter" alert.
This allows the client to restart the connection from This allows the client to restart the connection from
scratch without a cookie.</t> scratch without a cookie.</t>
<t>As described in Section 4.1.4 of <xref target="TLS13" format="default "/>, clients MUST <t>As described in <xref target="RFC8446" sectionFormat="of" section="4. 1.4"/>, clients <bcp14>MUST</bcp14>
abort the handshake with an "unexpected_message" alert in response abort the handshake with an "unexpected_message" alert in response
to any second HelloRetryRequest which was sent in the same connection to any second HelloRetryRequest which was sent in the same connection
(i.e., where the ClientHello was itself in response to a HelloRetryRequest).</t> (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 <t>DTLS clients which do not want to receive a Connection ID <bcp14>SHOU
still offer the "connection_id" extension unless LD</bcp14>
still offer the "connection_id" extension <xref target="RFC9146" format="default
"/> unless
there is an application profile to the contrary. This permits there is an application profile to the contrary. This permits
a server which wants to receive a CID to negotiate one.</t> a server which wants to receive a CID to negotiate one.</t>
</section> </section>
<section anchor="dtls-handshake-message-format" numbered="true" toc="defau lt"> <section anchor="dtls-handshake-message-format" numbered="true" toc="defau lt">
<name>DTLS Handshake Message Format</name> <name>DTLS Handshake Message Format</name>
<t>In order to support message loss, reordering, and message <t>DTLS uses the same Handshake messages as TLS 1.3. However,
fragmentation, DTLS modifies the TLS 1.3 handshake header:</t> prior to transmission they are converted to DTLSHandshake
<artwork name="" type="" align="left" alt=""><![CDATA[ messages, which contain extra data needed to support
message loss, reordering, and message fragmentation.</t>
<sourcecode name="" type="tls-presentation"><![CDATA[
enum { enum {
client_hello(1), client_hello(1),
server_hello(2), server_hello(2),
new_session_ticket(4), new_session_ticket(4),
end_of_early_data(5), end_of_early_data(5),
encrypted_extensions(8), encrypted_extensions(8),
request_connection_id(9), /* New */
new_connection_id(10), /* New */
certificate(11), certificate(11),
certificate_request(13), certificate_request(13),
certificate_verify(15), certificate_verify(15),
finished(20), finished(20),
key_update(24), key_update(24),
message_hash(254), message_hash(254),
(255) (255)
} HandshakeType; } HandshakeType;
]]></sourcecode>
<sourcecode name="" type="tls-presentation"><![CDATA[
struct { struct {
HandshakeType msg_type; /* handshake type */ HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */ uint24 length; /* bytes in message */
uint16 message_seq; /* DTLS-required field */ uint16 message_seq; /* DTLS-required field */
uint24 fragment_offset; /* DTLS-required field */ uint24 fragment_offset; /* DTLS-required field */
uint24 fragment_length; /* DTLS-required field */ uint24 fragment_length; /* DTLS-required field */
select (msg_type) { select (msg_type) {
case client_hello: ClientHello; case client_hello: ClientHello;
case server_hello: ServerHello; case server_hello: ServerHello;
case end_of_early_data: EndOfEarlyData; case end_of_early_data: EndOfEarlyData;
case encrypted_extensions: EncryptedExtensions; case encrypted_extensions: EncryptedExtensions;
case certificate_request: CertificateRequest; case certificate_request: CertificateRequest;
case certificate: Certificate; case certificate: Certificate;
case certificate_verify: CertificateVerify; case certificate_verify: CertificateVerify;
case finished: Finished; case finished: Finished;
case new_session_ticket: NewSessionTicket; case new_session_ticket: NewSessionTicket;
case key_update: KeyUpdate; case key_update: KeyUpdate;
case request_connection_id: RequestConnectionId;
case new_connection_id: NewConnectionId;
} body; } body;
} Handshake; } DTLSHandshake;
]]></artwork> ]]></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 <t>The first message each side transmits in each association always has
message_seq = 0. Whenever a new message is generated, the message_seq = 0. Whenever a new message is generated, the
message_seq value is incremented by one. When a message is message_seq value is incremented by one. When a message is
retransmitted, the old message_seq value is re-used, i.e., not retransmitted, the old message_seq value is reused, i.e., not
incremented. From the perspective of the DTLS record layer, the retransmission i s incremented. From the perspective of the DTLS record layer, the retransmission i s
a new record. This record will have a new a new record. This record will have a new
DTLSPlaintext.sequence_number value.</t> DTLSPlaintext.sequence_number value.</t>
<t>Note: In DTLS 1.2 the message_seq was reset to zero in case of a <t indent="3">Note: In DTLS 1.2, the message_seq was reset to zero in ca se of a
rehandshake (i.e., renegotiation). On the surface, a rehandshake in DTLS 1.2 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, shares similarities with a post-handshake message exchange in DTLS 1.3. However,
in DTLS 1.3 the message_seq is not reset to allow distinguishing a in DTLS 1.3 the message_seq is not reset, to allow distinguishing a
retransmission from a previously sent post-handshake message from a newly retransmission from a previously sent post-handshake message from a newly
sent post-handshake message.</t> sent post-handshake message.</t>
<t>DTLS implementations maintain (at least notionally) a <t>DTLS implementations maintain (at least notionally) a
next_receive_seq counter. This counter is initially set to zero. next_receive_seq counter. This counter is initially set to zero.
When a handshake message is received, if its message_seq value matches When a handshake message is received, if its message_seq value matches
next_receive_seq, next_receive_seq is incremented and the message is next_receive_seq, next_receive_seq is incremented and the message is
processed. If the sequence number is less than next_receive_seq, the processed. If the sequence number is less than next_receive_seq, the
message MUST be discarded. If the sequence number is greater than message <bcp14>MUST</bcp14> be discarded. If the sequence number is greater tha
next_receive_seq, the implementation SHOULD queue the message but MAY n
discard it. (This is a simple space/bandwidth tradeoff).</t> next_receive_seq, the implementation <bcp14>SHOULD</bcp14> queue the message but
<bcp14>MAY</bcp14>
discard it. (This is a simple space/bandwidth trade-off).</t>
<t>In addition to the handshake messages that are deprecated by the TLS 1.3 <t>In addition to the handshake messages that are deprecated by the TLS 1.3
specification, DTLS 1.3 furthermore deprecates the HelloVerifyRequest message specification, DTLS 1.3 furthermore deprecates the HelloVerifyRequest message
originally defined in DTLS 1.0. DTLS 1.3-compliant implements MUST NOT originally defined in DTLS 1.0. DTLS 1.3-compliant implementations <bcp14>MUST N OT</bcp14>
use the HelloVerifyRequest to execute a return-routability check. A use the HelloVerifyRequest to execute a return-routability check. A
dual-stack DTLS 1.2/DTLS 1.3 client MUST, however, be prepared to dual-stack DTLS 1.2 / DTLS 1.3 client <bcp14>MUST</bcp14>, however, be prepared to
interact with a DTLS 1.2 server.</t> interact with a DTLS 1.2 server.</t>
</section> </section>
<section anchor="clienthello-message" numbered="true" toc="default"> <section anchor="clienthello-message" numbered="true" toc="default">
<name>ClientHello Message</name> <name>ClientHello Message</name>
<t>The format of the ClientHello used by a DTLS 1.3 client differs from the <t>The format of the ClientHello used by a DTLS 1.3 client differs from the
TLS 1.3 ClientHello format as shown below.</t> TLS 1.3 ClientHello format, as shown below.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="tls-presentation"><![CDATA[
uint16 ProtocolVersion; uint16 ProtocolVersion;
opaque Random[32]; opaque Random[32];
uint8 CipherSuite[2]; /* Cryptographic suite selector */ uint8 CipherSuite[2]; /* Cryptographic suite selector */
struct { struct {
ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2 ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2
Random random; Random random;
opaque legacy_session_id<0..32>; opaque legacy_session_id<0..32>;
opaque legacy_cookie<0..2^8-1>; // DTLS opaque legacy_cookie<0..2^8-1>; // DTLS
CipherSuite cipher_suites<2..2^16-2>; CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>; opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>; Extension extensions<8..2^16-1>;
} ClientHello; } ClientHello;
]]></artwork> ]]></sourcecode>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>legacy_version:</dt> <dt>legacy_version:</dt>
<dd> <dd>
In previous versions of DTLS, this field was used for version In previous versions of DTLS, this field was used for version
negotiation and represented the highest version number supported by negotiation and represented the highest version number supported by
the client. Experience has shown that many servers do not properly the client. Experience has shown that many servers do not properly
implement version negotiation, leading to "version intolerance" in implement version negotiation, leading to "version intolerance" in
which the server rejects an otherwise acceptable ClientHello with a which the server rejects an otherwise acceptable ClientHello with a
version number higher than it supports. In DTLS 1.3, the client version number higher than it supports. In DTLS 1.3, the client
indicates its version preferences in the "supported_versions" indicates its version preferences in the "supported_versions"
extension (see Section 4.2.1 of <xref target="TLS13" format="default"/>) and the extension (see <xref target="RFC8446" sectionFormat="of" section="4.2.1"/>) and
legacy_version field MUST be set to {254, 253}, which was the version the
legacy_version field <bcp14>MUST</bcp14> be set to {254, 253}, which was the ver
sion
number for DTLS 1.2. The supported_versions entries for DTLS 1.0 and DTLS 1.2 ar e number for DTLS 1.2. The supported_versions entries for DTLS 1.0 and DTLS 1.2 ar e
0xfeff and 0xfefd (to match the wire versions). The value 0xfefc is used 0xfeff and 0xfefd (to match the wire versions). The value 0xfefc is used
to indicate DTLS 1.3.</dd> to indicate DTLS 1.3.</dd>
<dt>random:</dt> <dt>random:</dt>
<dd> <dd>
Same as for TLS 1.3, except that the downgrade sentinels described Same as for TLS 1.3, except that the downgrade sentinels described
in Section 4.1.3 of <xref target="TLS13" format="default"/> when TLS 1.2 and TLS in <xref target="RFC8446" sectionFormat="of" section="4.1.3"/> when TLS 1.2
1.1 and below are negotiated and TLS 1.1 and below are negotiated apply to DTLS 1.2 and DTLS 1.0, respectivel
apply to DTLS 1.2 and DTLS 1.0 respectively.</dd> y.
</dd>
<dt>legacy_session_id:</dt> <dt>legacy_session_id:</dt>
<dd> <dd>
Versions of TLS and DTLS before version 1.3 supported a "session resumption" Versions of TLS and DTLS before version 1.3 supported a "session resumption"
feature which has been merged with pre-shared keys in version 1.3. A client feature, which has been merged with pre-shared keys (PSK) in version 1.3. A cli
which has a cached session ID set by a pre-DTLS 1.3 server SHOULD set this ent
field to that value. Otherwise, it MUST be set as a zero-length vector which has a cached session ID set by a pre-DTLS 1.3 server <bcp14>SHOULD</bcp14>
set this
field to that value. Otherwise, it <bcp14>MUST</bcp14> be set as a zero-length v
ector
(i.e., a zero-valued single byte length field).</dd> (i.e., a zero-valued single byte length field).</dd>
<dt>legacy_cookie:</dt> <dt>legacy_cookie:</dt>
<dd> <dd>
A DTLS 1.3-only client MUST set the legacy_cookie field to zero length. A DTLS 1.3-only client <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, If a DTLS 1.3 ClientHello is received with any other value in this field,
the server MUST abort the handshake with an "illegal_parameter" alert.</dd> the server <bcp14>MUST</bcp14> abort the handshake with an "illegal_parameter" a lert.</dd>
<dt>cipher_suites:</dt> <dt>cipher_suites:</dt>
<dd> <dd>
Same as for TLS 1.3; only suites with DTLS-OK=Y may be used.</dd> Same as for TLS 1.3; only suites with DTLS-OK=Y may be used.</dd>
<dt>legacy_compression_methods:</dt> <dt>legacy_compression_methods:</dt>
<dd> <dd>
Same as for TLS 1.3.</dd> Same as for TLS 1.3.</dd>
<dt>extensions:</dt> <dt>extensions:</dt>
<dd> <dd>
Same as for TLS 1.3.</dd> Same as for TLS 1.3.</dd>
</dl> </dl>
</section> </section>
<section anchor="serverhello-message" numbered="true" toc="default"> <section anchor="serverhello-message" numbered="true" toc="default">
<name>ServerHello Message</name> <name>ServerHello Message</name>
<t>The DTLS 1.3 ServerHello message is the same as the TLS 1.3 <t>The DTLS 1.3 ServerHello message is the same as the TLS 1.3
ServerHello message, except that the legacy_version field ServerHello message, except that the legacy_version field
is set to 0xfefd, indicating DTLS 1.2.</t> is set to 0xfefd, indicating DTLS 1.2.</t>
</section> </section>
<section anchor="handshake-message-fragmentation-and-reassembly" numbered= "true" toc="default"> <section anchor="handshake-message-fragmentation-and-reassembly" numbered= "true" toc="default">
<name>Handshake Message Fragmentation and Reassembly</name> <name>Handshake Message Fragmentation and Reassembly</name>
<t>As described in <xref target="transport-layer-mapping" format="defaul t"/> one or more handshake <t>As described in <xref target="transport-layer-mapping" format="defaul t"/>, one or more handshake
messages may be carried in a single datagram. However, handshake messages are messages may be carried in a single datagram. However, handshake messages are
potentially bigger than the size allowed by the underlying datagram transport. potentially bigger than the size allowed by the underlying datagram transport.
DTLS provides a mechanism for fragmenting a handshake message over a DTLS provides a mechanism for fragmenting a handshake message over a
number of records, each of which can be transmitted in separate datagrams, thus number of records, each of which can be transmitted in separate datagrams, thus
avoiding IP fragmentation.</t> avoiding IP fragmentation.</t>
<t>When transmitting the handshake message, the sender divides the <t>When transmitting the handshake message, the sender divides the
message into a series of N contiguous data ranges. The ranges MUST NOT message into a series of N contiguous data ranges. The ranges <bcp14>MUST NOT</b
overlap. The sender then creates N handshake messages, all with the cp14>
same message_seq value as the original handshake message. Each new overlap. The sender then creates N DTLSHandshake messages, all with the
same message_seq value as the original DTLSHandshake message. Each new
message is labeled with the fragment_offset (the number of bytes message is labeled with the fragment_offset (the number of bytes
contained in previous fragments) and the fragment_length (the length contained in previous fragments) and the fragment_length (the length
of this fragment). The length field in all messages is the same as of this fragment). The length field in all messages is the same as
the length field of the original message. An unfragmented message is the length field of the original message. An unfragmented message is
a degenerate case with fragment_offset=0 and fragment_length=length. a degenerate case with fragment_offset=0 and fragment_length=length.
Each handshake message fragment that is placed into a record Each handshake message fragment that is placed into a record
MUST be delivered in a single UDP datagram.</t> <bcp14>MUST</bcp14> be delivered in a single UDP datagram.</t>
<t>When a DTLS implementation receives a handshake message fragment corr esponding <t>When a DTLS implementation receives a handshake message fragment corr esponding
to the next expected handshake message sequence number, it to the next expected handshake message sequence number, it
MUST buffer it until it has the entire handshake message. DTLS <bcp14>MUST</bcp14> process it, either by buffering it until it has the entire
implementations MUST be able to handle overlapping fragment ranges. 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 <bcp14>MUST</bcp14> be able to handle overlapping fragment range
s.
This allows senders to retransmit handshake messages with smaller This allows senders to retransmit handshake messages with smaller
fragment sizes if the PMTU estimate changes. Senders MUST NOT change fragment sizes if the PMTU estimate changes. Senders <bcp14>MUST NOT</bcp14> cha
handshake message bytes upon retransmission. Receivers MAY check nge
that retransmitted bytes are identical and SHOULD abort the handshake handshake message bytes upon retransmission. Receivers <bcp14>MAY</bcp14> check
that retransmitted bytes are identical and <bcp14>SHOULD</bcp14> abort the hands
hake
with an "illegal_parameter" alert if the value of a byte changes.</t> 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 <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 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 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 two DTLS handshake messages into the same datagram: in the same record or in
separate records.</t> separate records.</t>
</section> </section>
<section anchor="end-of-early-data" numbered="true" toc="default"> <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 <t>The DTLS 1.3 handshake has one important difference from the
TLS 1.3 handshake: the EndOfEarlyData message is omitted both TLS 1.3 handshake: the EndOfEarlyData message is omitted both
from the wire and the handshake transcript: because DTLS from the wire and the handshake transcript. Because DTLS
records have epochs, EndOfEarlyData is not necessary to determine records have epochs, EndOfEarlyData is not necessary to determine
when the early data is complete, and because DTLS is lossy, when the early data is complete, and because DTLS is lossy,
attackers can trivially mount the deletion attacks that EndOfEarlyData attackers can trivially mount the deletion attacks that EndOfEarlyData
prevents in TLS. Servers SHOULD NOT accept records from epoch 1 indefinitely onc e 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 co uld discard epoch 1 keys after the first epoch 3 data arrives, or retain keys f or processing epoch 1 data for a short period. prevents in TLS. Servers <bcp14>SHOULD NOT</bcp14> accept records from epoch 1 i ndefinitely once they are able to process records from epoch 3. Though reorderin g of IP packets can result in records from epoch 1 arriving after records from e poch 3, this is not likely to persist for very long relative to the round trip t ime. Servers could discard epoch 1 keys after the first epoch 3 data arrives, o r retain keys for processing epoch 1 data for a short period.
(See <xref target="dtls-epoch" format="default"/> for the definitions of each ep och.)</t> (See <xref target="dtls-epoch" format="default"/> for the definitions of each ep och.)</t>
</section> </section>
<section anchor="dtls-handshake-flights" numbered="true" toc="default"> <section anchor="dtls-handshake-flights" numbered="true" toc="default">
<name>DTLS Handshake Flights</name> <name>DTLS Handshake Flights</name>
<t>DTLS handshake messages are grouped into a series of message flights. A flight starts with the <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 f rom the handshake message transmission of one peer and ends with the expected response f rom the
other peer. <xref target="tab-flights" format="default"/> contains a complete li st of message combinations that constitute flights.</t> other peer. <xref target="tab-flights" format="default"/> contains a complete li st of message combinations that constitute flights.</t>
<table anchor="tab-flights" align="center"> <table anchor="tab-flights" align="center">
<name>Flight Handshake Message Combinations.</name> <name>Flight Handshake Message Combinations</name>
<thead> <thead>
<tr> <tr>
<th align="left">Note</th> <th align="left">Note</th>
<th align="left">Client</th> <th align="left">Client</th>
<th align="left">Server</th> <th align="left">Server</th>
<th align="left">Handshake Messages</th> <th align="left">Handshake Messages</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
skipping to change at line 1176 skipping to change at line 1233
<td align="left">&nbsp;</td> <td align="left">&nbsp;</td>
<td align="left">x</td> <td align="left">x</td>
<td align="left">NewSessionTicket</td> <td align="left">NewSessionTicket</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Remarks:</t> <t>Remarks:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<xref target="tab-flights" format="default"/> does not highlight any of the optional messages.</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 ex pected response, as it is the case with <li>Regarding note (1): When a handshake flight is sent without any ex pected response, as is the case with
the client's final flight or with the NewSessionTicket message, the flight must be the client's final flight or with the NewSessionTicket message, the flight must be
acknowledged with an ACK message.</li> acknowledged with an ACK message.</li>
</ul> </ul>
<t>Below are several example message exchange illustrating the flight co <t>Below are several example message exchanges illustrating the flight c
ncept. oncept.
The notational conventions from <xref target="TLS13" format="default"/> are used The notational conventions from <xref target="RFC8446" format="default"/> are us
.</t> ed.</t>
<figure anchor="dtls-full"> <figure anchor="dtls-full">
<name>Message flights for a full DTLS Handshake (with cookie exchange) <name>Message Flights for a Full DTLS Handshake (with Cookie Exchange)
</name> </name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
Client Server Client Server
+--------+ +--------+
ClientHello | Flight | ClientHello | Flight |
--------> +--------+ --------> +--------+
+--------+ +--------+
<-------- HelloRetryRequest | Flight | <-------- HelloRetryRequest | Flight |
+ cookie +--------+ + cookie +--------+
+--------+ +--------+
ClientHello | Flight | ClientHello | Flight |
+ cookie --------> +--------+ + cookie --------> +--------+
ServerHello ServerHello
{EncryptedExtensions} +--------+ {EncryptedExtensions} +--------+
{CertificateRequest*} | Flight | {CertificateRequest*} | Flight |
{Certificate*} +--------+ {Certificate*} +--------+
{CertificateVerify*} {CertificateVerify*}
{Finished} {Finished}
<-------- [Application Data*] <-------- [Application Data*]
{Certificate*} +--------+ {Certificate*} +--------+
{CertificateVerify*} | Flight | {CertificateVerify*} | Flight |
{Finished} --------> +--------+ {Finished} --------> +--------+
[Application Data] [Application Data]
+--------+
<-------- [ACK] | Flight |
[Application Data*] +--------+
+--------+ [Application Data] <-------> [Application Data]
<-------- [ACK] | Flight |
[Application Data*] +--------+
[Application Data] <-------> [Application Data]
]]></artwork> ]]></artwork>
</figure> </figure>
<figure anchor="dtls-psk"> <figure anchor="dtls-psk">
<name>Message flights for resumption and PSK handshake (without cookie <name>Message Flights for Resumption and PSK Handshake (without Cookie
exchange)</name> Exchange)</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
ClientHello +--------+ ClientHello +--------+
+ pre_shared_key | Flight | + pre_shared_key | Flight |
+ psk_key_exchange_modes +--------+ + psk_key_exchange_modes +--------+
+ key_share* --------> + key_share* -------->
ServerHello ServerHello
+ pre_shared_key +--------+ + pre_shared_key +--------+
+ key_share* | Flight | + key_share* | Flight |
{EncryptedExtensions} +--------+ {EncryptedExtensions} +--------+
<-------- {Finished} <-------- {Finished}
skipping to change at line 1245 skipping to change at line 1301
[Application Data*] +--------+ [Application Data*] +--------+
+--------+ +--------+
<-------- [ACK] | Flight | <-------- [ACK] | Flight |
[Application Data*] +--------+ [Application Data*] +--------+
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
]]></artwork> ]]></artwork>
</figure> </figure>
<figure anchor="dtls-zero-rtt"> <figure anchor="dtls-zero-rtt">
<name>Message flights for the Zero-RTT handshake</name> <name>Message Flights for the Zero-RTT Handshake</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
Client Server Client Server
ClientHello ClientHello
+ early_data + early_data
+ psk_key_exchange_modes +--------+ + psk_key_exchange_modes +--------+
+ key_share* | Flight | + key_share* | Flight |
+ pre_shared_key +--------+ + pre_shared_key +--------+
(Application Data*) --------> (Application Data*) -------->
ServerHello ServerHello
skipping to change at line 1275 skipping to change at line 1331
[Application Data*] +--------+ [Application Data*] +--------+
+--------+ +--------+
<-------- [ACK] | Flight | <-------- [ACK] | Flight |
[Application Data*] +--------+ [Application Data*] +--------+
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
]]></artwork> ]]></artwork>
</figure> </figure>
<figure anchor="dtls-post-handshake-ticket"> <figure anchor="dtls-post-handshake-ticket">
<name>Message flights for the NewSessionTicket message</name> <name>Message Flights for the NewSessionTicket Message</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
Client Server Client Server
+--------+ +--------+
<-------- [NewSessionTicket] | Flight | <-------- [NewSessionTicket] | Flight |
+--------+ +--------+
+--------+ +--------+
[ACK] --------> | Flight | [ACK] --------> | Flight |
+--------+ +--------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>KeyUpdate, NewConnectionId and RequestConnectionId follow a similar <t>KeyUpdate, NewConnectionId, and RequestConnectionId follow a similar
pattern to NewSessionTicket: a single message sent by one side pattern
to NewSessionTicket: a single message sent by one side
followed by an ACK by the other.</t> followed by an ACK by the other.</t>
</section> </section>
<section anchor="timeout-retransmissions" numbered="true" toc="default"> <section anchor="timeout-retransmissions" numbered="true" toc="default">
<name>Timeout and Retransmission</name> <name>Timeout and Retransmission</name>
<section anchor="state-machine" numbered="true" toc="default"> <section anchor="state-machine" numbered="true" toc="default">
<name>State Machine</name> <name>State Machine</name>
<t>DTLS uses a simple timeout and retransmission scheme with the <t>DTLS uses a simple timeout and retransmission scheme with the
state machine shown in <xref target="dtls-timeout-state-machine" format="default "/>.</t> state machine shown in <xref target="dtls-timeout-state-machine" format="default "/>.</t>
<figure anchor="dtls-timeout-state-machine"> <figure anchor="dtls-timeout-state-machine">
<name>DTLS timeout and retransmission state machine</name> <name>DTLS Timeout and Retransmission State Machine</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
+-----------+ +-----------+
| PREPARING | | PREPARING |
+----------> | | +----------> | |
| | | | | |
| +-----------+ | +-----------+
| | | |
| | Buffer next flight | | Buffer next flight
| | | |
| \|/ | \|/
| +-----------+ | +-----------+
skipping to change at line 1358 skipping to change at line 1414
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The state machine has four basic states: PREPARING, SENDING, WAITIN G, <t>The state machine has four basic states: PREPARING, SENDING, WAITIN G,
and FINISHED.</t> and FINISHED.</t>
<t>In the PREPARING state, the implementation does whatever computatio ns <t>In the PREPARING state, the implementation does whatever computatio ns
are necessary to prepare the next flight of messages. It then are necessary to prepare the next flight of messages. It then
buffers them up for transmission (emptying the transmission buffers them up for transmission (emptying the transmission
buffer first) and enters the SENDING state.</t> buffer first) and enters the SENDING state.</t>
<t>In the SENDING state, the implementation transmits the buffered <t>In the SENDING state, the implementation transmits the buffered
flight of messages. If the implementation has received one or more flight of messages. If the implementation has received one or more
ACKs (see <xref target="ack-msg" format="default"/>) from the peer, then it SHOU ACKs (see <xref target="ack-msg" format="default"/>) from the peer, then it <bcp
LD omit any messages or 14>SHOULD</bcp14> omit any messages or
message fragments which have already been ACKed. Once the messages message fragments which have already been acknowledged. Once the messages
have been sent, the implementation then sets a retransmit timer have been sent, the implementation then sets a retransmit timer
and enters the WAITING state.</t> and enters the WAITING state.</t>
<t>There are four ways to exit 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 im plementation transitions to <ol spacing="normal" type="1"><li>The retransmit timer expires: the im plementation transitions to
the SENDING state, where it retransmits the flight, adjusts and re-arms the the SENDING state, where it retransmits the flight, adjusts and re-arms the
retransmit timer (see <xref target="timer-values" format="default"/>), and retur ns to the WAITING state.</li> retransmit timer (see <xref target="timer-values" format="default"/>), and retur ns to the WAITING state.</li>
<li>The implementation reads an ACK from the peer: upon receiving <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"/>), an ACK for a partial flight (as mentioned in <xref target="sending-acks" format= "default"/>),
the implementation transitions the implementation transitions
to the SENDING state, where it retransmits the unacked portion to the SENDING state, where it retransmits the unacknowledged portion
of the flight, adjusts and re-arms the retransmit timer, and returns to the of the flight, adjusts and re-arms the retransmit timer, and returns to the
WAITING state. Upon receiving an ACK for a complete flight, WAITING state.
Upon receiving an ACK for a complete flight,
the implementation cancels all retransmissions and either the implementation cancels all retransmissions and either
remains in WAITING, or, if the ACK was for the final flight, remains in WAITING, or, if the ACK was for the final flight,
transitions to FINISHED.</li> transitions to FINISHED.</li>
<li>The implementation reads a retransmitted flight from the peer: t <li>The implementation reads a retransmitted flight from the peer
he 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 implementation transitions to the SENDING state, where it
retransmits the flight, adjusts and re-arms the retransmit timer, and returns 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 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 duplicate message is the likely result of timer expiry on the peer
and therefore suggests that part of one's previous flight was and therefore suggests that part of one's previous flight was
lost.</li> lost.</li>
<li>The implementation receives some or all of the next flight of me ssages: if <li>The implementation receives some or all of the next flight of me ssages: if
this is the final flight of messages, the implementation this is the final flight of messages, the implementation
transitions to FINISHED. If the implementation needs to send a new transitions to FINISHED. If the implementation needs to send a new
flight, it transitions to the PREPARING state. Partial reads flight, it transitions to the PREPARING state. Partial reads
(whether partial messages or only some of the messages in the (whether partial messages or only some of the messages in the
flight) may also trigger the implementation to send an ACK, as flight) may also trigger the implementation to send an ACK, as
described in <xref target="sending-acks" format="default"/>.</li> described in <xref target="sending-acks" format="default"/>.</li>
</ol> </ol>
<t>Because DTLS clients send the first message (ClientHello), they sta rt <t>Because DTLS clients send the first message (ClientHello), they sta rt
in the PREPARING state. DTLS servers start in the WAITING state, but in the PREPARING state. DTLS servers start in the WAITING state, but
with empty buffers and no retransmit timer.</t> with empty buffers and no retransmit timer.</t>
<t>In addition, for at least twice the default MSL defined for <xref t arget="RFC0793" format="default"/>, <t>In addition, for at least twice the default MSL defined for <xref t arget="RFC0793" format="default"/>,
when in the FINISHED state, the server MUST respond to retransmission when in the FINISHED state, the server <bcp14>MUST</bcp14> respond to retransmis sion
of the client's final flight with a retransmit of its ACK.</t> 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 <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 sending application data even though the other side has not received
the first side's Finished message. Implementations MUST either the first side's Finished message. Implementations <bcp14>MUST</bcp14> either
discard or buffer all application data records for epoch 3 and discard or buffer all application data records for epoch 3 and
above until they have received the Finished message from the above until they have received the Finished message from the
peer. Implementations MAY treat receipt of application data with a new peer. Implementations <bcp14>MAY</bcp14> treat receipt of application data with a new
epoch prior to receipt of the corresponding Finished message as epoch prior to receipt of the corresponding Finished message as
evidence of reordering or packet loss and retransmit their final evidence of reordering or packet loss and retransmit their final
flight immediately, shortcutting the retransmission timer.</t> flight immediately, shortcutting the retransmission timer.</t>
</section> </section>
<section anchor="timer-values" numbered="true" toc="default"> <section anchor="timer-values" numbered="true" toc="default">
<name>Timer Values</name> <name>Timer Values</name>
<t>The configuration of timer settings varies with implementations, an d certain <t>The configuration of timer settings varies with implementations, an d certain
deployment environments require timer value adjustments. Mishandling deployment environments require timer value adjustments. Mishandling
of the timer can lead to serious congestion problems, for example if of the timer can lead to serious congestion problems -- for example, if
many instances of a DTLS time out early and retransmit too quickly on many instances of a DTLS time out early and retransmit too quickly on
a congested link.</t> a congested link.</t>
<t>Unless implementations have deployment-specific and/or external inf ormation about the round trip time, <t>Unless implementations have deployment-specific and/or external inf ormation about the round trip time,
implementations SHOULD use an initial timer value of 1000 ms and double implementations <bcp14>SHOULD</bcp14> use an initial timer value of 1000 ms and
the value at each retransmission, up to no less than 60 seconds (the double
RFC 6298 <xref target="RFC6298" format="default"/> maximum). Application specifi the value at each retransmission, up to no less than 60 seconds (the maximum as
c profiles MAY specified in
RFC 6298 <xref target="RFC6298" format="default"/>). Application-specific profil
es <bcp14>MAY</bcp14>
recommend shorter or longer timer values. For instance:</t> recommend shorter or longer timer values. For instance:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Profiles for specific deployment environments, such as in low-po wer, <li>Profiles for specific deployment environments, such as in low-po wer,
multi-hop mesh scenarios as used in some Internet of Things (IoT) networks, multi-hop mesh scenarios as used in some Internet of Things (IoT) networks,
MAY specify longer timeouts. See <xref target="I-D.ietf-uta-tls13-iot-profile" f ormat="default"/> for <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> more information about one such DTLS 1.3 IoT profile.</li>
<li>Real-time protocols MAY specify shorter timeouts. It is RECOMMEN DED <li>Real-time protocols <bcp14>MAY</bcp14> specify shorter timeouts. It is <bcp14>RECOMMENDED</bcp14>
that for DTLS-SRTP <xref target="RFC5764" format="default"/>, a default timeout of that for DTLS-SRTP <xref target="RFC5764" format="default"/>, a default timeout of
400ms be used; because customer experience degrades with one-way latencies 400 ms be used; because customer experience degrades with one-way latencies
of greater than 200ms, real-time deployments are less likely of greater than 200 ms, real-time deployments are less likely
to have long latencies.</li> to have long latencies.</li>
</ul> </ul>
<t>In settings where there is external information (for instance from <t>In settings where there is external information (for instance, from
an ICE <xref target="RFC8445" format="default"/> an ICE <xref target="RFC8445" format="default"/> handshake, or from previous co
handshake, or from previous connections to the same server) nnections to the same server)
about the RTT, implementations SHOULD use 1.5 times that RTT estimate about the RTT, implementations <bcp14>SHOULD</bcp14> use 1.5 times that RTT esti
mate
as the retransmit timer.</t> as the retransmit timer.</t>
<t>Implementations SHOULD retain the current timer value until a <t>Implementations <bcp14>SHOULD</bcp14> retain the current timer valu e until a
message is transmitted and acknowledged without having to message is transmitted and acknowledged without having to
be retransmitted, at which time the value SHOULD be adjusted be retransmitted, at which time the value <bcp14>SHOULD</bcp14> be adjusted
to 1.5 times the measured round trip time for that to 1.5 times the measured round trip time for that
message. After a long period of idleness, no less message. After a long period of idleness, no less
than 10 times the current timer value, implementations MAY reset the than 10 times the current timer value, implementations <bcp14>MAY</bcp14> reset the
timer to the initial value.</t> timer to the initial value.</t>
<t>Note that because retransmission is for the handshake and not dataf low, the effect on <t>Note that because retransmission is for the handshake and not dataf low, the effect on
congestion of shorter timeouts is smaller than in generic protocols congestion of shorter timeouts is smaller than in generic protocols
such as TCP or QUIC. Experience with DTLS 1.2, which uses a such as TCP or QUIC. Experience with DTLS 1.2, which uses a
simpler "retransmit everything on timeout" approach, has not shown simpler "retransmit everything on timeout" approach, has not shown
serious congestion problems in practice.</t> serious congestion problems in practice.</t>
</section> </section>
<section anchor="large-flight-sizes" numbered="true" toc="default"> <section anchor="large-flight-sizes" numbered="true" toc="default">
<name>Large Flight Sizes</name> <name>Large Flight Sizes</name>
<t>DTLS does not have any built-in congestion control or rate control; <t>DTLS does not have any built-in congestion control or rate control;
in general this is not an issue because messages tend to be small. in general, this is not an issue because messages tend to be small.
However, in principle, some messages - especially Certificate - can However, in principle, some messages -- especially Certificate -- can
be quite large. If all the messages in a large flight are sent be quite large. If all the messages in a large flight are sent
at once, this can result in network congestion. A better strategy at once, this can result in network congestion. A better strategy
is to send out only part of the flight, sending more when is to send out only part of the flight, sending more when
messages are acknowledged. Several extensions have been standardized messages are acknowledged. Several extensions have been standardized
to reduce the size of the certificate message, for example to reduce the size of the Certificate message -- for example,
the cached information extension <xref target="RFC7924" format="default"/>, cert the "cached_info" extension <xref target="RFC7924" format="default"/>; certifica
ificate te
compression <xref target="RFC8879" format="default"/> and <xref target="RFC6066" compression <xref target="RFC8879" format="default"/>; and <xref target="RFC6066
format="default"/>, which defines the "client_certificate_url" " format="default"/>, which defines the "client_certificate_url"
extension allowing DTLS clients to send a sequence of Uniform extension allowing DTLS clients to send a sequence of Uniform
Resource Locators (URLs) instead of the client certificate.</t> Resource Locators (URLs) instead of the client certificate.</t>
<t>DTLS stacks SHOULD NOT send more than 10 records in a single transm ission.</t> <t>DTLS stacks <bcp14>SHOULD NOT</bcp14> send more than 10 records in a single transmission.</t>
</section> </section>
<section anchor="state-machine-duplication" numbered="true" toc="default "> <section anchor="state-machine-duplication" numbered="true" toc="default ">
<name>State machine duplication for post-handshake messages</name> <name>State Machine Duplication for Post-Handshake Messages</name>
<t>DTLS 1.3 makes use of the following categories of post-handshake me ssages:</t> <t>DTLS 1.3 makes use of the following categories of post-handshake me ssages:</t>
<ol spacing="normal" type="1"><li>NewSessionTicket</li> <ol spacing="normal" type="1"><li>NewSessionTicket</li>
<li>KeyUpdate</li> <li>KeyUpdate</li>
<li>NewConnectionId</li> <li>NewConnectionId</li>
<li>RequestConnectionId</li> <li>RequestConnectionId</li>
<li>Post-handshake client authentication</li> <li>Post-handshake client authentication</li>
</ol> </ol>
<t>Messages of each category can be sent independently, and reliabilit y is established <t>Messages of each category can be sent independently, and reliabilit y is established
via independent state machines each of which behaves as described in <xref targe t="state-machine" format="default"/>. via independent state machines, each of which behaves as described in <xref targ et="state-machine" format="default"/>.
For example, if a server sends a NewSessionTicket and a CertificateRequest messa ge, For example, if a server sends a NewSessionTicket and a CertificateRequest messa ge,
two independent state machines will be created.</t> two independent state machines will be created.</t>
<t>As explained in the corresponding sections, sending multiple instan ces of messages of <t>Sending multiple instances of messages of
a given category without having completed earlier transmissions is allowed for s ome a given category without having completed earlier transmissions is allowed for s ome
categories, but not for others. Specifically, a server MAY send multiple NewSess categories, but not for others.
ionTicket Specifically, a server <bcp14>MAY</bcp14> send multiple NewSessionTicket
messages at once without awaiting ACKs for earlier NewSessionTicket first. Likew messages at once without awaiting ACKs for earlier NewSessionTicket messages fir
ise, a st. Likewise, a
server MAY send multiple CertificateRequest messages at once without having comp server <bcp14>MAY</bcp14> send multiple CertificateRequest messages at once with
leted out having completed
earlier client authentication requests before. In contrast, implementations MUST earlier client authentication requests before. In contrast, implementations <bcp
NOT 14>MUST NOT</bcp14>
send KeyUpdate, NewConnectionId or RequestConnectionId messages if an earlier me send KeyUpdate, NewConnectionId, or RequestConnectionId messages if an earlier m
ssage essage
of the same type has not yet been acknowledged.</t> of the same type has not yet been acknowledged.</t>
<t>Note: Except for post-handshake client authentication, which involv es handshake messages <t indent="3">Note: Except for post-handshake client authentication, w hich involves handshake messages
in both directions, post-handshake messages are single-flight, and their respect ive state in both directions, post-handshake messages are single-flight, and their respect ive state
machines on the sender side reduce to waiting for an ACK and retransmitting the original 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 t he receiver message. In particular, note that a RequestConnectionId message does not force t he receiver
to send a NewConnectionId message in reply, and both messages are therefore trea ted to send a NewConnectionId message in reply, and both messages are therefore trea ted
independently.</t> independently.</t>
<t>Creating and correctly updating multiple state machines requires fe edback from the handshake <t>Creating and correctly updating multiple state machines requires fe edback from the handshake
logic to the state machine layer, indicating which message belongs to which stat e machine. logic to the state machine layer, indicating which message belongs to which stat e machine.
For example, if a server sends multiple CertificateRequest messages and receives a Certificate For example, if a server sends multiple CertificateRequest messages and receives a Certificate
message in response, the corresponding state machine can only be determined afte r inspecting the message in response, the corresponding state machine can only be determined afte r inspecting the
certificate_request_context field. Similarly, a server sending a single Certific ateRequest certificate_request_context field. Similarly, a server sending a single Certific ateRequest
and receiving a NewConnectionId message in response can only decide that the New ConnectionId and receiving a NewConnectionId message in response can only decide that the New ConnectionId
message should be treated through an independent state machine after inspecting the handshake message should be treated through an independent state machine after inspecting the handshake
message type.</t> message type.</t>
</section> </section>
</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="TLS1
3" format="default"/>, respectively.</t>
</section>
<section anchor="cryptographic-label-prefix" numbered="true" toc="default" > <section anchor="cryptographic-label-prefix" numbered="true" toc="default" >
<name>Cryptographic Label Prefix</name> <name>Cryptographic Label Prefix</name>
<t>Section 7.1 of <xref target="TLS13" format="default"/> specifies that <t><xref target="RFC8446" sectionFormat="of" section="7.1"/> specifies t
HKDF-Expand-Label uses hat HKDF-Expand-Label uses
a label prefix of "tls13 ". For DTLS 1.3, that label SHALL be a label prefix of "tls13 ". For DTLS 1.3, that label <bcp14>SHALL</bcp14> be
"dtls13". This ensures key separation between DTLS 1.3 and "dtls13". This ensures key separation between DTLS 1.3 and
TLS 1.3. Note that there is no trailing space; this is necessary 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 in order to keep the overall label size inside of one hash
iteration because "DTLS" is one letter longer than "TLS".</t> iteration because "DTLS" is one letter longer than "TLS".</t>
</section> </section>
<section anchor="alert-messages" numbered="true" toc="default"> <section anchor="alert-messages" numbered="true" toc="default">
<name>Alert Messages</name> <name>Alert Messages</name>
<t>Note that Alert messages are not retransmitted at all, even when they <t>Note that alert messages are not retransmitted at all, even when they
occur in the context of a handshake. However, a DTLS implementation occur in the context of a handshake. However, a DTLS implementation
which would ordinarily issue an alert SHOULD generate a new alert which would ordinarily issue an alert <bcp14>SHOULD</bcp14> generate a new alert
message if the offending record is received again (e.g., as a message if the offending record is received again (e.g., as a
retransmitted handshake message). Implementations SHOULD detect when retransmitted handshake message). Implementations <bcp14>SHOULD</bcp14> detect when
a peer is persistently sending bad messages and terminate the local a peer is persistently sending bad messages and terminate the local
connection state after such misbehavior is detected. Note that alerts connection state after such misbehavior is detected. Note that alerts
are not reliably transmitted; implementation SHOULD NOT depend on are not reliably transmitted; implementations <bcp14>SHOULD NOT</bcp14> depend o n
receiving alerts in order to signal errors or connection closure.</t> 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>
<section anchor="establishing-new-associations-with-existing-parameters" n umbered="true" toc="default"> <section anchor="establishing-new-associations-with-existing-parameters" n umbered="true" toc="default">
<name>Establishing New Associations with Existing Parameters</name> <name>Establishing New Associations with Existing Parameters</name>
<t>If a DTLS client-server pair is configured in such a way that <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 repeated connections happen on the same host/port quartet, then it is
possible that a client will silently abandon one connection and then possible that a client will silently abandon one connection and then
initiate another with the same parameters (e.g., after a reboot). 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 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 cases where a server believes it has an existing association on a
given host/port quartet and it receives an epoch=0 ClientHello, it given host/port quartet and it receives an epoch=0 ClientHello, it
SHOULD proceed with a new handshake but MUST NOT destroy the existing <bcp14>SHOULD</bcp14> proceed with a new handshake but <bcp14>MUST NOT</bcp14> d estroy the existing
association until the client has demonstrated reachability either by association until the client has demonstrated reachability either by
completing a cookie exchange or by completing a complete handshake completing a cookie exchange or by completing a complete handshake
including delivering a verifiable Finished message. After a correct including delivering a verifiable Finished message. After a correct
Finished message is received, the server MUST abandon the previous Finished message is received, the server <bcp14>MUST</bcp14> abandon the previou s
association to avoid confusion between two valid associations with association to avoid confusion between two valid associations with
overlapping epochs. The reachability requirement prevents overlapping epochs. The reachability requirement prevents
off-path/blind attackers from destroying associations merely by off-path/blind attackers from destroying associations merely by
sending forged ClientHellos.</t> sending forged ClientHellos.</t>
<t>Note: it is not always possible to distinguish which association <t indent="3">Note: It is not always possible to distinguish which assoc iation
a given record is from. For instance, if the client performs a given record is from. For instance, if the client performs
a handshake, abandons the connection, and then immediately starts a handshake, abandons the connection, and then immediately starts
a new handshake, it may not be possible to tell which connection a new handshake, it may not be possible to tell which connection
a given protected record is for. In these cases, trial decryption a given protected record is for. In these cases, trial decryption
may be necessary, though implementations could use CIDs to avoid may be necessary, though implementations could use CIDs to avoid
the 5-tuple-based ambiguity.</t> the 5-tuple-based ambiguity.</t>
</section> </section>
</section> </section>
<section anchor="example-of-handshake-with-timeout-and-retransmission" numbe red="true" toc="default"> <section anchor="example-of-handshake-with-timeout-and-retransmission" numbe red="true" toc="default">
<name>Example of Handshake with Timeout and Retransmission</name> <name>Example of Handshake with Timeout and Retransmission</name>
<t>The following is an example of a handshake with lost packets and <t>The following is an example of a handshake with lost packets and
retransmissions. Note that the client sends an empty ACK message retransmissions. Note that the client sends an empty ACK message
because it can only acknowledge Record 2 sent by the server once it has 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 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"/> 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. provides the necessary background details for this interaction.
Note: for simplicity we are not re-setting record numbers in this Note: For simplicity, we are not resetting record numbers in this
diagram, so "Record 1" is really "Epoch 2, Record 0, etc.".</t> diagram, so "Record 1" is really "Epoch 2, Record 0", etc.
</t>
<figure anchor="dtls-msg-loss"> <figure anchor="dtls-msg-loss">
<name>Example DTLS exchange illustrating message loss</name> <name>Example DTLS Exchange Illustrating Message Loss</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
Client Server Client Server
------ ------ ------ ------
Record 0 --------> Record 0 -------->
ClientHello ClientHello
(message_seq=0) (message_seq=0)
X<----- Record 0 X<----- Record 0
(lost) ServerHello (lost) ServerHello
(message_seq=0) (message_seq=0)
skipping to change at line 1625 skipping to change at line 1680
(message_seq=3) (message_seq=3)
<-------- Record 5 <-------- Record 5
ACK [2] ACK [2]
]]></artwork> ]]></artwork>
</figure> </figure>
<section anchor="dtls-epoch" numbered="true" toc="default"> <section anchor="dtls-epoch" numbered="true" toc="default">
<name>Epoch Values and Rekeying</name> <name>Epoch Values and Rekeying</name>
<t>A recipient of a DTLS message needs to select the correct keying mate rial <t>A recipient of a DTLS message needs to select the correct keying mate rial
in order to process an incoming message. With the possibility of message in order to process an incoming message. With the possibility of message
loss and re-ordering, an identifier is needed to determine which cipher state loss and reordering, an identifier is needed to determine which cipher state
has been used to protect the record payload. The epoch value fulfills this 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 role in DTLS. In addition to the TLS 1.3-defined key derivation steps (see
Section 7 of <xref target="TLS13" format="default"/>, a sender may want to rekey <xref target="RFC8446" sectionFormat="of" section="7"/>), a sender may want to r
at any time during ekey at any time during
the lifetime of the connection. It therefore needs to indicate that it is the lifetime of the connection. It therefore needs to indicate that it is
updating its sending cryptographic keys.</t> updating its sending cryptographic keys.</t>
<t>This version of DTLS assigns dedicated epoch values to messages in th e <t>This version of DTLS assigns dedicated epoch values to messages in th e
protocol exchange to allow identification of the correct cipher state:</t> protocol exchange to allow identification of the correct cipher state:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>epoch value (0) is used with unencrypted messages. There are <li>Epoch value (0) is used with unencrypted messages. There are
three unencrypted messages in DTLS, namely ClientHello, ServerHello, three unencrypted messages in DTLS, namely ClientHello, ServerHello,
and HelloRetryRequest.</li> and HelloRetryRequest.</li>
<li>epoch value (1) is used for messages protected using keys derived <li>Epoch value (1) is used for messages protected using keys derived
from client_early_traffic_secret. Note this epoch is skipped if from client_early_traffic_secret. Note that this epoch is skipped if
the client does not offer early data.</li> the client does not offer early data.</li>
<li>epoch value (2) is used for messages protected using keys derived <li>Epoch value (2) is used for messages protected using keys derived
from [sender]_handshake_traffic_secret. Messages transmitted during from [sender]_handshake_traffic_secret. Messages transmitted during
the initial handshake, such as EncryptedExtensions, the initial handshake, such as EncryptedExtensions,
CertificateRequest, Certificate, CertificateVerify, and Finished CertificateRequest, Certificate, CertificateVerify, and Finished,
belong to this category. Note, however, post-handshake are 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> protected under the appropriate application traffic key and are not included in this category.</li>
<li>epoch value (3) is used for payloads protected using keys derived <li>Epoch value (3) is used for payloads protected using keys derived
from the initial [sender]_application_traffic_secret_0. This may include from the initial [sender]_application_traffic_secret_0. This may include
handshake messages, such as post-handshake messages (e.g., a handshake messages, such as post-handshake messages (e.g., a
NewSessionTicket message).</li> NewSessionTicket message).</li>
<li>epoch value (4 to 2^16-1) is used for payloads protected using key s from <li>Epoch values (4 to 2^64-1) are used for payloads protected using k eys from
the [sender]_application_traffic_secret_N (N&gt;0).</li> the [sender]_application_traffic_secret_N (N&gt;0).</li>
</ul> </ul>
<t>Using these reserved epoch values a receiver knows what cipher state <t>Using these reserved epoch values, a receiver knows what cipher state
has been used to encrypt and integrity protect a has been used to encrypt and integrity protect a
message. Implementations that receive a record with an epoch value message. Implementations that receive a record with an epoch value
for which no corresponding cipher state can be determined SHOULD for which no corresponding cipher state can be determined <bcp14>SHOULD</bcp14>
handle it as a record which fails deprotection.</t> handle it as a record which fails deprotection.</t>
<t>Note that epoch values do not wrap. If a DTLS implementation would <t>Note that epoch values do not wrap. If a DTLS implementation would
need to wrap the epoch value, it MUST terminate the connection.</t> need to wrap the epoch value, it <bcp14>MUST</bcp14> terminate the connection.</
<t>The traffic key calculation is described in Section 7.3 of <xref targ t>
et="TLS13" format="default"/>.</t> <t>The traffic key calculation is described in <xref target="RFC8446" se
ctionFormat="of" section="7.3"/>.</t>
<t><xref target="dtls-msg-epoch" format="default"/> illustrates the epoc h values in an example DTLS handshake.</t> <t><xref target="dtls-msg-epoch" format="default"/> illustrates the epoc h values in an example DTLS handshake.</t>
<figure anchor="dtls-msg-epoch"> <figure anchor="dtls-msg-epoch">
<name>Example DTLS exchange with epoch information</name> <name>Example DTLS Exchange with Epoch Information</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
Client Server Client Server
------ ------ ------ ------
Record 0 Record 0
ClientHello ClientHello
(epoch=0) (epoch=0)
--------> -------->
Record 0 Record 0
<-------- HelloRetryRequest <-------- HelloRetryRequest
(epoch=0) (epoch=0)
skipping to change at line 1732 skipping to change at line 1787
(epoch=4) (epoch=4)
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="ack-msg" numbered="true" toc="default"> <section anchor="ack-msg" numbered="true" toc="default">
<name>ACK Message</name> <name>ACK Message</name>
<t>The ACK message is used by an endpoint to indicate which handshake reco rds <t>The ACK message is used by an endpoint to indicate which handshake reco rds
it has received and processed from the other side. ACK is not it has received and processed from the other side. ACK is not
a handshake message but is rather a separate content type, a handshake message but is rather a separate content type,
with code point TBD (proposed, 25). This avoids having ACK being added with code point 26. This avoids having ACK being added
to the handshake transcript. Note that ACKs can still be to the handshake transcript. Note that ACKs can still be
sent in the same UDP datagram as handshake records.</t> sent in the same UDP datagram as handshake records.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="tls-presentation"><![CDATA[
struct { struct {
RecordNumber record_numbers<0..2^16-1>; RecordNumber record_numbers<0..2^16-1>;
} ACK; } ACK;
]]></artwork> ]]></sourcecode>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>record_numbers:</dt> <dt>record_numbers:</dt>
<dd> <dd>
a list of the records containing handshake messages in the current A list of the records containing handshake messages in the current
flight which the endpoint has received and either processed or buffered, flight which the endpoint has received and either processed or buffered,
in numerically increasing in numerically increasing
order.</dd> order.</dd>
</dl> </dl>
<t>Implementations MUST NOT acknowledge records containing <t>Implementations <bcp14>MUST NOT</bcp14> acknowledge records containing
handshake messages or fragments which have not been handshake messages or fragments which have not been
processed or buffered. Otherwise, deadlock can ensue. processed or buffered. Otherwise, deadlock can ensue.
As an example, implementations MUST NOT send ACKs for As an example, implementations <bcp14>MUST NOT</bcp14> send ACKs for
handshake messages which they discard because they are handshake messages which they discard because they are
not the next expected message.</t> not the next expected message.</t>
<t>During the handshake, ACKs only cover the current outstanding flight (t his is <t>During the handshake, ACKs only cover the current outstanding flight (t his is
possible because DTLS is generally a lockstep protocol). In particular, possible because DTLS is generally a lock-step protocol). In particular,
receiving a message from a handshake flight implicitly acknowledges all receiving a message from a handshake flight implicitly acknowledges all
messages from the previous flight(s). Accordingly, an ACK messages from the previous flight(s). Accordingly, an ACK
from the server would not cover both the ClientHello and the client's from the server would not cover both the ClientHello and the client's Certificat
Certificate, because the ClientHello and client Certificate are in different e message, because the ClientHello and client Certificate are in different
flights. Implementations can accomplish this by clearing their ACK flights. Implementations can accomplish this by clearing their ACK
list upon receiving the start of the next flight.</t> list upon receiving the start of the next flight.</t>
<t>After the handshake, ACKs SHOULD be sent once for each received <t>For post-handshake messages, ACKs <bcp14>SHOULD</bcp14> be sent once fo
and processed handshake record (potentially subject to some delay) and MAY r each received
and processed handshake record (potentially subject to some delay) and <bcp14>MA
Y</bcp14>
cover more than one flight. This includes records containing messages which are cover more than one flight. This includes records containing messages which are
discarded because a previous copy has been received.</t> discarded because a previous copy has been received.</t>
<t>During the handshake, ACK records MUST be sent with an epoch that is <t>During the handshake, ACK records <bcp14>MUST</bcp14> be sent with an e poch which is
equal to or higher than the record which is being acknowledged. equal to or higher than the record which is being acknowledged.
Note that some care is required when processing flights spanning Note that some care is required when processing flights spanning
multiple epochs. For instance, if the client receives only the Server Hello multiple epochs. For instance, if the client receives only the ServerHello
and Certificate and wishes to ACK them in a single record, 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 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 greater than or equal to 2 and cannot yet send with any greater
epoch. Implementations SHOULD simply use the highest epoch. Implementations <bcp14>SHOULD</bcp14> simply use the highest
current sending epoch, which will generally be the highest available. current sending epoch, which will generally be the highest available.
After the handshake, implementations MUST use the highest available After the handshake, implementations <bcp14>MUST</bcp14> use the highest availab le
sending epoch.</t> sending epoch.</t>
<section anchor="sending-acks" numbered="true" toc="default"> <section anchor="sending-acks" numbered="true" toc="default">
<name>Sending ACKs</name> <name>Sending ACKs</name>
<t>When an implementation detects a disruption in the receipt of the <t>When an implementation detects a disruption in the receipt of the
current incoming flight, it SHOULD generate an ACK that covers the current incoming flight, it <bcp14>SHOULD</bcp14> generate an ACK that covers th e
messages from that flight which it has received and processed so far. messages from that flight which it has received and processed so far.
Implementations have some discretion about which events to treat Implementations have some discretion about which events to treat
as signs of disruption, but it is RECOMMENDED that they generate as signs of disruption, but it is <bcp14>RECOMMENDED</bcp14> that they generate
ACKs under two circumstances:</t> ACKs under two circumstances:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>When they receive a message or fragment which is out of order, <li>When they receive a message or fragment which is out of order,
either because it is not the next expected message or because either because it is not the next expected message or because
it is not the next piece of the current message.</li> it is not the next piece of the current message.</li>
<li>When they have received part of a flight and do not immediately <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 receive the rest of the flight (which may be in the same UDP
datagram). "Immediately" is hard to define. One approach is to datagram). "Immediately" is hard to define. One approach is to
set a timer for 1/4 the current retransmit timer value when set a timer for 1/4 the current retransmit timer value when
the first record in the flight is received and then send an the first record in the flight is received and then send an
ACK when that timer expires. Note: the 1/4 value here is somewhat ACK when that timer expires. Note: The 1/4 value here is somewhat
arbitrary. Given that the round trip estimates in the DTLS arbitrary. Given that the round trip estimates in the DTLS
handshake are generally very rough (or the default), any handshake are generally very rough (or the default), any
value will be an approximation, and there is an inherent value will be an approximation, and there is an inherent
compromise due to competition between retransmision due to over-agressive ACKing compromise due to competition between retransmission due to over-aggressive ACKi ng
and over-aggressive timeout-based retransmission. and over-aggressive timeout-based retransmission.
As a comparison point, As a comparison point,
QUIC's loss-based recovery algorithms QUIC's loss-based recovery algorithms
(<xref target="I-D.ietf-quic-recovery" format="default"/>; Section 6.1.2) (<xref target="RFC9002" sectionFormat="comma" section="6.1.2"/>)
work out to a delay of about 1/3 of the retransmit timer.</li> work out to a delay of about 1/3 of the retransmit timer.</li>
</ul> </ul>
<t>In general, flights MUST be ACKed unless they are implicitly <t>In general, flights <bcp14>MUST</bcp14> be ACKed unless they are impl
acknowledged. In the present specification the following flights are implicitly icitly
acknowledged acknowledged. In the present specification, the following flights are implicitly
by the receipt of the next flight, which generally immediately follows the fligh acknowledged
t,</t> by the receipt of the next flight, which generally immediately follows the fligh
t:</t>
<ol spacing="normal" type="1"><li>Handshake flights other than the clien t's final flight of the <ol spacing="normal" type="1"><li>Handshake flights other than the clien t's final flight of the
main handshake.</li> main handshake.</li>
<li>The server's post-handshake CertificateRequest.</li> <li>The server's post-handshake CertificateRequest.</li>
</ol> </ol>
<t>ACKs SHOULD NOT be sent for these flights unless <t>ACKs <bcp14>SHOULD NOT</bcp14> be sent for these flights unless
the responding flight cannot be generated immediately. the responding flight cannot be generated immediately.
All other flights <bcp14>MUST</bcp14> be ACKed.
In this case, In this case,
implementations MAY send explicit ACKs for the complete received implementations <bcp14>MAY</bcp14> send explicit ACKs for the complete received
flight even though it will eventually also be implicitly acknowledged flight even though it will eventually also be implicitly acknowledged
through the responding flight. A notable example for this is through the responding flight. A notable example for this is
the case of client authentication in constrained the case of client authentication in constrained
environments, where generating the CertificateVerify message can environments, where generating the CertificateVerify message can
take considerable time on the client. All other flights MUST be ACKed. take considerable time on the client.
Implementations MAY acknowledge the records corresponding to each transmission o Implementations <bcp14>MAY</bcp14> acknowledge the records corresponding to each
f transmission of
each flight or simply acknowledge the most recent one. In general, each flight or simply acknowledge the most recent one. In general,
implementations SHOULD ACK as many received packets as can fit implementations <bcp14>SHOULD</bcp14> ACK as many received packets as can fit
into the ACK record, as this provides the most complete information into the ACK record, as this provides the most complete information
and thus reduces the chance of spurious retransmission; if space and thus reduces the chance of spurious retransmission; if space
is limited, implementations SHOULD favor including records which is limited, implementations <bcp14>SHOULD</bcp14> favor including records which
have not yet been acknowledged.</t> have not yet been acknowledged.</t>
<t>Note: While some post-handshake messages follow a request/response <t indent="3">Note: While some post-handshake messages follow a request/ response
pattern, this does not necessarily imply receipt. pattern, this does not necessarily imply receipt.
For example, a KeyUpdate sent in response to a KeyUpdate with For example, a KeyUpdate sent in response to a KeyUpdate with
request_update set to 'update_requested' does not implicitly request_update set to "update_requested" does not implicitly
acknowledge the earlier KeyUpdate message because the two KeyUpdate acknowledge the earlier KeyUpdate message because the two KeyUpdate
messages might have crossed in flight.</t> messages might have crossed in flight.</t>
<t>ACKs MUST NOT be sent for other records of any content type <t>ACKs <bcp14>MUST NOT</bcp14> be sent for records of any content type
other than handshake or for records which cannot be unprotected.</t> other than handshake or for records which cannot be deprotected.
</t>
<t>Note that in some cases it may be necessary to send an ACK which <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 does not contain any record numbers. For instance, a client
might receive an EncryptedExtensions message prior to receiving might receive an EncryptedExtensions message prior to receiving
a ServerHello. Because it cannot decrypt the EncryptedExtensions, a ServerHello. Because it cannot decrypt the EncryptedExtensions,
it cannot safely acknowledge it (as it might be damaged). If the client it cannot safely acknowledge it (as it might be damaged). If the client
does not send an ACK, the server will eventually retransmit does not send an ACK, the server will eventually retransmit
its first flight, but this might take far longer than the its first flight, but this might take far longer than the
actual round trip time between client and server. Having actual round trip time between client and server. Having
the client send an empty ACK shortcuts this process.</t> the client send an empty ACK shortcuts this process.</t>
</section> </section>
<section anchor="receiving-acks" numbered="true" toc="default"> <section anchor="receiving-acks" numbered="true" toc="default">
<name>Receiving ACKs</name> <name>Receiving ACKs</name>
<t>When an implementation receives an ACK, it SHOULD record that the <t>When an implementation receives an ACK, it <bcp14>SHOULD</bcp14> reco rd that the
messages or message fragments sent in the records being messages or message fragments sent in the records being
ACKed were received and omit them from any future ACKed were received and omit them from any future
retransmissions. Upon receipt of an ACK that leaves it with retransmissions. Upon receipt of an ACK that leaves it with
only some messages from a flight having been acknowledged only some messages from a flight having been acknowledged,
an implementation SHOULD retransmit the unacknowledged an implementation <bcp14>SHOULD</bcp14> retransmit the unacknowledged
messages or fragments. Note that this requires implementations to 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 track which messages appear in which records. Once all the messages in a flight have been
acknowledged, the implementation MUST cancel all retransmissions acknowledged, the implementation <bcp14>MUST</bcp14> cancel all retransmissions
of that flight. of that flight.
Implementations MUST treat a record Implementations <bcp14>MUST</bcp14> treat a record
as having been acknowledged if it appears in any ACK; this as having been acknowledged if it appears in any ACK; this
prevents spurious retransmission in cases where a flight is prevents spurious retransmission in cases where a flight is
very large and the receiver is forced to elide acknowledgements very large and the receiver is forced to elide acknowledgements
for records which have already been ACKed. for records which have already been ACKed.
As noted above, the receipt of any record responding As noted above, the receipt of any record responding
to a given flight MUST be taken as an implicit acknowledgement for the entire to a given flight <bcp14>MUST</bcp14> be taken as an implicit acknowledgement fo r the entire
flight to which it is responding.</t> flight to which it is responding.</t>
</section> </section>
<section anchor="design-rationale" numbered="true" toc="default"> <section anchor="design-rationale" numbered="true" toc="default">
<name>Design Rationale</name> <name>Design Rationale</name>
<t>ACK messages are used in two circumstances, namely :</t> <t>ACK messages are used in two circumstances, namely:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>on sign of disruption, or lack of progress, and</li> <li>On sign of disruption, or lack of progress; and</li>
<li>to indicate complete receipt of the last flight in a handshake.</l <li>To indicate complete receipt of the last flight in a handshake.</l
i> i>
</ul> </ul>
<t>In the first case the use of the ACK message is optional because <t>In the first case, the use of the ACK message is optional, because
the peer will retransmit in any case and therefore the ACK just the peer will retransmit in any case and therefore the ACK just
allows for selective or early retransmission, as opposed to the timeout-based wh allows for selective or early retransmission, as opposed to the
ole timeout-based whole flight retransmission in previous
flight retransmission in previous versions of DTLS. When DTLS 1.3 is used in dep versions of DTLS.
loyments When DTLS 1.3 is used in deployments
with lossy networks, such as low-power, long range radio networks as well as with lossy networks, such as low-power, long-range radio networks as well as
low-power mesh networks, the use of ACKs is recommended.</t> 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 fu nctioning of the <t>The use of the ACK for the second case is mandatory for the proper fu nctioning of the
protocol. For instance, the ACK message sent by the client in Figure 13, protocol. For instance, the ACK message sent by the client in <xref target="dtls
acknowledges receipt and processing of record 4 (containing the NewSessionTicket -msg-epoch"/>
message) and if it is not sent the server will continue retransmission acknowledges receipt and processing of Record 4 (containing the NewSessionTicket
message), and if it is not sent, the server will continue retransmission
of the NewSessionTicket indefinitely until its maximum retransmission count is r eached.</t> of the NewSessionTicket indefinitely until its maximum retransmission count is r eached.</t>
</section> </section>
</section> </section>
<section anchor="key-updates" numbered="true" toc="default"> <section anchor="key-updates" numbered="true" toc="default">
<name>Key Updates</name> <name>Key Updates</name>
<t>As with TLS 1.3, DTLS 1.3 implementations send a KeyUpdate message to <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 indicate that they are updating their sending keys. As with other
handshake messages with no built-in response, KeyUpdates MUST be handshake messages with no built-in response, KeyUpdates <bcp14>MUST</bcp14> be
acknowledged. In order to facilitate epoch reconstruction acknowledged. In order to facilitate epoch reconstruction
<xref target="reconstructing" format="default"/> implementations MUST NOT send r ecords with the new keys or (<xref target="reconstructing" format="default"/>), implementations <bcp14>MUST NOT</bcp14> send records with the new keys or
send a new KeyUpdate until the previous KeyUpdate has been send a new KeyUpdate until the previous KeyUpdate has been
acknowledged (this avoids having too many epochs in active use).</t> acknowledged (this avoids having too many epochs in active use).</t>
<t>Due to loss and/or re-ordering, DTLS 1.3 implementations <t>Due to loss and/or reordering, DTLS 1.3 implementations
may receive a record with an older epoch than the may receive a record with an older epoch than the
current one (the requirements above preclude receiving current one (the requirements above preclude receiving
a newer record). They SHOULD attempt to process those records a newer record). They <bcp14>SHOULD</bcp14> attempt to process those records
with that epoch (see <xref target="reconstructing" format="default"/> for inform ation with that epoch (see <xref target="reconstructing" format="default"/> for inform ation
on determining the correct epoch), but MAY opt to discard on determining the correct epoch) but <bcp14>MAY</bcp14> opt to discard
such out-of-epoch records.</t> such out-of-epoch records.</t>
<t>Due to the possibility of an ACK message for a KeyUpdate being lost and thereby <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, preventing the sender of the KeyUpdate from updating its keying material,
receivers MUST retain the pre-update keying material until receipt and successfu l receivers <bcp14>MUST</bcp14> retain the pre-update keying material until receip t and successful
decryption of a message using the new keys.</t> decryption of a message using the new keys.</t>
<t><xref target="dtls-key-update" format="default"/> shows an example exch ange illustrating that a successful <t><xref target="dtls-key-update" format="default"/> shows an example exch ange illustrating that successful
ACK processing updates the keys of the KeyUpdate message sender, which is ACK processing updates the keys of the KeyUpdate message sender, which is
reflected in the change of epoch values.</t> reflected in the change of epoch values.</t>
<figure anchor="dtls-key-update"> <figure anchor="dtls-key-update">
<name>Example DTLS Key Update</name> <name>Example DTLS Key Update</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
Client Server Client Server
/-------------------------------------------\ /-------------------------------------------\
| | | |
| Initial Handshake | | Initial Handshake |
\-------------------------------------------/ \-------------------------------------------/
[Application Data] --------> [Application Data] -------->
(epoch=3) (epoch=3)
skipping to change at line 1941 skipping to change at line 2000
[Application Data] --------> [Application Data] -------->
(epoch=3) (epoch=3)
[KeyUpdate] [KeyUpdate]
(+ update_requested --------> (+ update_requested -------->
(epoch 3) (epoch 3)
<-------- [Application Data] <-------- [Application Data]
(epoch=3) (epoch=3)
[Ack] [ACK]
<-------- (epoch=3) <-------- (epoch=3)
[Application Data] [Application Data]
(epoch=4) --------> (epoch=4) -------->
<-------- [KeyUpdate] <-------- [KeyUpdate]
(epoch=3) (epoch=3)
[Ack] --------> [ACK] -------->
(epoch=4) (epoch=4)
<-------- [Application Data] <-------- [Application Data]
(epoch=4) (epoch=4)
]]></artwork> ]]></artwork>
</figure> </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</bc
p14>
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>
<section anchor="connection-id-updates" numbered="true" toc="default"> <section anchor="connection-id-updates" numbered="true" toc="default">
<name>Connection ID Updates</name> <name>Connection ID Updates</name>
<t>If the client and server have negotiated the "connection_id" <t>If the client and server have negotiated the "connection_id"
extension <xref target="I-D.ietf-tls-dtls-connection-id" format="default"/>, eit extension <xref target="RFC9146" format="default"/>, either side
her side can send a new CID that it wishes the other side to use
can send a new CID which it wishes the other side to use
in a NewConnectionId message.</t> in a NewConnectionId message.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="tls-presentation"><![CDATA[
enum { enum {
cid_immediate(0), cid_spare(1), (255) cid_immediate(0), cid_spare(1), (255)
} ConnectionIdUsage; } ConnectionIdUsage;
opaque ConnectionId<0..2^8-1>; opaque ConnectionId<0..2^8-1>;
struct { struct {
ConnectionIds cids<0..2^16-1>; ConnectionId cids<0..2^16-1>;
ConnectionIdUsage usage; ConnectionIdUsage usage;
} NewConnectionId; } NewConnectionId;
]]></artwork> ]]></sourcecode>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>cid</dt> <dt>cids:</dt>
<dd> <dd>
Indicates the set of CIDs which the sender wishes the peer to use.</dd> Indicates the set of CIDs that the sender wishes the peer to use.</dd>
<dt>usage</dt> <dt>usage:</dt>
<dd> <dd>
Indicates whether the new CIDs should be used immediately or are 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 spare. If usage is set to "cid_immediate", then one of the new CIDs
MUST be used immediately for all future records. If it is set to <bcp14>MUST</bcp14> be used immediately for all future records. If it is set to
"cid_spare", then either existing or new CID MAY be used.</dd> "cid_spare", then either an existing or new CID <bcp14>MAY</bcp14> be used.</dd>
</dl> </dl>
<t>Endpoints SHOULD use receiver-provided CIDs in the order they were prov ided. <t>Endpoints <bcp14>SHOULD</bcp14> use receiver-provided CIDs in the order they were provided.
Implementations which receive more spare CIDs than they wish to maintain Implementations which receive more spare CIDs than they wish to maintain
MAY simply discard any extra CIDs. <bcp14>MAY</bcp14> simply discard any extra CIDs.
Endpoints MUST NOT have more than one NewConnectionId message outstanding.</t> Endpoints <bcp14>MUST NOT</bcp14> have more than one NewConnectionId message out
standing.</t>
<t>Implementations which either did not negotiate the "connection_id" exte nsion <t>Implementations which either did not negotiate the "connection_id" exte nsion
or which have negotiated receiving an empty CID MUST NOT or which have negotiated receiving an empty CID <bcp14>MUST NOT</bcp14>
send NewConnectionId. Implementations MUST NOT send RequestConnectionId send NewConnectionId. Implementations <bcp14>MUST NOT</bcp14> send RequestConnec
tionId
when sending an empty Connection ID. Implementations which detect a violation when sending an empty Connection ID. Implementations which detect a violation
of these rules MUST terminate the connection with an "unexpected_message" of these rules <bcp14>MUST</bcp14> terminate the connection with an "unexpected_ message"
alert.</t> alert.</t>
<t>Implementations SHOULD use a new CID whenever sending on a new path, <t>Implementations <bcp14>SHOULD</bcp14> use a new CID whenever sending on
and SHOULD request new CIDs for this purpose if path changes are anticipated.</t a new path
> and <bcp14>SHOULD</bcp14> request new CIDs for this purpose if path changes are
<artwork name="" type="" align="left" alt=""><![CDATA[ anticipated.</t>
<sourcecode name="" type="tls-presentation"><![CDATA[
struct { struct {
uint8 num_cids; uint8 num_cids;
} RequestConnectionId; } RequestConnectionId;
]]></artwork> ]]></sourcecode>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>num_cids</dt> <dt>num_cids:</dt>
<dd> <dd>
The number of CIDs desired.</dd> The number of CIDs desired.</dd>
</dl> </dl>
<t>Endpoints SHOULD respond to RequestConnectionId by sending a <t>Endpoints <bcp14>SHOULD</bcp14> respond to RequestConnectionId by sendi
NewConnectionId with usage "cid_spare" containing num_cid CIDs soon as ng a
possible. Endpoints MUST NOT send a RequestConnectionId message NewConnectionId with usage "cid_spare" containing num_cids CIDs as soon as
possible. Endpoints <bcp14>MUST NOT</bcp14> send a RequestConnectionId message
when an existing request is still unfulfilled; this implies that when an existing request is still unfulfilled; this implies that
endpoints needs to request new CIDs well in advance. An endpoint MAY endpoints need to request new CIDs well in advance. An endpoint <bcp14>MAY</bcp
handle requests, which it considers excessive, by responding with 14>
a NewConnectionId message containing fewer than num_cid CIDs, handle requests which it considers excessive by responding with
including no CIDs at all. Endpoints MAY handle an excessive number a NewConnectionId message containing fewer than num_cids CIDs,
including no CIDs at all. Endpoints <bcp14>MAY</bcp14> handle an excessive numbe
r
of RequestConnectionId messages by terminating the connection of RequestConnectionId messages by terminating the connection
using a "too_many_cids_requested" (alert number 52) alert.</t> using a "too_many_cids_requested" (alert number 52) alert.</t>
<t>Endpoints MUST NOT send either of these messages if they did not negoti ate a <t>Endpoints <bcp14>MUST NOT</bcp14> send either of these messages if they did not negotiate a
CID. If an implementation receives these messages when CIDs CID. If an implementation receives these messages when CIDs
were not negotiated, it MUST abort the connection with an unexpected_message were not negotiated, it <bcp14>MUST</bcp14> abort the connection with an "unexpe cted_message"
alert.</t> alert.</t>
<section anchor="connection-id-example" numbered="true" toc="default"> <section anchor="connection-id-example" numbered="true" toc="default">
<name>Connection ID Example</name> <name>Connection ID Example</name>
<t>Below is an example exchange for DTLS 1.3 using a single <t>Below is an example exchange for DTLS 1.3 using a single
CID in each direction.</t> CID in each direction.</t>
<t>Note: The connection_id extension is defined in <t indent="3">Note: The "connection_id" extension, which is used in Clie
<xref target="I-D.ietf-tls-dtls-connection-id" format="default"/>, which is used ntHello and ServerHello messages, is defined in
in ClientHello and ServerHello messages.</t> <xref target="RFC9146" format="default"/>.</t>
<figure anchor="dtls-example"> <figure anchor="dtls-example">
<name>Example DTLS 1.3 Exchange with CIDs</name> <name>Example DTLS 1.3 Exchange with CIDs</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
Client Server Client Server
------ ------ ------ ------
ClientHello ClientHello
(connection_id=5) (connection_id=5)
--------> -------->
<-------- HelloRetryRequest <-------- HelloRetryRequest
(cookie) (cookie)
ClientHello --------> ClientHello -------->
(connection_id=5) (connection_id=5)
+cookie + cookie
<-------- ServerHello <-------- ServerHello
(connection_id=100) (connection_id=100)
EncryptedExtensions EncryptedExtensions
(cid=5) (cid=5)
Certificate Certificate
(cid=5) (cid=5)
CertificateVerify CertificateVerify
(cid=5) (cid=5)
Finished Finished
(cid=5) (cid=5)
Certificate --------> Certificate -------->
(cid=100) (cid=100)
CertificateVerify CertificateVerify
(cid=100) (cid=100)
Finished Finished
(cid=100) (cid=100)
<-------- Ack <-------- ACK
(cid=5) (cid=5)
Application Data ========> Application Data ========>
(cid=100) (cid=100)
<======== Application Data <======== Application Data
(cid=5) (cid=5)
]]></artwork> ]]></artwork>
</figure> </figure>
<t>If no CID is negotiated, then the receiver MUST reject any <t>If no CID is negotiated, then the receiver <bcp14>MUST</bcp14> reject any
records it receives that contain a CID.</t> records it receives that contain a CID.</t>
</section> </section>
</section> </section>
<section anchor="application-data-protocol" numbered="true" toc="default"> <section anchor="application-data-protocol" numbered="true" toc="default">
<name>Application Data Protocol</name> <name>Application Data Protocol</name>
<t>Application data messages are carried by the record layer and are split <t>Application data messages are carried by the record layer and are split
into records into records
and encrypted based on the current connection state. The messages and encrypted based on the current connection state. The messages
are treated as transparent data to the record layer.</t> are treated as transparent data to the record layer.</t>
</section> </section>
<section anchor="security-considerations" numbered="true" toc="default"> <section anchor="security-considerations" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>Security issues are discussed primarily in <xref target="TLS13" format= "default"/>.</t> <t>Security issues are discussed primarily in <xref target="RFC8446" forma t="default"/>.</t>
<t>The primary additional security consideration raised by DTLS is that <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 of denial of service by excessive resource consumption. DTLS includes a cookie exchange designed to
protect against denial of service. However, implementations that do protect against denial of service. However, implementations that do
not use this cookie exchange are still vulnerable to DoS. In not use this cookie exchange are still vulnerable to DoS. In
particular, DTLS servers that do not use the cookie exchange may be particular, DTLS servers that do not use the cookie exchange may be
used as attack amplifiers even if they themselves are not used as attack amplifiers even if they themselves are not
experiencing DoS. Therefore, DTLS servers SHOULD use the cookie experiencing DoS. Therefore, DTLS servers <bcp14>SHOULD</bcp14> use the cookie
exchange unless there is good reason to believe that amplification is exchange unless there is good reason to believe that amplification is
not a threat in their environment. Clients MUST be prepared to do a not a threat in their environment. Clients <bcp14>MUST</bcp14> be prepared to d o a
cookie exchange with every handshake.</t> cookie exchange with every handshake.</t>
<t>Some key properties required of the cookie for the cookie-exchange mech anism <t>Some key properties required of the cookie for the cookie-exchange mech anism
to be functional are described in Section 3.3 of <xref target="RFC2522" format=" default"/>:</t> to be functional are described in <xref target="RFC2522" sectionFormat="of" sect ion="3.3"/>:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the cookie MUST depend on the client's address.</li> <li>The cookie <bcp14>MUST</bcp14> depend on the client's address.</li>
<li>it MUST NOT be possible for anyone other than the issuing entity to <li>It <bcp14>MUST NOT</bcp14> be possible for anyone other than the iss
generate uing entity to generate
cookies that are accepted as valid by that entity. This typically entails cookies that are accepted as valid by that entity. This typically entails
an integrity check based on a secret key.</li> an integrity check based on a secret key.</li>
<li>cookie generation and verification are triggered by unauthenticated parties, <li>Cookie generation and verification are triggered by unauthenticated parties,
and as such their resource consumption needs to be restrained in order to 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> avoid having the cookie-exchange mechanism itself serve as a DoS vector.</li>
</ul> </ul>
<t>Although the cookie must allow the server to produce the right handshak e <t>Although the cookie must allow the server to produce the right handshak e
transcript, it SHOULD be constructed so that knowledge of the cookie transcript, it <bcp14>SHOULD</bcp14> be constructed so that knowledge of the coo kie
is insufficient to reproduce the ClientHello contents. Otherwise, is insufficient to reproduce the ClientHello contents. Otherwise,
this may create problems with future extensions such as <xref target="I-D.ietf-t this may create problems with future extensions such as Encrypted Client Hello <
ls-esni" format="default"/>.</t> xref target="TLS-ECH" format="default"/>.</t>
<t>When cookies are generated using a keyed authentication mechanism <t>When cookies are generated using a keyed authentication mechanism,
it should be possible to rotate the associated it should be possible to rotate the associated
secret key, so that temporary compromise of the key does not permanently secret key, so that temporary compromise of the key does not permanently
compromise the integrity of the cookie-exchange mechanism. Though this secret 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 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 cookie-generation key on a similar timescale would ensure that the
key-rotation functionality is exercised regularly and thus in working order.</t> key rotation functionality is exercised regularly and thus in working order.</t>
<t>The cookie exchange provides address validation during the initial hand shake. <t>The cookie exchange provides address validation during the initial hand shake.
DTLS with Connection IDs allows for endpoint addresses to change during the DTLS with Connection IDs allows for endpoint addresses to change during the
association; any such updated addresses are not covered by the cookie exchange association; any such updated addresses are not covered by the cookie exchange
during the handshake. during the handshake.
DTLS implementations MUST NOT update the address they send to in response DTLS implementations <bcp14>MUST NOT</bcp14> update the address they send to in response
to packets from a different address unless they first perform some to packets from a different address unless they first perform some
reachability test; no such test is defined in this specification. Even reachability test; no such test is defined in this 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 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 create a reflection attack against third parties because a DTLS peer
has no means to distinguish a genuine address update event (for has no means to distinguish a genuine address update event (for
example, due to a NAT rebinding) from one that is malicious. This example, due to a NAT rebinding) from one that is malicious. This
attack is of concern when there is a large asymmetry of attack is of concern when there is a large asymmetry of
request/response message sizes.</t> request/response message sizes.</t>
<t>With the exception of order protection and non-replayability, the secur ity <t>With the exception of order protection and non-replayability, the secur ity
guarantees for DTLS 1.3 are the same as TLS 1.3. While TLS always provides 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 order protection and non-replayability, DTLS does not provide order protection
and may not provide replay protection.</t> and may not provide replay protection.</t>
<t>Unlike TLS implementations, DTLS implementations SHOULD NOT respond <t>Unlike TLS implementations, DTLS implementations <bcp14>SHOULD NOT</bcp 14> respond
to invalid records by terminating the connection.</t> to invalid records by terminating the connection.</t>
<t>TLS 1.3 requires replay protection for 0-RTT data (or rather, for conne ctions <t>TLS 1.3 requires replay protection for 0-RTT data (or rather, for conne ctions
that use 0-RTT data; see Section 8 of <xref target="TLS13" format="default"/>). DTLS provides an optional that use 0-RTT data; see <xref target="RFC8446" sectionFormat="of" section="8"/> ). DTLS provides an optional
per-record replay-protection mechanism, since datagram protocols are per-record replay-protection mechanism, since datagram protocols are
inherently subject to message reordering and replay. These two inherently subject to message reordering and replay. These two
replay-protection mechanisms are orthogonal, and neither mechanism meets the replay-protection mechanisms are orthogonal, and neither mechanism meets the
requirements for the other.</t> requirements for the other.</t>
<t>The security and privacy properties of the CID for DTLS 1.3 builds <t>
on top of what is described for DTLS 1.2 in <xref target="I-D.ietf-tls-dtls-conn DTLS 1.3's handshake transcript does not include the new DTLS fields,
ection-id" format="default"/>. There are, 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 build
on top of what is described for DTLS 1.2 in <xref target="RFC9146" format="defau
lt"/>. There are,
however, several differences:</t> however, several differences:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>In both versions of DTLS extension negotiation is used to agree on t <li>In both versions of DTLS, extension negotiation is used to agree on
he use of the CID the use of the CID
feature and the CID values. In both versions the CID is carried in the DTLS reco feature and the CID values. In both versions, the CID is carried in the DTLS rec
rd header (if negotiated). ord header (if negotiated).
However, the way the CID is included in the record header differs between the tw o versions.</li> However, the way the CID is included in the record header differs between the tw o versions.</li>
<li>The use of the Post-Handshake message allows the client and the serv <li>The use of the post-handshake message allows the client and the serv
er er
to update their CIDs and those values are exchanged with confidentiality to update their CIDs, and those values are exchanged with confidentiality
protection.</li> protection.</li>
<li>The ability to use multiple CIDs allows for improved privacy propert ies <li>The ability to use multiple CIDs allows for improved privacy propert ies
in multi-homed scenarios. When only a single CID is in use on multiple in multihomed scenarios. When only a single CID is in use on multiple
paths from such a host, an adversary can correlate the communication paths from such a host, an adversary can correlate the communication
interaction across paths, which adds further privacy concerns. In order interaction across paths, which adds further privacy concerns. In order
to prevent this, implementations SHOULD attempt to use fresh CIDs to prevent this, implementations <bcp14>SHOULD</bcp14> attempt to use fresh CIDs
whenever they change local addresses or ports (though this is not always whenever they change local addresses or ports (though this is not always
possible to detect). The RequestConnectionId message can be used by a peer 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> 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" fo rmat="default"/>) prevents <li>The mechanism for encrypting sequence numbers (<xref target="rne" fo rmat="default"/>) prevents
trivial tracking by on-path adversaries that attempt to correlate the trivial tracking by on-path adversaries that attempt to correlate the
pattern of sequence numbers received on different paths; such tracking pattern of sequence numbers received on different paths; such tracking
could occur even when different CIDs are used on each path, in the could occur even when different CIDs are used on each path, in the
absence of sequence number encryption. Switching CIDs based on certain absence of sequence number encryption. Switching CIDs based on certain
events, or even regularly, helps against tracking by on-path events, or even regularly, helps against tracking by on-path
adversaries. Note that sequence number encryption is used for all adversaries. Note that sequence number encryption is used for all
skipping to change at line 2181 skipping to change at line 2262
may improve correlation of packets from a single connection across may improve correlation of packets from a single connection across
different network paths.</li> different network paths.</li>
<li>DTLS 1.3 encrypts handshake messages much earlier than in previous <li>DTLS 1.3 encrypts handshake messages much earlier than in previous
DTLS versions. Therefore, less information identifying the DTLS client, such as DTLS versions. Therefore, less information identifying the DTLS client, such as
the client certificate, is available to an on-path adversary.</li> the client certificate, is available to an on-path adversary.</li>
</ul> </ul>
</section> </section>
<section anchor="changes-since-dtls-12" numbered="true" toc="default"> <section anchor="changes-since-dtls-12" numbered="true" toc="default">
<name>Changes since DTLS 1.2</name> <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 <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 of changes from DTLS 1.2 to DTLS 1.3 is equally large. For this reason,
this section focuses on the most important changes only.</t> this section focuses on the most important changes only.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>New handshake pattern, which leads to a shorter message exchange</li > <li>New handshake pattern, which leads to a shorter message exchange.</l i>
<li>Only AEAD ciphers are supported. Additional data calculation has bee n simplified.</li> <li>Only AEAD ciphers are supported. Additional data calculation has bee n simplified.</li>
<li>Removed support for weaker and older cryptographic algorithms</li> <li>Removed support for weaker and older cryptographic algorithms.</li>
<li>HelloRetryRequest of TLS 1.3 used instead of HelloVerifyRequest</li> <li>HelloRetryRequest of TLS 1.3 used instead of HelloVerifyRequest.</li
<li>More flexible ciphersuite negotiation</li> >
<li>New session resumption mechanism</li> <li>More flexible cipher suite negotiation.</li>
<li>PSK authentication redefined</li> <li>New session resumption mechanism.</li>
<li>New key derivation hierarchy utilizing a new key derivation construc <li>PSK authentication redefined.</li>
t</li> <li>New key derivation hierarchy utilizing a new key derivation construc
<li>Improved version negotiation</li> t.</li>
<li>Optimized record layer encoding and thereby its size</li> <li>Improved version negotiation.</li>
<li>Added CID functionality</li> <li>Optimized record layer encoding and thereby its size.</li>
<li>Added CID functionality.</li>
<li>Sequence numbers are encrypted.</li> <li>Sequence numbers are encrypted.</li>
</ul> </ul>
</section> </section>
<section anchor="updates-affecting-dtls-12" numbered="true" toc="default"> <section anchor="updates-affecting-dtls-12" numbered="true" toc="default">
<name>Updates affecting DTLS 1.2</name> <name>Updates Affecting DTLS 1.2</name>
<t>This document defines several changes that optionally affect <t>This document defines several changes that optionally affect
implementations of DTLS 1.2, including those which do not also support implementations of DTLS 1.2, including those which do not also support
DTLS 1.3.</t> DTLS 1.3.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>A version downgrade protection mechanism as described <li>A version downgrade protection mechanism as described
in <xref target="TLS13" format="default"/>; Section 4.1.3 and applying to DTLS a s in <xref target="RFC8446" sectionFormat="comma" section="4.1.3"/> and applying t o DTLS as
described in <xref target="clienthello-message" format="default"/>.</li> described in <xref target="clienthello-message" format="default"/>.</li>
<li>The updates described in <xref target="TLS13" format="default"/>; Se <li>The updates described in <xref target="RFC8446" sectionFormat="comma
ction 3.</li> " section="1.3"/>.</li>
<li>The new compliance requirements described in <xref target="TLS13" fo <li>The new compliance requirements described in <xref target="RFC8446"
rmat="default"/>; Section 9.3.</li> sectionFormat="comma" section="9.3"/>.</li>
</ul> </ul>
</section> </section>
<section anchor="iana-considerations" numbered="true" toc="default"> <section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA is requested to allocate a new value in the "TLS ContentType" <t>IANA has allocated the content type value 26 in the "TLS ContentType"
registry for the ACK message, defined in <xref target="ack-msg" format="default" registry for the ACK message, defined in <xref target="ack-msg" format="default"
/>, with content type 26. />.
The value for the "DTLS-OK" column is "Y". IANA is requested to reserve The value for the "DTLS-OK" column is "Y". IANA has reserved
the content type range 32-63 so that content types in this range are not the content type range 32-63 so that content types in this range are not
allocated.</t> allocated.</t>
<t>IANA is requested to allocate "the too_many_cids_requested" alert in <t>IANA has allocated value 52 for the "too_many_cids_requested" alert in
the "TLS Alerts" registry with value 52.</t> the "TLS Alerts" registry. The value for the "DTLS-OK" column is "Y".
<t>IANA is requested to allocate two values in the "TLS Handshake Type"
registry, defined in <xref target="TLS13" format="default"/>, for RequestConnect <!-- 9/1/2021 Lynne to ask IANA to change "the too_many_cids_requested" to
ionId (TBD), and "too_many_cids_requested" on <https://www.iana.org/assignments/tls-parameters/>
NewConnectionId (TBD), as defined in this document. The value for the just prior to publication. -->
"DTLS-OK" columns are "Y".</t> </t>
<t>IANA is requested to add this RFC as a reference to the TLS Cipher Suit <t>IANA has allocated two values in the "TLS HandshakeType"
e Registry registry, defined in <xref target="RFC8446" format="default"/>, for request_conn
ection_id (9) and
new_connection_id (10), as defined in this document. The value for the
"DTLS-OK" column is "Y".</t>
<t>IANA has added this RFC as a reference to the "TLS Cipher Suites" regis
try
along with the following Note:</t> 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 Any TLS cipher suite that is specified for use with DTLS <bcp14>MUST</bcp14>
define limits on the use of the associated AEAD function that define limits on the use of the associated AEAD function that
preserves margins for both confidentiality and integrity, preserves margins for both confidentiality and integrity,
as specified in [THIS RFC; Section TODO] as specified in <xref target="aead-limits"/> of RFC 9147.
]]></artwork> </blockquote>
</section> </section>
</middle> </middle>
<back> <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> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC0768" target="https://www.rfc-editor.org/info/rfc7
68"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0768.
<front> xml"/>
<title>User Datagram Protocol</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
<author initials="J." surname="Postel" fullname="J. Postel"> xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1191.
</author> xml"/>
<date year="1980" month="August"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4443.
</front> xml"/>
<seriesInfo name="STD" value="6"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4821.
<seriesInfo name="RFC" value="768"/> xml"/>
<seriesInfo name="DOI" value="10.17487/RFC0768"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0793.
</reference> xml"/>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6298.
119"> xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
<title>Key words for use in RFCs to Indicate Requirement Levels</tit xml"/>
le> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.
<author initials="S." surname="Bradner" fullname="S. Bradner"> xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8439.
</author> xml"/>
<date year="1997" month="March"/>
<abstract> <!-- draft-ietf-tls-dtls-connection-id (RFC 9146) -->
<t>In many standards track documents several words are used to sig <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9146.
nify the requirements in the specification. These words are often capitalized. xml"/>
This document defines these words as they should be interpreted in IETF document
s. 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/rfc1
191">
<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 t
hat passes through a router that has not been so changed, this technique might n
ot discover the correct Path MTU, but it will always choose a Path MTU as accura
te as, and in many cases more accurate than, the Path MTU that would be chosen b
y 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/rfc4
443">
<front>
<title>Internet Control Message Protocol (ICMPv6) for the Internet P
rotocol 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="edit
or">
<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 Con
trol 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/rfc4
821">
<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 Interne
t path with progressively larger packets. This method is described as an extens
ion 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/rfc7
93">
<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/rfc6
298">
<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 r
etransmission timer. It expands on the discussion in Section 4.2.3.1 of RFC 112
2 and upgrades the requirement of supporting the algorithm from a SHOULD to a MU
ST. 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/rfc8
174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<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 protoco
l specifications. This document aims to reduce the ambiguity by clarifying tha
t 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 Tschofeni
g">
<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 t
he 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 securi
ty association. In "classical" DTLS, selecting a security association of an inc
oming DTLS record is accomplished with the help of the 5-tuple. If the source I
P address and/or source port changes during the lifetime of an ongoing DTLS sess
ion then the receiver will be unable to locate the correct security context.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-dtls-connectio
n-id-11"/>
</reference>
<reference anchor="TLS13" target="https://www.rfc-editor.org/info/rfc844
6">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<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 Secu
rity (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 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 i
mplementations.</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/rfc84
39">
<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 "com
bined 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 Cryp
to Forum Research Group (CFRG). This document merges the errata filed against R
FC 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>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC7296" target="https://www.rfc-editor.org/info/rfc7
296"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7296.
<front> xml"/>
<title>Internet Key Exchange Protocol Version 2 (IKEv2)</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2522.
<author initials="C." surname="Kaufman" fullname="C. Kaufman"> xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4303.
</author> xml"/>
<author initials="P." surname="Hoffman" fullname="P. Hoffman"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4340.
<organization/> xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4346.
<author initials="Y." surname="Nir" fullname="Y. Nir"> xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4347.
</author> xml"/>
<author initials="P." surname="Eronen" fullname="P. Eronen"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5238.
<organization/> xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.
<author initials="T." surname="Kivinen" fullname="T. Kivinen"> xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.
</author> xml"/>
<date year="2014" month="October"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7525.
<abstract> xml"/>
<t>This document describes version 2 of the Internet Key Exchange
(IKE) protocol. IKE is a component of IPsec used for performing mutual authenti <reference anchor="AEBounds" target="https://www.isg.rhul.ac.uk/~kp/TLS-AEbounds
cation and establishing and maintaining Security Associations (SAs). This docum .pdf">
ent obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv
2 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/rfc2
522">
<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 docum
ent 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/rfc4
303">
<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 par
tial sequence integrity), and limited traffic flow confidentiality. This docume
nt 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/rfc4
340">
<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-controlle
d unreliable datagrams. DCCP is suitable for applications that transfer fairly
large amounts of data and that can benefit from control over the tradeoff betwee
n 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/rfc4
346">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.1</titl
e>
<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 Secu
rity (TLS) protocol. The TLS protocol provides communications security over the
Internet. The protocol allows client/server applications to communicate in a w
ay 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/rfc4
347">
<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 L
ayer Security (DTLS) protocol. The DTLS protocol provides communications privac
y for datagram protocols. The protocol allows client/server applications to com
municate in a way that is designed to prevent eavesdropping, tampering, or messa
ge forgery. The DTLS protocol is based on the Transport Layer Security (TLS) pr
otocol and provides equivalent security guarantees. Datagram semantics of the u
nderlying 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/rfc5
238">
<front>
<title>Datagram Transport Layer Security (DTLS) over the Datagram Co
ngestion 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 Sec
urity (DTLS) over the Datagram Congestion Control Protocol (DCCP). DTLS provide
s communications privacy for applications that use datagram transport protocols
and allows client/server applications to communicate in a way that is designed t
o prevent eavesdropping and detect tampering or message forgery. DCCP is a tran
sport 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/rfc5
246">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</titl
e>
<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 Secu
rity (TLS) protocol. The TLS protocol provides communications security over the
Internet. The protocol allows client/server applications to communicate in a w
ay that is designed to prevent eavesdropping, tampering, or message forgery. [S
TANDARDS-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/rfc6
347">
<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 L
ayer Security (DTLS) protocol. The DTLS protocol provides communications privac
y for datagram protocols. The protocol allows client/server applications to com
municate in a way that is designed to prevent eavesdropping, tampering, or messa
ge forgery. The DTLS protocol is based on the Transport Layer Security (TLS) pr
otocol and provides equivalent security guarantees. Datagram semantics of the u
nderlying transport are preserved by the DTLS protocol. This document updates D
TLS 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/rfc7
525">
<front>
<title>Recommendations for Secure Use of Transport Layer Security (T
LS) 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 Sec
urity (DTLS) are widely used to protect data exchanged over application protocol
s such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, severa
l serious attacks on TLS have emerged, including attacks on its most commonly us
ed cipher suites and their modes of operation. This document provides recommend
ations for improving the security of deployed services that use TLS and DTLS. Th
e 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>
<reference anchor="AEBounds" target="http://www.isg.rhul.ac.uk/~kp/TLS-A
Ebounds.pdf">
<front> <front>
<title>Limits on Authenticated Encryption Use in TLS</title> <title>Limits on Authenticated Encryption Use in TLS</title>
<author initials="A." surname="Luykx"> <author initials="A." surname="Luykx">
<organization/> <organization/>
</author> </author>
<author initials="K." surname="Paterson"> <author initials="K." surname="Paterson">
<organization/> <organization/>
</author> </author>
<date year="2016" month="March" day="08"/> <date year="2017" month="August" day="28"/>
</front> </front>
</reference> </reference>
<reference anchor="ROBUST" target="https://eprint.iacr.org/2020/718"> <reference anchor="ROBUST" target="https://eprint.iacr.org/2020/718">
<front> <front>
<title>Robust Channels: Handling Unreliable Networks in the Record L ayers of QUIC and DTLS 1.3</title> <title>Robust Channels: Handling Unreliable Networks in the Record L ayers of QUIC and DTLS 1.3</title>
<author initials="M." surname="Fischlin"> <author initials="M." surname="Fischlin">
<organization/> <organization/>
</author> </author>
<author initials="F." surname="Günther"> <author initials="F." surname="Günther">
<organization/> <organization/>
</author> </author>
<author initials="C." surname="Janson"> <author initials="C." surname="Janson">
<organization/> <organization/>
</author> </author>
<date year="2020" month="June" day="15"/> <date/>
</front>
</reference>
<reference anchor="DEPRECATE" target="http://www.ietf.org/internet-draft
s/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 (RFC 4346). Accordingly, those d
ocuments (will be moved|have been moved) to Historic status. These versions lac
k support for current and recommended cryptographic algorithms and mechanisms, a
nd various government and industry profiles of applications using TLS now mandat
e avoiding these old TLS versions. TLSv1.2 became the recommended version for I
ETF protocols in 2008, (subsequently being obsoleted by TLSv1.3 in 2018), provid
ing sufficient time to transition away from older versions. Removing support fo
r older versions from implementations reduces the attack surface, reduces opport
unity for misconfiguration, and streamlines library and product maintenance. Th
is document also deprecates Datagram TLS (DTLS) version 1.0 (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 doc
ument also updates the best practices for TLS usage in RFC 7525 and hence is par
t of BCP 195.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-oldversions-de
precate-12"/>
</reference>
<reference anchor="RFC5763" target="https://www.rfc-editor.org/info/rfc5
763">
<front>
<title>Framework for Establishing a Secure Real-time Transport Proto
col (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)</titl
e>
<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 to use the Session Initiation Proto
col (SIP) to establish a Secure Real-time Transport Protocol (SRTP) security con
text using the Datagram Transport Layer Security (DTLS) protocol. It describes
a mechanism of transporting a fingerprint attribute in the Session Description P
rotocol (SDP) that identifies the key that will be presented during the DTLS han
dshake. The key exchange travels along the media path as opposed to the signali
ng path. The SIP Identity mechanism can be used to protect the integrity of the
fingerprint attribute from modification by intermediate proxies. [STANDARDS-TR
ACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5763"/>
<seriesInfo name="DOI" value="10.17487/RFC5763"/>
</reference>
<reference anchor="RFC7983" target="https://www.rfc-editor.org/info/rfc7
983">
<front>
<title>Multiplexing Scheme Updates for Secure Real-time Transport Pr
otocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)</title>
<author initials="M." surname="Petit-Huguenin" fullname="M. Petit-Hu
guenin">
<organization/>
</author>
<author initials="G." surname="Salgueiro" fullname="G. Salgueiro">
<organization/>
</author>
<date year="2016" month="September"/>
<abstract>
<t>This document defines how Datagram Transport Layer Security (DT
LS), Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP), Session Tr
aversal Utilities for NAT (STUN), Traversal Using Relays around NAT (TURN), and
ZRTP packets are multiplexed on a single receiving socket. It overrides the gui
dance from RFC 5764 ("SRTP Extension for DTLS"), which suffered f
rom four issues described and fixed in this document.</t>
<t>This document updates RFC 5764.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7983"/>
<seriesInfo name="DOI" value="10.17487/RFC7983"/>
</reference>
<reference anchor="RFC4960" target="https://www.rfc-editor.org/info/rfc4
960">
<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 th
e Stream Control Transmission Protocol (SCTP). SCTP is designed to transport Pu
blic 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 con
nectionless packet network such as IP. It offers the following services to its
users:</t>
<t>-- acknowledged error-free non-duplicated transfer of user dat
a,</t>
<t>-- data fragmentation to conform 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 S
CTP packet, and</t>
<t>-- network-level fault tolerance through supporting of multi-h
oming at either or both ends of an association.</t>
<t> The design of SCTP includes appropriate congestion avoidance b
ehavior and resistance 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/rfc8
201">
<front>
<title>Path MTU Discovery for IP 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="ed
itor">
<organization/>
</author>
<date year="2017" month="July"/>
<abstract>
<t>This document describes Path MTU Discovery (PMTUD) for IP versi
on 6. It is largely derived from RFC 1191, which describes Path MTU Discovery fo
r 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.i
etf.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 Tschofeni
g">
<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 regar
ds 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 htt
ps://github.com/thomas-fossati/draft-tls13-iot (https://github.com/thomas-fossat
i/draft-tls13-iot).</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-uta-tls13-iot-prof
ile-01"/>
</reference>
<reference anchor="RFC5764" target="https://www.rfc-editor.org/info/rfc5
764">
<front>
<title>Datagram Transport Layer Security (DTLS) Extension to Establi
sh 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 (DT
LS) extension to establish keys for Secure RTP (SRTP) and Secure RTP Control Pro
tocol (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/rfc8
445">
<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 Translat
or (NAT) traversal for UDP-based communication. This protocol is called Interac
tive Connectivity Establishment (ICE). ICE makes use of the Session Traversal U
tilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (T
URN).</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/rfc7
924">
<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 certifi
cation authorities (CAs). This information can be of considerable size, particu
larly 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 alrea
dy 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/rfc8
879">
<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 majorit
y of the bytes transmitted.</t>
<t>This document describes how certificate chains can be compresse
d 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/rfc6
066">
<front>
<title>Transport Layer Security (TLS) Extensions: Extension Definiti
ons</title>
<author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3
rd">
<organization/>
</author>
<date year="2011" month="January"/>
<abstract>
<t>This document provides specifications for existing TLS extensio
ns. 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_req
uest. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6066"/>
<seriesInfo name="DOI" value="10.17487/RFC6066"/>
</reference>
<reference anchor="I-D.ietf-quic-recovery" target="https://www.ietf.org/
internet-drafts/draft-ietf-quic-recovery-34.txt">
<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 m
echanisms for QUIC.</t>
<t> Note to Readers</t>
<t> Discussion of this draft takes place 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/q
uicwg; 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/inter
net-drafts/draft-ietf-tls-esni-10.txt">
<front>
<title>TLS Encrypted Client Hello</title>
<author 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" 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>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-esni-10"/> <refcontent>received 15 June 2020, last revised 22 February 2021</refcon tent>
</reference> </reference>
<!-- draft-ietf-tls-oldversions-deprecate (RFC 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-ut
a-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 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 do "long way" to accommodate "C.A. Wood".
Otherwise OK as of 8/9/2021 -->
<reference anchor='TLS-ECH'>
<front>
<title>TLS Encrypted Client Hello</title>
<author 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='2021' month='July' day='7' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-tls-esni-11'/>
</reference>
<!-- draft-irtf-cfrg-aead-limits (I-D Exists)
Had to do "long way" to accommodate Günther, C.A. Wood, version #, date -->
<reference anchor='AEAD-LIMITS'>
<front>
<title>Usage Limits on AEAD Algorithms</title>
<author 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='July' day='12' />
</front>
<seriesInfo name='Internet-Draft' value='draft-irtf-cfrg-aead-limits-03'/>
</reference>
<reference anchor="CCM-ANALYSIS"> <reference anchor="CCM-ANALYSIS">
<front> <front>
<title>On the Security of CTR + CBC-MAC</title> <title>On the Security of CTR + CBC-MAC</title>
<author initials="J." surname="Jonsson" fullname="Jakob Jonsson"> <author initials="J." surname="Jonsson" fullname="Jakob Jonsson">
<organization/> <organization/>
</author> </author>
<date year="2003"/> <date month="February" year="2003"/>
</front> </front>
<seriesInfo name="Selected Areas in Cryptography" value="pp. 76-93"/> <refcontent>Selected Areas in Cryptography pp. 76-93</refcontent>
<seriesInfo name="DOI" value="10.1007/3-540-36492-7_7"/> <seriesInfo name="DOI" value="10.1007/3-540-36492-7_7"/>
</reference> </reference>
</references> </references>
</references> </references>
<section anchor="protocol-data-structures-and-constant-values" numbered="tru e" toc="default"> <section anchor="protocol-data-structures-and-constant-values" numbered="tru e" toc="default">
<name>Protocol Data Structures and Constant Values</name> <name>Protocol Data Structures and Constant Values</name>
<t>This section provides the normative protocol types and constants defini tions.</t> <t>This section provides the normative protocol types and constants defini tions.</t>
<section anchor="record-layer" numbered="true" toc="default"> <section anchor="record-layer" numbered="true" toc="default">
<name>Record Layer</name> <name>Record Layer</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
struct { struct {
ContentType type; ContentType type;
ProtocolVersion legacy_record_version; ProtocolVersion legacy_record_version;
uint16 epoch = 0 uint16 epoch = 0
uint48 sequence_number; uint48 sequence_number;
uint16 length; uint16 length;
opaque fragment[DTLSPlaintext.length]; opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext; } DTLSPlaintext;
struct { struct {
opaque content[DTLSPlaintext.length]; opaque content[DTLSPlaintext.length];
ContentType type; ContentType type;
uint8 zeros[length_of_padding]; uint8 zeros[length_of_padding];
} DTLSInnerPlaintext; } DTLSInnerPlaintext;
struct { struct {
opaque unified_hdr[variable]; opaque unified_hdr[variable];
opaque encrypted_record[length]; opaque encrypted_record[length];
} DTLSCiphertext; } DTLSCiphertext;
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0|0|1|C|S|L|E E| |0|0|1|C|S|L|E E|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Connection ID | Legend: | Connection ID | Legend:
| (if any, | | (if any, |
/ length as / C - Connection ID (CID) present / length as / C - Connection ID (CID) present
| negotiated) | S - Sequence number length | negotiated) | S - Sequence number length
+-+-+-+-+-+-+-+-+ L - Length present +-+-+-+-+-+-+-+-+ L - Length present
| 8 or 16 bit | E - Epoch | 8 or 16 bit | E - Epoch
|Sequence Number| |Sequence Number|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| 16 bit Length | | 16 bit Length |
| (if present) | | (if present) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
struct { struct {
uint16 epoch; uint64 epoch;
uint48 sequence_number; uint64 sequence_number;
} RecordNumber; } RecordNumber;
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="handshake-protocol" numbered="true" toc="default"> <section anchor="handshake-protocol" numbered="true" toc="default">
<name>Handshake Protocol</name> <name>Handshake Protocol</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="tls-presentation"><![CDATA[
enum { enum {
hello_request_RESERVED(0), hello_request_RESERVED(0),
client_hello(1), client_hello(1),
server_hello(2), server_hello(2),
hello_verify_request_RESERVED(3), hello_verify_request_RESERVED(3),
new_session_ticket(4), new_session_ticket(4),
end_of_early_data(5), end_of_early_data(5),
hello_retry_request_RESERVED(6), hello_retry_request_RESERVED(6),
encrypted_extensions(8), encrypted_extensions(8),
certificate(11), request_connection_id(9), /* New */
server_key_exchange_RESERVED(12), new_connection_id(10), /* New */
certificate_request(13), certificate(11),
server_hello_done_RESERVED(14), server_key_exchange_RESERVED(12),
certificate_verify(15), certificate_request(13),
client_key_exchange_RESERVED(16), server_hello_done_RESERVED(14),
finished(20), certificate_verify(15),
certificate_url_RESERVED(21), client_key_exchange_RESERVED(16),
certificate_status_RESERVED(22), finished(20),
supplemental_data_RESERVED(23), certificate_url_RESERVED(21),
key_update(24), certificate_status_RESERVED(22),
message_hash(254), supplemental_data_RESERVED(23),
(255) key_update(24),
} HandshakeType; message_hash(254),
(255)
} HandshakeType;
struct { struct {
HandshakeType msg_type; /* handshake type */ HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */ uint24 length; /* bytes in message */
uint16 message_seq; /* DTLS-required field */ uint16 message_seq; /* DTLS-required field */
uint24 fragment_offset; /* DTLS-required field */ uint24 fragment_offset; /* DTLS-required field */
uint24 fragment_length; /* DTLS-required field */ uint24 fragment_length; /* DTLS-required field */
select (msg_type) { select (msg_type) {
case client_hello: ClientHello; case client_hello: ClientHello;
case server_hello: ServerHello; case server_hello: ServerHello;
case end_of_early_data: EndOfEarlyData; case end_of_early_data: EndOfEarlyData;
case encrypted_extensions: EncryptedExtensions; case encrypted_extensions: EncryptedExtensions;
case certificate_request: CertificateRequest; case certificate_request: CertificateRequest;
case certificate: Certificate; case certificate: Certificate;
case certificate_verify: CertificateVerify; case certificate_verify: CertificateVerify;
case finished: Finished; case finished: Finished;
case new_session_ticket: NewSessionTicket; case new_session_ticket: NewSessionTicket;
case key_update: KeyUpdate; case key_update: KeyUpdate;
} body; case request_connection_id: RequestConnectionId;
} Handshake; case new_connection_id: NewConnectionId;
} body;
} Handshake;
uint16 ProtocolVersion; uint16 ProtocolVersion;
opaque Random[32]; opaque Random[32];
uint8 CipherSuite[2]; /* Cryptographic suite selector */ uint8 CipherSuite[2]; /* Cryptographic suite selector */
struct { struct {
ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2 ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2
Random random; Random random;
opaque legacy_session_id<0..32>; opaque legacy_session_id<0..32>;
opaque legacy_cookie<0..2^8-1>; // DTLS opaque legacy_cookie<0..2^8-1>; // DTLS
CipherSuite cipher_suites<2..2^16-2>; CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>; opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>; Extension extensions<8..2^16-1>;
} ClientHello; } ClientHello;
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="acks" numbered="true" toc="default"> <section anchor="acks" numbered="true" toc="default">
<name>ACKs</name> <name>ACKs</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="tls-presentation"><![CDATA[
struct { struct {
RecordNumber record_numbers<0..2^16-1>; RecordNumber record_numbers<0..2^16-1>;
} ACK; } ACK;
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="connection-id-management" numbered="true" toc="default"> <section anchor="connection-id-management" numbered="true" toc="default">
<name>Connection ID Management</name> <name>Connection ID Management</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="tls-presentation"><![CDATA[
enum { enum {
cid_immediate(0), cid_spare(1), (255) cid_immediate(0), cid_spare(1), (255)
} ConnectionIdUsage; } ConnectionIdUsage;
opaque ConnectionId<0..2^8-1>; opaque ConnectionId<0..2^8-1>;
struct { struct {
ConnectionIds cids<0..2^16-1>; ConnectionId cids<0..2^16-1>;
ConnectionIdUsage usage; ConnectionIdUsage usage;
} NewConnectionId; } NewConnectionId;
struct { struct {
uint8 num_cids; uint8 num_cids;
} RequestConnectionId; } RequestConnectionId;
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="ccm-bounds" numbered="true" toc="default"> <section anchor="ccm-bounds" numbered="true" toc="default">
<name>Analysis of Limits on CCM Usage</name> <name>Analysis of Limits on CCM Usage</name>
<t>TLS <xref target="TLS13" format="default"/> and <xref target="AEBounds" <t>TLS <xref target="RFC8446" format="default"/> and <xref target="AEBound
format="default"/> do not specify limits on key usage for s" 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 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 use that ensure that both confidentiality and integrity are preserved. This
section documents that analysis for AEAD_AES_128_CCM.</t> section documents that analysis for AEAD_AES_128_CCM.</t>
<t><xref target="CCM-ANALYSIS" format="default"/> is used as the basis of this <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 analysis. The results of that analysis are used to derive usage limits that are
based on those chosen in <xref target="TLS13" format="default"/>.</t> based on those chosen in <xref target="RFC8446" format="default"/>.</t>
<t>This analysis uses symbols for multiplication (*), division (/), and <t>This analysis uses symbols for multiplication (*), division (/), and
exponentiation (^), plus parentheses for establishing precedence. The following exponentiation (^), plus parentheses for establishing precedence. The following
symbols are also used:</t> symbols are also used:</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal" indent="4">
<dt>t:</dt> <dt>t:</dt>
<dd> <dd>
The size of the authentication tag in bits. For this cipher, t is 128.</dd> The size of the authentication tag in bits. For this cipher, t is 128.</dd>
<dt>n:</dt> <dt>n:</dt>
<dd> <dd>
The size of the block function in bits. For this cipher, n is 128.</dd> The size of the block function in bits. For this cipher, n is 128.</dd>
<dt>l:</dt> <dt>l:</dt>
<dd> <dd>
The number of blocks in each packet (see below).</dd> The number of blocks in each packet (see below).</dd>
<dt>q:</dt> <dt>q:</dt>
skipping to change at line 3075 skipping to change at line 2649
<dd> <dd>
The number of forged packets that endpoints will accept. This value is the 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 bound on the number of forged packets that an endpoint can reject before
updating keys.</dd> updating keys.</dd>
</dl> </dl>
<t>The analysis of AEAD_AES_128_CCM relies on a count of the number of blo ck <t>The analysis of AEAD_AES_128_CCM relies on a count of the number of blo ck
operations involved in producing each message. For simplicity, and to match the 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 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> 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 th e sum <t>For AEAD_AES_128_CCM, the total number of block cipher operations is th e sum
of: the length of the associated data in blocks, the length of the ciphertext of: the length of the associated data in blocks, the length of the ciphertext in
in blocks, and the length of the plaintext in blocks, plus 1. In this analysis, 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 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 da ta (that is, <tt>2l = 2^11</tt>). This simplification is based on the associated da ta
being limited to one block.</t> being limited to one block.</t>
<section anchor="ccm-confidentiality" numbered="true" toc="default"> <section anchor="ccm-confidentiality" numbered="true" toc="default">
<name>Confidentiality Limits</name> <name>Confidentiality Limits</name>
<t>For confidentiality, Theorem 2 in <xref target="CCM-ANALYSIS" format= "default"/> establishes that an attacker <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 gains a distinguishing advantage over an ideal pseudorandom permutation (PRP) of
no more than:</t> no more than:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
(2l * q)^2 / 2^n (2l * q)^2 / 2^n
]]></artwork> ]]></artwork>
<t>For a target advantage of 2^-60, which matches that used by <xref tar
get="TLS13" format="default"/>, this <t>For a target advantage in a single-key setting of 2^-60, which matche
results in the relation:</t> s that used by TLS 1.3, as summarized in <xref target="AEAD-LIMITS"/>, this resu
<artwork name="" type="" align="left" alt=""><![CDATA[ lts in the relation:</t>
<artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
q <= 2^23 q <= 2^23
]]></artwork> ]]></artwork>
<t>That is, endpoints cannot protect more than 2^23 packets with the sam e set of <t>That is, endpoints cannot protect more than 2^23 packets with the sam e set of
keys without causing an attacker to gain an larger advantage than the target of keys without causing an attacker to gain a larger advantage than the target of
2^-60.</t> 2^-60.</t>
</section> </section>
<section anchor="ccm-integrity" numbered="true" toc="default"> <section anchor="ccm-integrity" numbered="true" toc="default">
<name>Integrity Limits</name> <name>Integrity Limits</name>
<t>For integrity, Theorem 1 in <xref target="CCM-ANALYSIS" format="defau lt"/> establishes that an attacker <t>For integrity, Theorem 1 in <xref target="CCM-ANALYSIS" format="defau lt"/> establishes that an attacker
gains an advantage over an ideal PRP of no more than:</t> gains an advantage over an ideal PRP of no more than:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
v / 2^t + (2l * (v + q))^2 / 2^n v / 2^t + (2l * (v + q))^2 / 2^n
]]></artwork> ]]></artwork>
<t>The goal is to limit this advantage to 2^-57, to match the target in <t>The goal is to limit this advantage to 2^-57, to match the target in
<xref target="TLS13" format="default"/>. As <tt>t</tt> and <tt>n</tt> are both 1 28, the first term is negligible relative TLS 1.3, as summarized in <xref 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 to the second, so that term can be removed without a significant effect on the
result. This produces the relation:</t> result. This produces the relation:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
v + q <= 2^24.5 v + q <= 2^24.5
]]></artwork> ]]></artwork>
<t>Using the previously-established value of 2^23 for <tt>q</tt> and rou nding, this leads <t>Using the previously established value of 2^23 for <tt>q</tt> and rou nding, this leads
to an upper limit on <tt>v</tt> of 2^23.5. That is, endpoints cannot attempt to 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 authenticate more than 2^23.5 packets with the same set of keys without causing
an attacker to gain an larger advantage than the target of 2^-57.</t> an attacker to gain a larger advantage than the target of 2^-57.</t>
</section> </section>
<section anchor="ccm-short" numbered="true" toc="default"> <section anchor="ccm-short" numbered="true" toc="default">
<name>Limits for AEAD_AES_128_CCM_8</name> <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, <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> 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 thos e for <t>The confidentiality limits of AEAD_AES_128_CCM_8 are the same as thos e for
AEAD_AES_128_CCM, as this does not depend on the tag length; see AEAD_AES_128_CCM, as this does not depend on the tag length; see
<xref target="ccm-confidentiality" format="default"/>.</t> <xref target="ccm-confidentiality" format="default"/>.</t>
<t>The shorter tag length of 64 bits means that the simplification used in <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_C CM_8. If the goal is to <xref target="ccm-integrity" format="default"/> does not apply to AEAD_AES_128_C CM_8. If the goal is to
preserve the same margins as other cipher suites, then the limit on forgeries 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> is largely dictated by the first term of the advantage formula:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
v <= 2^7 v <= 2^7
]]></artwork> ]]></artwork>
<t>As this represents attempts to fail authentication, applying this lim it might <t>As this represents attempts that fail authentication, applying this l imit might
be feasible in some environments. However, applying this limit in an be feasible in some environments. However, applying this limit in an
implementation intended for general use exposes connections to an inexpensive implementation intended for general use exposes connections to an inexpensive
denial of service attack.</t> denial-of-service attack.</t>
<t>This analysis supports the view that TLS_AES_128_CCM_8_SHA256 is not suitable <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 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 additional measures to prevent forgery of records, or to mitigate the effect of
forgeries. This might require understanding the constraints that exist in a forgeries. This might require understanding the constraints that exist in a
particular deployment or application. For instance, it might be possible to set particular deployment or application. For instance, it might be possible to set
a different target for the advantage an attacker gains based on an a different target for the advantage an attacker gains based on an
understanding of the constraints imposed on a specific usage of DTLS.</t> understanding of the constraints imposed on a specific usage of DTLS.</t>
</section> </section>
</section> </section>
<section anchor="implementation-pitfalls" numbered="true" toc="default"> <section anchor="implementation-pitfalls" numbered="true" toc="default">
<name>Implementation Pitfalls</name> <name>Implementation Pitfalls</name>
<t>In addition to the aspects of TLS that have been a source of interopera bility <t>In addition to the aspects of TLS that have been a source of interopera bility
and security problems (Section C.3 of <xref target="TLS13" format="default"/>), DTLS presents a few new and security problems (<xref target="RFC8446" sectionFormat="of" section="C.3"/> ), DTLS presents a few new
potential sources of issues, noted here.</t> potential sources of issues, noted here.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Do you correctly handle messages received from multiple epochs durin g a key <li>Do you correctly handle messages received from multiple epochs durin g a key
transition? This includes locating the correct key as well as performing transition? This includes locating the correct key as well as performing
replay detection, if enabled.</li> replay detection, if enabled.</li>
<li>Do you retransmit handshake messages that are not (implicitly or exp licitly) <li>Do you retransmit handshake messages that are not (implicitly or exp licitly)
acknowledged (<xref target="timeout-retransmissions" format="default"/>)?</li> acknowledged (<xref target="timeout-retransmissions" format="default"/>)?</li>
<li>Do you correctly handle handshake message fragments received, includ ing <li>Do you correctly handle handshake message fragments received, includ ing
when they are out of order?</li> when they are out of order?</li>
<li>Do you correctly handle handshake messages received out of order? <li>Do you correctly handle handshake messages received out of order?
This may include either buffering or discarding them.</li> 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 <li>Do you limit how much data you send to a peer before its address is
validated?</li> validated?</li>
<li>Do you verify that the explicit record length is contained within th e <li>Do you verify that the explicit record length is contained within th e
datagram in which it is contained?</li> datagram in which it is contained?</li>
</ul> </ul>
</section> </section>
<section anchor="history" numbered="true" toc="default"> <section anchor="contributors" numbered="false" 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 t
he 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">http
s://www.ietf.org/mail-archive/web/tls/current/index.html</eref></t>
</section>
<section anchor="contributors" numbered="true" toc="default">
<name>Contributors</name> <name>Contributors</name>
<t>Many people have contributed to previous DTLS versions and they are ack <t>Many people have contributed to previous DTLS versions, and they are ac
nowledged knowledged
in prior versions of DTLS specifications or in the referenced specifications. Th in prior versions of DTLS specifications or in the referenced specifications.</t
e >
sequence number encryption concept is taken from the QUIC specification. We woul
d
like to thank the authors of the QUIC specification for their work. Felix
Guenther and 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 would like to thank Jonathan Hammell, Bernard Aboba and Andy Cunning
ham 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, Zaheduzzama
n Sarker, John Scudder, Eric Vyncke, Robert Wilton, Roman Danyliw, Benjamin Kadu
k, Murray Kucherawy, Martin Vigoureux, and 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
<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 QUIC <xref target="RFC9000"/>.
We would
like to thank the authors of RFC 9000 for their work. <contact fullname="Felix G
ünther"/> and <contact fullname="Martin
Thomson"/> contributed the analysis in <xref target="ccm-bounds" format="defaul
t"/>.
We would like to thank <contact fullname="Jonathan Hammell"/>, <contact fu
llname="Bernard Aboba"/>, and <contact fullname="Andy Cunningham"/> for their re
view comments.</t>
<t>Additionally, we would like to thank the IESG members for their review
comments: <contact fullname="Martin Duke"/>, <contact fullname="Erik Kline"/>, <
contact fullname="Francesca Palombini"/>, <contact fullname="Lars Eggert"/>, <co
ntact fullname="Zaheduzzaman Sarker"/>, <contact fullname="John Scudder"/>, <con
tact fullname="Éric Vyncke"/>, <contact fullname="Robert Wilton"/>, <contact ful
lname="Roman Danyliw"/>, <contact fullname="Benjamin Kaduk"/>, <contact fullname
="Murray Kucherawy"/>, <contact fullname="Martin Vigoureux"/>, and <contact full
name="Alvaro Retana"/>.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 383 change blocks. 
2685 lines changed or deleted 1188 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/