<?xmlversion='1.0' encoding='utf-8'?> <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>version="1.0" encoding="UTF-8"?> <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.4.15 --> <!DOCTYPE rfcSYSTEM "rfc2629-xhtml.ent"> <?rfc rfcedstyle="yes"?> <?rfc toc="yes"?> <?rfc tocindent="yes"?> <?rfc sortrefs="yes"?> <?rfc symrefs="yes"?> <?rfc strict="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc text-list-symbols="-o*+"?> <?rfc docmapping="yes"?>[ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="pre5378Trust200902" docName="draft-ietf-tls-dtls-connection-id-13"category="std"number="9146" updates="6347" obsoletes="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 3.8.0 --> <front> <title abbrev="DTLS 1.2 Connection ID">ConnectionIdentifiersIdentifier for DTLS 1.2</title> <seriesInfoname="Internet-Draft" value="draft-ietf-tls-dtls-connection-id-13"/>name="RFC" value="9146"/> <author initials="E." surname="Rescorla" fullname="Eric Rescorla" role="editor"><organization>RTFM, Inc.</organization><organization>Mozilla</organization> <address> <email>ekr@rtfm.com</email> </address> </author> <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig" role="editor"> <organization>Arm Limited</organization> <address> <email>hannes.tschofenig@arm.com</email> </address> </author> <author initials="T." surname="Fossati" fullname="Thomas Fossati"> <organization>Arm Limited</organization> <address> <email>thomas.fossati@arm.com</email> </address> </author> <author initials="A." surname="Kraus" fullname="Achim Kraus"> <organization>Bosch.IO GmbH</organization> <address> <email>achim.kraus@bosch.io</email> </address> </author> <dateyear="2021" month="June" day="22"/>year="2022" month="March"/> <area>Security</area> <workgroup>TLS</workgroup><keyword>Internet-Draft</keyword><keyword>NAT rebinding</keyword> <abstract> <t>This document specifies the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol version 1.2.</t> <t>A CID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association. In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple. If the source IP address and/or source port changes during the lifetime of an ongoing DTLSsessionsession, then the receiver will be unable to locate the correct security context.</t> <t>The new ciphertext record format with the CID also provides content type encryption andrecord-layerrecord layer padding.</t> <t>This document updates RFC 6347.</t> </abstract> </front> <middle> <section anchor="introduction" numbered="true" toc="default"> <name>Introduction</name> <t>The Datagram Transport Layer Security (DTLS) protocol <xref target="RFC6347" format="default"/>protocolwas designed for securingconnection-less transports, like UDP.data sent over datagram transports (e.g., UDP). DTLS, like TLS, starts with a handshake, which can be computationally demanding (particularly when public key cryptography is used). After a successful handshake, symmetric key cryptography is used to apply data origin authentication,integrityintegrity, and confidentiality protection. This two-step approach allows endpoints to amortize the cost of the initial handshake across subsequent application data protection. Ideally, the second phase where application data is protected lasts over a long period oftimetime, since the established keys will only need to be updated once the key lifetime expires.</t> <t>In DTLS as specified in RFC 6347, the IP address and port of the peer are used to identify the DTLS association. Unfortunately, in some cases, such as NAT rebinding, these values are insufficient. This is a particular issue in the Internet of Things when devices enter extended sleep periods to increase their battery lifetime. The NAT rebinding leads to connection failure, with the resulting cost of a new handshake.</t> <t>This document defines an extension to DTLS 1.2 to add a Connection ID (CID) to the DTLS record layer. The presence of the CID is negotiated via a DTLS extension.</t> <t>Adding a CID to the ciphertext record format presents an opportunity to make other changes to the record format. In keeping with the best practices established by TLS 1.3, the type of the record is encrypted, and a mechanism is provided for adding padding to obfuscate the plaintext length.</t> </section> <section anchor="conventions-and-terminology" numbered="true" toc="default"> <name>Conventions and Terminology</name> <t>The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xreftarget="RFC2119" format="default"/>target="RFC2119"/> <xreftarget="RFC8174" format="default"/>target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t> <t>This document assumes familiarity with DTLS 1.2 <xref target="RFC6347" format="default"/>. The presentation language used in this document is described inSection 3 of<xref target="RFC8446"format="default"/>.</t>sectionFormat="of" section="3"/>.</t> </section> <section anchor="the-connectionid-extension" numbered="true" toc="default"> <name>The "connection_id" Extension</name> <t>This document defines the "connection_id" extension, which is used in ClientHello and ServerHello messages.</t> <t>The extension type is specified as follows.</t><artwork<sourcecode name=""type="" align="left" alt=""><![CDATA[type="tls-presentation"><![CDATA[ enum {connection_id(TBD1),connection_id(54), (65535) } ExtensionType;]]></artwork>]]></sourcecode> <t>The extension_data field of this extension, when included in the ClientHello,MUST<bcp14>MUST</bcp14> contain the ConnectionId structure. This structure contains the CID value the client wishes the server to use when sending messages to the client. A zero-length CID value indicates that the client is prepared to send using a CID but does not wish the server to use one when sending.</t><artwork<sourcecode name=""type="" align="left" alt=""><![CDATA[type="tls-presentation"><![CDATA[ struct { opaque cid<0..2^8-1>; } ConnectionId;]]></artwork>]]></sourcecode> <t>A server willing to use CIDs will respond with a "connection_id" extension in the ServerHello, containing the CID it wishes the client to use when sending messages towards it. A zero-length value indicates that the server will send using the client's CID but does not wish the client to include a CID when sending.</t> <t>Because each party sends the value in the "connection_id" extension it wants to receive as a CID in encrypted records, it is possible for an endpoint to use a deployment-specific constant length for such connection identifiers. This can in turn ease parsing and connectionlookup,lookup -- forexampleexample, by having the length in question be a compile-time constant. Such implementationsMUST<bcp14>MUST</bcp14> still be able to send CIDs of differentlengthlengths to other parties. Since the CID length information is not included in the record itself, implementations that want to use variable-length CIDs are responsible for constructing the CID in such a way that its length can be determined on reception.</t> <t>In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS session only. There is no dedicated "CID update" message that allows new CIDs to be established mid-session, because DTLS 1.2 in general does not allow TLS 1.3-style post-handshake messages that do not themselves begin other handshakes. When a DTLS session is resumed or renegotiated, the "connection_id" extension is negotiated afresh.</t> <t>If DTLS peers have not negotiated the use of CIDs, or a zero-length CID has been advertised for a given direction, then theRFC 6347-definedrecord format and content typeMUSTdefined in RFC 6347 <bcp14>MUST</bcp14> be used to send in the indicated direction(s).</t> <t>If DTLS peers have negotiated the use of a non-zero-length CID for a given direction, then once encryption isenabledenabled, theyMUST<bcp14>MUST</bcp14> send with the record format defined in <xref target="dtls-ciphertext" format="default"/> (see <xref target="record-layer-extensions"/>) with the newMACMessage Authentication Code (MAC) computation defined in <xref target="mac" format="default"/> and the content type tls12_cid. Plaintext payloads never use the new record format or the CID content type.</t> <t>When receiving, if the tls12_cid content type is set, then the CID is used to look up the connection and the security association. If the tls12_cid content type is not set, then the connection and the security associationisare looked up by the 5-tuple and a checkMUST<bcp14>MUST</bcp14> be made to determine whether anon-zero lengthnon-zero-length CID is expected. If a non-zero-length CID is expected for the retrieved association, then the datagramMUST<bcp14>MUST</bcp14> be treated as invalid, as described inSection 4.1.2.1 of<xref target="RFC6347"format="default"/>.</t>sectionFormat="of" section="4.1.2.1"/>.</t> <t>When receiving a datagram with the tls12_cid content type, the new MAC computation defined in <xref target="mac" format="default"/>MUST<bcp14>MUST</bcp14> be used. When receiving a datagram with theRFC 6347-definedrecordformat,format defined in RFC 6347, the MAC calculation defined inSection 4.1.2 of<xref target="RFC6347"format="default"/> MUSTsectionFormat="of" section="4.1.2"/> <bcp14>MUST</bcp14> be used.</t> </section> <section anchor="record-layer-extensions" numbered="true" toc="default"> <name>Record Layer Extensions</name> <t>This specification defines theDTLS 1.2CID-enhanced record layer format for DTLS 1.2, and <xreftarget="I-D.ietf-tls-dtls13"target="RFC9147" format="default"/> specifies how to carry the CID in DTLS 1.3.</t> <t>To allow a receiver to determine whether a record has a CID or not, connectionswhichthat have negotiated this extension use a distinguished record typetls12_cid(TBD2). Usetls12_cid(25). The use of this content type has the following three implications:</t> <ul spacing="normal"> <li>The CID field is present and contains one or more bytes.</li> <li>The MAC calculation follows the process described in <xref target="mac" format="default"/>.</li> <li>The real content type is inside the encryption envelope, as described below.</li> </ul> <t>Plaintext records are not impacted by this extension. Hence, the format of the DTLSPlaintext structure is left unchanged, as shown in <xref target="dtls-plaintext" format="default"/>.</t> <figure anchor="dtls-plaintext"> <name>DTLS 1.2 Plaintext RecordPayload.</name> <artworkPayload</name> <sourcecode name=""type="" align="left" alt=""><![CDATA[type="tls-presentation"><![CDATA[ struct { ContentType type; ProtocolVersion version; uint16 epoch; uint48 sequence_number; uint16 length; opaque fragment[DTLSPlaintext.length]; } DTLSPlaintext;]]></artwork>]]></sourcecode> </figure> <t>When CIDs are being used, the content to be sent is first wrapped along with its content type and optional padding into a DTLSInnerPlaintext structure. This newly introduced structure is shown in <xref target="dtls-innerplaintext" format="default"/>.</t> <figure anchor="dtls-innerplaintext"> <name>New DTLSInnerPlaintext PayloadStructure.</name> <artworkStructure</name> <sourcecode name=""type="" align="left" alt=""><![CDATA[type="tls-presentation"><![CDATA[ struct { opaque content[length]; ContentType real_type; uint8 zeros[length_of_padding]; } DTLSInnerPlaintext;]]></artwork>]]></sourcecode> </figure> <dl> <dt>content </dt>content:</dt> <dd> <t>Corresponds to the fragment of a given length.</t> </dd> <dt>real_type </dt>real_type:</dt> <dd> <t>The content type describing the cleartext payload.</t> </dd> <dt>zeros </dt>zeros:</dt> <dd> <t>An arbitrary-length run of zero-valued bytes may appear in the cleartext after the type field. This provides an opportunity for senders to pad any DTLS record by a chosen amount as long as the total stays within record size limits. SeeSection 5.4 of<xref target="RFC8446"format="default"/>sectionFormat="of" section="5.4"/> for more details. (Note that the term TLSInnerPlaintext in RFC 8446 refers to DTLSInnerPlaintext in this specification.)</t> </dd> </dl> <t>The DTLSInnerPlaintext byte sequence is then encrypted. To create the DTLSCiphertext structure shown in <xref target="dtls-ciphertext"format="default"/>format="default"/>, the CID is added.</t> <figure anchor="dtls-ciphertext"> <name>DTLS 1.2CID-enhancedCID-Enhanced CiphertextRecord.</name> <artworkRecord</name> <sourcecode name=""type="" align="left" alt=""><![CDATA[type="tls-presentation"><![CDATA[ struct { ContentType outer_type = tls12_cid; ProtocolVersion version; uint16 epoch; uint48 sequence_number; opaque cid[cid_length]; // New field uint16 length; opaque enc_content[DTLSCiphertext.length]; } DTLSCiphertext;]]></artwork>]]></sourcecode> </figure> <dl> <dt>outer_type </dt>outer_type:</dt> <dd> <t>The outer content type of a DTLSCiphertext record carrying a CID is always set totls12_cid(TBD2).tls12_cid(25). The real content type of the record is found in DTLSInnerPlaintext.real_type after decryption.</t> </dd> <dt>cid </dt>cid:</dt> <dd> <t>The CID value, cid_length bytes long, as agreed at the time the extension has been negotiated. Recall that(as discussed previously)each peer chooses the CID value it will receive and use to identify the connection, so an implementation can choose to always receive CIDs of a fixed length. If, however, an implementation chooses to receivedifferent lengthsCIDs ofCID,different lengths, the assigned CID values must beself-delineatingself-delineating, since there is no other mechanism available to determine what connection (and thus, what CID length) is in use.</t> </dd> <dt>enc_content </dt>enc_content:</dt> <dd> <t>The encrypted form of the serialized DTLSInnerPlaintext structure.</t> </dd> </dl> <t>All other fields are as defined in RFC 6347.</t> </section> <section anchor="mac" numbered="true" toc="default"> <name>Record Payload Protection</name> <t>Several types of ciphers have been defined for use with TLS andDTLSDTLS, and the MAC calculations for those ciphers differ slightly.</t> <t>This specification modifies the MAC calculation as defined in <xref target="RFC6347" format="default"/> and <xref target="RFC7366" format="default"/>, as well as the definition of the additional data used withAEADAuthenticated Encryption with Associated Data (AEAD) ciphers provided in <xref target="RFC6347" format="default"/>, for records with content type tls12_cid. The modified algorithmMUST NOT<bcp14>MUST NOT</bcp14> be applied to records that do not carry a CID, i.e., records with content type other than tls12_cid.</t> <t>The following fields are defined in this document; all other fields are as defined in the cited documents.</t> <dl> <dt>cid </dt>cid:</dt> <dd> <t>Value of the negotiated CID (variable length).</t> </dd> <dt>cid_length </dt>cid_length:</dt> <dd><t>1 byte field indicating the<t>The length (in bytes) of the negotiatedCID.</t>CID (one-byte integer).</t> </dd> <dt>length_of_DTLSInnerPlaintext </dt>length_of_DTLSInnerPlaintext:</dt> <dd> <t>The length (in bytes) of the serialized DTLSInnerPlaintext (two-byte integer). The lengthMUST NOT<bcp14>MUST NOT</bcp14> exceed 2^14.</t> </dd> <dt>seq_num_placeholder </dt>seq_num_placeholder:</dt> <dd> <t>8 bytes of0xff</t>0xff.</t> </dd> </dl> <t>Note that "+" denotes concatenation.</t> <section anchor="block-ciphers" numbered="true" toc="default"> <name>Block Ciphers</name> <t>The following MAC algorithm applies to block ciphers that do not use the Encrypt-then-MAC processing described in <xref target="RFC7366" format="default"/>.</t><artwork<sourcecode name=""type="" align="left" alt=""><![CDATA[type="tls-presentation"><![CDATA[ MAC(MAC_write_key, seq_num_placeholder + tls12_cid + cid_length + tls12_cid + DTLSCiphertext.version + epoch + sequence_number + cid + length_of_DTLSInnerPlaintext + DTLSInnerPlaintext.content + DTLSInnerPlaintext.real_type + DTLSInnerPlaintext.zeros );]]></artwork>]]></sourcecode> <t>The rationale behind this construction is to separate the MAC input for DTLS without the connection ID from the MAC input with the connection ID. The former always consists of a sequence number followed by someothercontent type other than tls12_cid; the latter always consists of the seq_num_placeholder followed by tls12_cid. Although 2^64-1 is potentially a valid sequence number, tls12_cid will never be a valid content type when the connection ID is not in use. In addition, the epoch and sequence_number are now fed into the MAC in the same order as they appear on the wire.</t> </section> <section anchor="block-ciphers-with-encrypt-then-mac-processing" numbered="true" toc="default"> <name>Block Ciphers with Encrypt-then-MACprocessing</name>Processing</name> <t>The following MAC algorithm applies to block ciphers that use the Encrypt-then-MAC processing described in <xref target="RFC7366" format="default"/>.</t><artwork<sourcecode name=""type="" align="left" alt=""><![CDATA[type="tls-presentation"><![CDATA[ MAC(MAC_write_key, seq_num_placeholder + tls12_cid + cid_length + tls12_cid + DTLSCiphertext.version + epoch + sequence_number + cid + DTLSCiphertext.length + IV + ENC(content + padding +padding_length)); ]]></artwork>padding_length) ); ]]></sourcecode> </section> <section anchor="aead-ciphers" numbered="true" toc="default"> <name>AEAD Ciphers</name> <t>For ciphers utilizingauthenticated encryption with additional dataAEAD, the following modification is made to the additional data calculation.</t><artwork<sourcecode name=""type="" align="left" alt=""><![CDATA[type="tls-presentation"><![CDATA[ additional_data = seq_num_placeholder + tls12_cid + cid_length + tls12_cid + DTLSCiphertext.version + epoch + sequence_number + cid + length_of_DTLSInnerPlaintext;]]></artwork>]]></sourcecode> </section> </section> <section anchor="peer-address-update" numbered="true" toc="default"> <name>Peer Address Update</name> <t>When a record with a CID is received that has a source address different from the one currently associated with the DTLS connection, the receiverMUST NOT<bcp14>MUST NOT</bcp14> replace the address it uses for sending records to its peer with the source address specified in the received datagram, unless the following three conditions are met:</t> <ul spacing="normal"> <li>The received datagram has been cryptographically verified using the DTLS record layer processing procedures.</li> <li>The received datagram is "newer" (in terms of both epoch and sequence number) than the newest datagram received. Reordered datagrams that are sent prior to a change in a peer address might otherwise cause a valid address change to be reverted. This also limits the ability of an attacker to use replayed datagrams to force a spurious address change, which could result in denial of service. An attacker might be able to succeed in changing a peer address if they are able to rewrite source addresses and if replayed packets are able to arrive before any original.</li> <li>There is a strategy for ensuring that the new peer address is able to receive and process DTLS records. No strategy is mandated by thisspecificationspecification, but see note (*) below.</li> </ul> <t>The conditions above are necessary to protect against attacks that use datagrams with spoofed addresses or replayed datagrams to trigger attacks. Note that there is no requirement for the use of the anti-replay window mechanism defined inSection 4.1.2.6 of DTLS 1.2.<xref target="RFC6347" sectionFormat="of" section="4.1.2.6"/>. Both solutions, the "anti-replay window" or "newer" algorithm, will prevent address updates from replay attacks while the latter will only apply to peer address updates and the former applies to any application layer traffic.</t> <t>Note that datagrams that pass the DTLS cryptographic verification procedures but do not trigger a change of peer address are still valid DTLS records and are still to be passed to the application.</t><t>(*)<t indent="3">(*) Note: Application protocols that implement protection against spoofed addresses depend on being aware of changes in peer addresses so that they can engage the necessary mechanisms. When delivered such an event, anapplication layer-specificaddress validation mechanism specific to the application layer can betriggered,triggered -- forexampleexample, one that is based on successful exchange of a minimal amount of ping-pong traffic with the peer. Alternatively,ana DTLS-specific mechanism may be used, as described in <xreftarget="I-D.ietf-tls-dtls-rrc"target="DTLS-RRC" format="default"/>.</t> <t>DTLS implementationsMUST<bcp14>MUST</bcp14> silently discard records with bad MACs or that are otherwise invalid.</t> </section> <section anchor="examples" numbered="true" toc="default"><name>Examples</name><name>Example</name> <t><xref target="dtls-example2" format="default"/> shows an example exchange where a CID is useduni-directionallyunidirectionally from the client to the server. To indicate that a zero-length CID is present in the "connection_id"extensionextension, we use the notation 'connection_id=empty'.</t> <figure anchor="dtls-example2"> <name>Example DTLS 1.2 Exchange with CID</name> <artwork name="" type="" align="left" alt=""><![CDATA[ Client Server ------ ------ ClientHello --------> (connection_id=empty) <-------- HelloVerifyRequest (cookie) ClientHello --------> (connection_id=empty) (cookie) ServerHello (connection_id=100) Certificate ServerKeyExchange CertificateRequest <-------- ServerHelloDone Certificate ClientKeyExchange CertificateVerify [ChangeCipherSpec] Finished --------> <CID=100> [ChangeCipherSpec] <-------- Finished Application Data ========> <CID=100> <======== Application Data Legend: <...> indicates that a connectionidID is used in the record layer (...) indicates an extension [...] indicates a payload other than a handshake message ]]></artwork> </figure><t>Note:<t indent="3">Note: In the exampleexchangeexchange, the CID is included in the record layer once encryption is enabled. In DTLS1.21.2, only one handshake message is encrypted, namely the Finished message. Since the example shows how to use the CID for payloads sent from the client to the server, only the record layer payloads containing the Finished message or application data include a CID.</t> </section> <section anchor="priv-cons" numbered="true" toc="default"> <name>Privacy Considerations</name> <t>The CID replaces the previously used 5-tuple and, as such, introduces an identifier that remains persistent during the lifetime of a DTLS connection. Every identifier introduces the risk of linkability, as explained in <xref target="RFC6973" format="default"/>.</t> <t>An on-path adversary observing the DTLS protocol exchanges between the DTLS client and the DTLS server is able to link the observed payloads to all subsequent payloads carrying the same ID pair (forbi-directionalbidirectional communication). Withoutmulti-homingmultihoming or mobility, the use of the CID exposes the same information as the 5-tuple.</t> <t>Withmulti-homing,multihoming, a passive attacker is able to correlate the communication interaction over the two paths. The lack of a CID update mechanism in DTLS 1.2 makes this extension unsuitable for mobility scenarios where correlation must be considered. Deployments that use DTLS inmulti-homingmultihoming environments and are concerned about these aspectsSHOULD<bcp14>SHOULD</bcp14> refuse to use CIDs in DTLS 1.2 and switch to DTLS 1.3 where a CID update mechanism is provided and sequence number encryption is available.</t><t>The<t>This specification introduces record padding for the CID-enhanced record layer, which is a privacy feature not available with the original DTLS 1.2 specification. Padding allowsto inflatethe size of the ciphertext to be inflated, making traffic analysis more difficult. More details about record padding can be found inSection 5.4Section <xref target="RFC8446" section="5.4" sectionFormat="bare"/> andAppendix E.3Appendix <xref target="RFC8446" section="E.3" sectionFormat="bare"/> ofRFC 8446.</t><xref target="RFC8446"/>.</t> <t>Finally, endpoints can use the CID to attach arbitrary per-connection metadata to each record they receive on a given connection. This may be used as a mechanism to communicate per-connection information to on-path observers. There is no straightforward way to address this concern with CIDs that contain arbitrary values. Implementations concerned about this aspectSHOULD<bcp14>SHOULD</bcp14> refuse to use CIDs.</t> </section> <section anchor="sec-cons" numbered="true" toc="default"> <name>Security Considerations</name> <t>An on-path adversary can create reflection attacks against third parties because a DTLS peer has no means to distinguish a genuine address update event (for example, due to a NAT rebinding) from one that is malicious. This attack is of particular concern when the request is small and the response large. See <xref target="peer-address-update" format="default"/> for more on address updates.</t> <t>Additionally, an attacker able to observe the data traffic exchanged between two DTLS peers is able to replay datagrams with modified IPaddress/portaddresses / port numbers.</t> <t>The topic of peer address updates is discussed in <xref target="peer-address-update" format="default"/>.</t> </section> <section anchor="iana-considerations" numbered="true" toc="default"> <name>IANA Considerations</name> <t>This documentrequestsimplements threeactions from IANA.</t>IANA updates.</t> <section anchor="extra-column-to-tls-extensiontype-values-registry" numbered="true" toc="default"> <name>Extra Column Added to the TLS ExtensionType Values Registry</name> <t>IANAis requested to addhas added an extra column named "DTLS-Only" to the "TLS ExtensionType Values" registry to indicate whether an extension is only applicable to DTLS and to include this document as an additional reference for the registry.</t> </section> <section anchor="entry-to-the-tls-extensiontype-values-registry" numbered="true" toc="default"><name>Entry to<name>New Entry in the TLS ExtensionType Values Registry</name> <t>IANAis requested to allocatehas allocated an entrytoin the existing "TLS ExtensionType Values"registry,registry forconnection_id(TBD1)connection_id(54), as described in the table below. Although the value 53hashad been allocated by early allocation for a previous version of this document, it is incompatible with this document.Once this document is approved for publication,Therefore, the early allocationwill behas been deprecated in favor of this assignment.</t><artwork name="" type="" align="left" alt=""><![CDATA[ Value Extension Name TLS 1.3 DTLS-Only Recommended Reference -------------------------------------------------------------------- TBD1 connection_id CH, SH Y N [[This doc]] ]]></artwork><table anchor="iana-tls-ext-entry"> <name></name> <thead> <tr> <th>Value</th> <th>Extension Name</th> <th>TLS 1.3</th> <th>DTLS-Only</th> <th>Recommended</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>54</td> <td>connection_id</td> <td>CH, SH</td> <td>Y</td> <td>N</td> <td>RFC 9146</td> </tr> </tbody> </table> <t>A newcolumn "DTLS-Only" iscolumn, "DTLS-Only", has been added to the registry. The valid entries are "Y" if the extension is only applicable to DTLS, "N" otherwise. All the pre-existing entries are given the value "N".</t><t>Note:<t indent="3">Note: The value "N" in theRecommended"Recommended" column is set because this extension is intended only for specific use cases. This document describes the behavior of this extension for DTLS 1.2 only; it is not applicable to TLS, and its usage for DTLS 1.3 is described in <xreftarget="I-D.ietf-tls-dtls13"target="RFC9147" format="default"/>.</t> </section> <section anchor="entry-to-the-tls-contenttype-registry" numbered="true" toc="default"><name>Entry to<name>New Entry in the TLS ContentType Registry</name> <t>IANAis requested to allocate tls12_cid(TBD2)has allocated tls12_cid(25) in the "TLS ContentType" registry. The tls12_cidContentTypecontent type is only applicable to DTLS 1.2.</t> </section> </section> </middle> <back> <references> <name>References</name> <references> <name>Normative References</name><reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"> <organization/> </author> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc6347"> <front> <title>Datagram Transport Layer Security Version 1.2</title> <author fullname="E. Rescorla" initials="E." surname="Rescorla"> <organization/> </author> <author fullname="N. Modadugu" initials="N." surname="Modadugu"> <organization/> </author> <date month="January" year="2012"/> <abstract> <t>This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6347"/> <seriesInfo name="DOI" value="10.17487/RFC6347"/> </reference> <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446"> <front> <title>The Transport Layer Security (TLS) Protocol Version 1.3</title> <author fullname="E. Rescorla" initials="E." surname="Rescorla"> <organization/> </author> <date month="August" year="2018"/> <abstract> <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t> <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t> </abstract> </front> <seriesInfo name="RFC" value="8446"/> <seriesInfo name="DOI" value="10.17487/RFC8446"/> </reference> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"> <organization/> </author> <date month="May" year="2017"/> <abstract> <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference> <reference anchor="RFC7366" target="https://www.rfc-editor.org/info/rfc7366"> <front> <title>Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title> <author fullname="P. Gutmann" initials="P." surname="Gutmann"> <organization/> </author> <date month="September" year="2014"/> <abstract> <t>This document describes a means of negotiating the use of the encrypt-then-MAC security mechanism in place of the existing MAC-then-encrypt mechanism in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The MAC-then-encrypt mechanism has been the subject of a number of security vulnerabilities over a period of many years.</t> </abstract> </front> <seriesInfo name="RFC" value="7366"/> <seriesInfo name="DOI" value="10.17487/RFC7366"/> </reference><xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7366.xml"/> </references> <references> <name>Informative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6973.xml"/> <!-- draft-ietf-tls-dtls13 (RFC 9147) --> <referenceanchor="RFC6973" target="https://www.rfc-editor.org/info/rfc6973"> <front> <title>Privacy Considerations for Internet Protocols</title> <author fullname="A. Cooper" initials="A." surname="Cooper"> <organization/> </author> <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"> <organization/> </author> <author fullname="B. Aboba" initials="B." surname="Aboba"> <organization/> </author> <author fullname="J. Peterson" initials="J." surname="Peterson"> <organization/> </author> <author fullname="J. Morris" initials="J." surname="Morris"> <organization/> </author> <author fullname="M. Hansen" initials="M." surname="Hansen"> <organization/> </author> <author fullname="R. Smith" initials="R." surname="Smith"> <organization/> </author> <date month="July" year="2013"/> <abstract> <t>This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content.</t> </abstract> </front> <seriesInfo name="RFC" value="6973"/> <seriesInfo name="DOI" value="10.17487/RFC6973"/> </reference> <reference anchor="I-D.ietf-tls-dtls13" target="https://www.ietf.org/archive/id/draft-ietf-tls-dtls13-43.txt">anchor='RFC9147' target="https://www.rfc-editor.org/info/rfc9147"> <front> <title>The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title> <authorfullname="Eric Rescorla"> <organization>RTFM, Inc.</organization> </author> <author fullname="Hannes Tschofenig"> <organization>Arm Limited</organization> </author> <author fullname="Nagendra Modadugu"> <organization>Google, Inc.</organization>initials='E' surname='Rescorla' fullname='Eric Rescorla'> <organization /> </author> <author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'> <organization /> </author> <author initials='N' surname='Modadugu' fullname='Nagendra Modadugu'> <organization /> </author> <dateday="30" month="April" year="2021"/> <abstract> <t> This document specifies Version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection/non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. </t> </abstract>year='2022' month='March' /> </front> <seriesInfoname="Internet-Draft" value="draft-ietf-tls-dtls13-43"/>name="RFC" value="9147"/> <seriesInfo name="DOI" value="10.17487/RFC9147"/> </reference> <!-- draft-ietf-tls-dtls-rrc (I-D Exists) ("long way"; one author is editor) --> <referenceanchor="I-D.ietf-tls-dtls-rrc" target="https://www.ietf.org/archive/id/draft-ietf-tls-dtls-rrc-00.txt">anchor='DTLS-RRC'> <front> <title>Return Routability Check for DTLS 1.2 and DTLS 1.3</title> <authorfullname="Hannes Tschofenig"> <organization>Arm Limited</organization>initials='H' surname='Tschofenig' fullname='Hannes Tschofenig' role="editor"> <organization /> </author> <authorfullname="Thomas Fossati"> <organization>Arm Limited</organization>initials='T' surname='Fossati' fullname='Thomas Fossati'> <organization /> </author> <dateday="9" month="June" year="2021"/> <abstract> <t> This document specifies a return routability check for use in context of the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol versions 1.2 and 1.3. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Transport Layer Security Working Group mailing list (tls@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/tls/. Source for this draft and an issue tracker can be found at https://github.com/tlswg/dtls-rrc. </t> </abstract>month='March' day='7' year='2022'/> </front> <seriesInfoname="Internet-Draft" value="draft-ietf-tls-dtls-rrc-00"/>name='Internet-Draft' value='draft-ietf-tls-dtls-rrc-05' /> </reference> </references> </references> <sectionanchor="history" numbered="true"anchor="acknowledgements" numbered="false" toc="default"><name>History</name> <t>RFC EDITOR: PLEASE REMOVE THE THIS SECTION</t> <t>draft-ietf-tls-dtls-connection-id-12</t> <ul spacing="normal"> <li>Improved peer address update text</li> <li>Editorial improvements</li> <li>Clarification regarding the use of the TLS ExtensionType Values Registry</li> </ul> <t>draft-ietf-tls-dtls-connection-id-11</t> <ul spacing="normal"> <li>Enhanced IANA considerations section</li> <li>Clarifications regarding CID negotiation and zero-length CIDs</li> </ul> <t>draft-ietf-tls-dtls-connection-id-10</t> <ul spacing="normal"> <li>Clarify privacy impact.</li> <li>Have security considerations point to <xref target="peer-address-update" format="default"/>.</li> </ul> <t>draft-ietf-tls-dtls-connection-id-09</t> <ul spacing="normal"> <li>Changed MAC/additional data calculation.</li> <li>Disallow sending MAC failure fatal alerts to non-validated peers.</li> <li>Incorporated editorial review comments by Ben Kaduk.</li> </ul> <t>draft-ietf-tls-dtls-connection-id-08</t> <ul spacing="normal"> <li>RRC draft moved from normative to informative.</li> </ul> <t>draft-ietf-tls-dtls-connection-id-07</t> <ul spacing="normal"> <li>Wording changes in the security and privacy consideration and the peer address update sections.</li> </ul> <t>draft-ietf-tls-dtls-connection-id-06</t> <ul spacing="normal"> <li>Updated IANA considerations</li> <li>Enhanced security consideration section to describe a potential man-in-the-middle attack concerning address validation.</li> </ul> <t>draft-ietf-tls-dtls-connection-id-05</t> <ul spacing="normal"> <li>Restructed Section 5 "Record Payload Protection"</li> </ul> <t>draft-ietf-tls-dtls-connection-id-04</t> <ul spacing="normal"> <li>Editorial simplifications<name>Acknowledgements</name> <t>We would like tothe 'Record Layer Extensions' and the 'Record Payload Protection' sections.</li> <li>Added MAC calculationsthank <contact fullname="Hanno Becker"/>, <contact fullname=" Martin Duke"/>, <contact fullname="Lars Eggert"/>, <contact fullname="Ben Kaduk"/>, <contact fullname="Warren Kumari"/>, <contact fullname="Francesca Palombini"/>, <contact fullname="Tom Petch"/>, <contact fullname="John Scudder"/>, <contact fullname="Sean Turner"/>, <contact fullname="Éric Vyncke"/>, and <contact fullname="Robert Wilton"/> forblock ciphers with and without Encrypt-then-MAC processing.</li> </ul> <t>draft-ietf-tls-dtls-connection-id-03</t> <ul spacing="normal"> <li>Updated list of contributors</li> <li>Updated list of contributors and acknowledgements</li> <li>Updated example</li> <li>Changed record layer design</li> <li>Changed record payload protection</li> <li>Updated introduction and security consideration section</li> <li>Author- and affiliation changes</li> </ul> <t>draft-ietf-tls-dtls-connection-id-02</t> <ul spacing="normal"> <li>Movetheir review comments.</t> <t>Finally, we want tointernal content types a la DTLS 1.3.</li> </ul> <t>draft-ietf-tls-dtls-connection-id-01</t> <ul spacing="normal"> <li>Remove 1.3 based onthank theWG consensus atIETF101</li> </ul> <t>draft-ietf-tls-dtls-connection-id-00</t> <ul spacing="normal"> <li>Initial working group version (containing a solution for DTLS 1.2 and 1.3)</li> </ul> <t>draft-rescorla-tls-dtls-connection-id-00</t> <ul spacing="normal"> <li>Initial version</li> </ul> </section> <section anchor="working-group-information" numbered="true" toc="default"> <name>WorkingTLS Working GroupInformation</name> <t>RFC EDITOR: PLEASE REMOVE THE THIS SECTION</t> <t>The discussion listchairs, <contact fullname="Chris Wood"/>, <contact fullname="Joseph Salowey"/>, and <contact fullname="Sean Turner"/>, forthe IETF TLS working group is located at the e-mail address <eref target="mailto:tls@ietf.org">tls@ietf.org</eref>. Information on the grouptheir patience, support, andinformation on how to subscribe to the list is at <eref target="https://www1.ietf.org/mailman/listinfo/tls">https://www1.ietf.org/mailman/listinfo/tls</eref></t> <t>Archives of the list can be found at: <eref target="https://www.ietf.org/mail-archive/web/tls/current/index.html">https://www.ietf.org/mail-archive/web/tls/current/index.html</eref></t>feedback.</t> </section> <section anchor="contributors"numbered="true"numbered="false" toc="default"> <name>Contributors</name> <t>Many people have contributed to this specification, and we would like to thank the following individuals for their contributions:</t><artwork name="" type="" align="left" alt=""><![CDATA[ * Yin Xinxing Huawei yinxinxing@huawei.com ]]></artwork> <artwork name="" type="" align="left" alt=""><![CDATA[ * Nikos Mavrogiannopoulos RedHat nmav@redhat.com ]]></artwork> <artwork name="" type="" align="left" alt=""><![CDATA[ * Tobias Gondrom tobias.gondrom@gondrom.org ]]></artwork><contact fullname="Yin Xinxing"> <organization>Huawei</organization> <address> <email>yinxinxing@huawei.com</email> </address> </contact> <contact fullname="Nikos Mavrogiannopoulos"> <organization>RedHat</organization> <address> <email>nmav@redhat.com</email> </address> </contact> <contact fullname="Tobias Gondrom"> <organization></organization> <address> <email>tobias.gondrom@gondrom.org</email> </address> </contact> <t>Additionally, we would like to thank the Connection ID task force team members:</t> <ul spacing="normal"><li>Martin Thomson (Mozilla)</li> <li>Christian Huitema<li><t><contact fullname="Martin Thomson"/> (Mozilla)</t></li> <li><t><contact fullname="Christian Huitema"/> (Private OctopusInc.)</li> <li>Jana Iyengar (Google)</li> <li>DanielInc.)</t></li> <li><t><contact fullname="Jana Iyengar"/> (Google)</t></li> <li><t><contact fullname="Daniel KahnGillmor (ACLU)</li> <li>Patrick McManus (Mozilla)</li> <li>Ian Swett (Google)</li> <li>Mark Nottingham (Fastly)</li>Gillmor"/> (ACLU)</t></li> <li><t><contact fullname="Patrick McManus"/> (Mozilla)</t></li> <li><t><contact fullname="Ian Swett"/> (Google)</t></li> <li><t><contact fullname="Mark Nottingham"/> (Fastly)</t></li> </ul> <t>The task force team discussed various design ideas, including cryptographically generated sessionidsIDs using hash chains and public key encryption, but dismissed them due to their inefficiency. The approach described in this specification is the simplest possible design thatworksworks, given the limitations of DTLS 1.2. DTLS 1.3 provides better privacyfeaturesfeatures, and developers are encouraged to switch to the new version of DTLS.</t> </section><section anchor="acknowledgements" numbered="true" toc="default"> <name>Acknowledgements</name> <t>We would like to thank Hanno Becker, Martin Duke, Lars Eggert, Ben Kaduk, Warren Kumari, Francesca Palombini, Tom Petch, John Scudder, Sean Turner, Eric Vyncke, and Robert Wilton for their review comments.</t> <t>Finally, we want to thank the IETF TLS working group chairs, Chris Wood, Joseph Salowey, and Sean Turner, for their patience, support and feedback.</t> </section></back><!-- ##markdown-source: H4sIAB1U0mAAA+0923IbN5bv+Aqs8hBphqQt23ES5VJRJDnWxLe15HinUlkX yAZJlJrd3Ea3ZMaV/Zb9lv2yPTdcukk58szWPi2rZiKyG8DBud8Aj8dj1bq2 tEf6pK4qO2tdXenzwlatmzvbeD2vG316+exCH04eKDOdNvb6KP7QG3SqinpW mRXMVTRm3o6dbefjtvTjAv9vFl8du2J8+FDNTGsXdbM50r4tVLcu4Ls/0o8f PvpSKbdujvS6sV88/PKry6bz7YP797++DxA01hzpCzvrGtdu1E3dXC2aulsf aQBJXdkN/FIc6fOqtU1l2/EpQqKUb01VvDNlXQF0G+vV2h0prZv5zBa+3ZTy q9ZtPcv+dBViIvzg66Zt7NzH75tV72vbuFl8eVavVjA2PnVV6aq0jH3fjkvn 2zFMMq1LeG1c/+Wv8ARwuDLrtasW/K7p2mXdALBjeEgfV8HbZxP92vpZ3ZQm /M6oPwMgth7VzcJU7neD2D/Sry+fPB8BimaT8LypEQO2cG3dhN/syrgSfrxq fmja+WoCG1JDKJ5O9KWfLeu5rdyiD8dTA+T2Ox73YTluVvqZW7nWFncAZkmT Tto46Q+mYcgGgF1O9JPae1ikD9Xlsl4ZP3z2pyDJ8i2Nnsx59G1rH0/0z43p fH/l49nSrfoP+sv+WMOuJucv9U+r6dPBwgYHT65w8A9Tes/VSlV1s4LB1xZZ +fWTkweHh1/LnyhE8udXjx49PgKBquaD1x9//eVD/PN8fDrpierh7p/HTTOD icbjsTZTYHYzA8G6XDqPPNshs2u/tjPUGx5QZfvKQe+fnJ8egFhUMLSbtaRY 8K1T05pFY1b6sjGVX4OMqWdmY5so5Hof1c0BaIMaRLIu9TXoJZwUFNBEqWMN E2uAwlTaRcWlZ6ZpnC2AJLRKY0EgCl3SzEtrCourm1YvACEEroJX3NrhNkwB zAcrmFJHtMF6CLG3JW6pWtCsIKhNvW4caC54IuAa70Fz0JCJOq/03qyEn9zM lHukOEfZJGbnMF3PaTcVcBe+ReqWd6BwozP4fQ3aYwn7u3HtkmBZ2nKNA/Hv L8Ztty7tRJ/zd193zczq81e4tcZ6RFZxD8RLHiDW9QykawG4KAAe2V/p5rZ1 KysA1dWijvB4mAZhhfeqgD8LyGwApLLUU6u7ykxLC3pUlzUqe5oSNgEvtmnf wBGoDSfIS1ZX9kYDGZa2wR8D2ZgGvFektil9jfxwDQT3PAOQrd2srbbVrNms EYsK9igTjJnuayRstZgwE69cUZRWKfWZRnvR1EVHzMqAbLOl3s2WHz6IvP3x R2LRG1AyAJpbVJagV7xdwF1mBkskRBum9yNA95XVb05fTYRP6DtzTGvgDUUI MKgGC780V3akb5ZutgRmrxDhyBZda5h1yw1AsII3cdX9NYx3s640TQlWE0m2 7qYlmAowmZowVsNu18sNSlLnbXEw0cdzMKLIot1sBqDOuzJbWYHhWlk0ebdO gZQHCUFAAJmg7tzCVWTQUEpnBOcIuBzcAJYAoBegZ85SbEr8DTHK6AJTA7pG tTf12Ld2zbIHihGYoaxvPBC+WAN3tp6WXQFG3e+B5XwbJMNVDqdWcSMgTQ3o c9jk1Nv/6Ej8AWYBjyHPgQDfCHE7IpYHqtYA9HppvAVS2MZuDwZkyHiL+scD gPU14RW8kYVa28bVBYGHguZB6BlqCzSfipADhj2LVV0BOivLyEUZI7epUHUY hsSIYmvfrx2IOzA86CGSWuDLoKRJNwLvksdF+xkoCFYLgri1RZhhg0JZJbp2 w0qc506KT79BxdmCCmgtYguW8jVANANMAacDSy0RlhfHlyCiU0dcOlIwFSDy 2pQdiDUuBga1m8/dDNUyMwBpep3YGb77zgY1H/w+hBrerhaemb2w1w54GJgE WRo0C3ALbMOXFjiJSUB8A9gHB9MTKl2jp6aF9xNCEQSrekDrEowJjU2Sredg tbsGxTNoZ8BpV7asAJgbDem6yIeToS0t7NyhBwWiTfCysq2T741sXhQwzy47 Cw+RQTPLwbaPdoCOtbfIMUJcsaAV+OMtGrNCXzsDM+NwFVdHY0sKFNeEEbzG 7eqaV2lpC/V6TeyAMg3jVrBjVcPoJpodma03xQQ1M7C0RX84IXMKsgGzgwOC RFW5pEw3mvHzkDmabILsUqZ2PhgJW4yQz5XRK4tgOL8KVoUg0Gwvgt1AEOvp vPPRmK1L48h6ARdUi3Y5QWMC5LhG0QBPh6To0jZgxeuyXmzYtKCIYpji9d7z NxeXeyP+r37xkv5+ffavb85fn53i3xdPj589i38oeePi6cs3z07TX2nkycvn z89enPJg+FX3flJ7z4//vkd71nsvX12ev3xx/GyPZSdnPZQ8Vi+4uwboiCxh vAKTNmvclFXHjyev/vu/Dh+BAfwXcT7BAvKXrw6/fARfUPR4NVJb/BXwtlGg JS3KboXaG5TC2rVg00eknpb1TaVRlwI2BzIBGgb+gKDUrFzpDFkN4oooFJk1 zlmdjSKIQLXozMJqRVpsa+OOrHba4oWI1UNkIZoavWmYGumMs+8loX/nij19 FmTlNmludwyKAibmXAX7CRCclKj6nlqwcYTIC9uA8eDvgAkPm/HiOmVaApne 5ZreYCBPdhJe/k/4gINvq26lP3Ck0YNo//LH08ODkd5//MUXD784gDf+SBu7 hLm/4Sn6q74jawerlWzNcPu9nVnyaMuuiF65ynY30iQD6MsZUeZJr50XmqMG UKpiBuJ3JUN81GRkP1g10fzAIqAb+Lkn/CF3d2yywS5ZUuQqoDPqtZKtzrH+ 3Tb1mCU8WwD1P2oCz4FEGqLI5FuwUWymcQFYLinOaQcMUcPAqmbgdoBWVwye EvAS3SR+EsqBZjXgtoAWLr69P5k8+Pevxofff0M0y/EXSHYclkFvQnQaLgdg iYcB8rJGp0Z8zQGzJmsQTG7GkaNAvhA/kF3J8a+EIjvwrzP83xjUjm4L+YR4 tQPx2aZydCeafO63MK8i5hNQwqBCpxw8wP+PdmYQaoteJ3ogG3rIjBV44uMS Ttgw7KSGgAmFk9eD0dEyibUCnehIL63BSXUQTimyS1V0dwMqDaiYdVlvUNuM RfBnHG7DemKfOIRF3ysBqFLQ7MHeknDNDJO3a2AhdIdgt8y/7KIHd6Os66tu PSKY7HsDQalFC7w01zGC5HVhMmBST4OmCCyGKq60Y3JTA5QTdYGwOZxnFZS2 Z8UAYzmqDDElol4R24K2Kdx8DhYjbRRNNbkX5CmijryInjWiOsKVwnvH8jjQ UdFraCFqn4/UEDhiQSRpIMQ1mCWEMVMY7MuyYCUixlRIT1oq8Y1hzg1PDisH cCXOK8Aeo09Bfj8CaNecbYhuPpjCUVrZvmcnC+xAKw4URGIkpeIakaMXIno0 1mQ8G8tIgQVZ4sBtQCA56NgLEqsITAnD0KmlhdmByH0zCLjHssYInpEwqWi5 YecLW9nGlEk30pzBoRtTohYFoR2n8C1oDQaiqGkcbGkF5MLMDm1VeCGOAkZ/ i7Jt+qkMCC/RT18BrEAfYKfoD4/+TKx7zrOZwzToDJ7PeQEMnjyKhSXwsldx WlL3c8LaCBc2uc5DFoeRuBEEuAA11zof/FNKX0F44xoGaxTTMRjZKXSExux6 FAPnXCQ5JU5IyqYxvmM1CvE6R82B/nGlfX9wywZ3bg6inboaDw0p7UHt3gNF tCmbw247ChbNuxGtYMVSqa3YQYd9A/k/fOASRIxU0DmVaEIhxz4/PsmzJ/2x KzOD9xFhnE3IkIbZ0gfvwPZO1KsYC6zNpqwxKKwsGqWOw0mSjD6EkgFFTMis CmcFvBJ3sn3AwFg7FtO4XB8KdIdsm9Ge4zkVSIlqGoQ2gB+0d9jRzsylpA7V 7UsiJ/eXHcwd5lV5ahMGIjgAGAA03eTpShoEpmFpZ1eRHVemQHWvos5Dq0zS nFhKZyxFXueasi0TZM/djJe9FRPRDWazgGJFjgfKSfDuipARDKC1jWVxB1el AvvvCgpgYgShsgji0QSz1YcxjpAQZUhpNONhmRju7iYBQabvyLy5cIvu27Wm imuGvNBu7cHqkNY1JaZhhuv2tq36m+4Dg5HUa56b86sx0vASQwVnJl/Ep6wT 2o5edj8pOPXhw47iBkCQ6hQQbFLuxjTNJjfCMvVDjK1qsUNGxxR3W+tdDClw LKNHB6wFYjJSSTK8pGy3dWUeLwWXznn0Djqyn0pm7yseDNYeHEz0G29j2NWT VAQGN8bxHwY67bKxlrwsQarHsg7Fs6SUKYTjGMZT1C2mgoIsjEtgV6u6QVev Rc+Khw65QeJNzpM0NWaQ+8G18GYYD8JUbukYWNEVkg9NpsBW17asQQT64qaB qWBJIFnSxeJFkxtE3t1qbUjqSfXkKJ/op5gSGwmykIdU5h2lKWPkSbrMzlvd VeJfZQmMZHVikojknWM4vRXGweeEN39J9KUwOz56JYWFX6T0JSWw7I0O1jh8 rO26ni0HPz/6SnNqe2bfQcw/tc32ONaN2e8SVs4bs0Bv99ceDib8+m/y/h99 DFGsqT4c6c/6+9fUafDdXhTbhFPRAK/Yck72/hDFGF3YqUVNhRpj1LfC5GV6 ibrnrvHgjTeYXgK9jAl2VqPoQ/d4i5JSaynyhfweAAOyTi7pOchrs4Pmkn0A tVtu8H2qGtmizxSBA5RwgMPJ7swGIaBncH/to3rIJyg17wbMgiT9inxIL6Pf 1fN3ssk+zfrbHBCuD3ag3guwODswJKTTFxFTSMTg1mB7SSOZhZhgCbzF/iF7 gTGPGjemjkg99KgnMp9CfGua3PWC8bR9GKuPwRlppq5tTLMJLkDTUY2VvAIK 3AvWZeBtbHTMTSKi+tMbqojFvDJpyhAzx3JkP9uNk3DhuCrQR4a9AyXgpU1e 1kV1hJ5P7dHJX9UdJTupQoR5VwGkrVvgVoioqBoE6qsKwz3WukpsWsAY/sLa aIG/mDyCreIMWf6SICIVDlbMuBIG7b+oKaktESLaNr1NZUYKOgc4Eaw+lz3t 4IiQXe3Z78mBlFe330cKREWFYkSeV0yIgOSBnSaXK5Y2TlLpIQngUP/2vP6s 2gHyQP7HHTVy3QFOiCP1d8n8/p/o6JTi+xX+9y5oBN3/3LunUTaJKe+s32HB d0HT9DG6U8enx5JQjMoiqwIN1Tzge2wrsJCoKDOSsdInPZGQiyKLDEK/9KWe 1MSA7ML/5L/FBCtCjAQub1BSIEYhjTP0mIZOB0nZznLRHOSxCF5hn2snUU+x csBJChs8FeAuWDBsKaaORzqRURQPSjp5D+CH25SoofRYm6fZcYGYDkj+I0g9 oBOLKSTC++gYOT/rPIaA4Mhdu7rz5eZAkpeWCm81qJuoXLLEdhsywZKfpHwq Jd16Rd/k1I60x/IE4b2XH6OMFS9E9UqmSJg4ZO+wbPAeq+Os/DXEniPaZ32D EfSImmEG8zLwOGmYbZgD9JJUGYUdYhcONWTErYLC78BhIA+inEOsgz16hhJy sRAfk2CUQ8K5UrHQXIPyDAnJPCAAEmTB8D5H2p0f8aOUgDwQVnXk8QO7ZPIY 2CalhNErDdzpbYMtEr/Dzx/1V5Q6xrYBClBINbA/RY5zDNdCtJdHY8Ggv4rN D/rDZ+ixK3WBVAHBQbYnLLPwSwKIODNMjoaGMv3ohVGTQFVItwBnH9QgbvAS jyPHhGmZstqXbrFsy81kZ2C4qovUejYMRvrbzYNRDhOxaPnlw8dgGkkIbyzg TOImGudCWxbxUWoPo5oXpVlog8dnx6cqQB0ryf0VR7TBEJfQsFtSSkR+JftC d3ZRN/C6JCCwujuVfhNO84Q580woB7akFUfaTexkpG5fmrkEhld5YovsdYwe cybKUNqro35DVd0dPKd6I5DAlFOUYT6qy19IDwm6syAZBWc/JNiDCPEoUacw +JA9CQljOXM5KEfsnBnmSd7ytkyJHyoz7MMOSHMf3E0g97FvieCififbHGDz bTZhpKl9P0MD8ODfDx8BROAUoD/wDtzwmV3WJfiQAMhXYjVg6fvv53OlyHnb ++sekASozj1xmLCtpA1RffaZ/rGsZ1dif/2QqigwicGYqTiHT6OEp3tJ9pDX PGP9NEZ3bYzzSLSPqYZBwB+lLHO7YMQ+/O/dDSxt313ZzSg6KTs2r/8an6a0 WPots6sff3Hg64SW0vQCOWnZ94F31l8z+/YxFhqsP/Akgih+9KXkbnz0NY5+ 8OEBB3VE7kZaA1FHQ/BQxGyR1KE4PUu5/7VpQpMLktRV665V8SwAqg5w0IZJ X0weNfWqPyol2ntvsv+FFg0zZ+wXICSOGuTm1BkroQBjXDGzcuqGesmkf6in PHu66xuWeWriUjvWYLHd5rF8pUwRHpe468USZPPxo/EhV2Vb7lUsUclSDngI 9yhNocit4qoAVUF5QG8HNzuS6dKdRcVJ9hPOq2iFOB/C7MpZ9z6jcuYL4gIS wrZWiTqMAIOobHDfbPFiBMzNvUA/ciOGGoTp+jHh/ydUzP/rll26ZWeAlj0/ /yX7cvbiZD+qlJjiin/JVg6CfgDyoveS7MMTLFELqbvWgWWj+Cp17wLis5ws t4tEz0iRZ9TLO4uHNot1ICnt7PSpMucto2d6i7uNvvsTMvY/u2jV/+wk8adO 8qfk73+GzND/3M4aW5Df+uxjJilQX7/CkPBYmn/fUIEf/H0MFMfSEjzmsn9I zcZqhzQKSVZForGCvVCuhMgpA5lHpUAtWgusKsy6Bn8sUx0yP95AdieLOEPB l+sx0XtqLHFC4CnajSN94mMaDnlRnGCFMS0YAwqI41p9ePsN09myRaybjVRX cTd/j+G50IIt4k7aQRtsWGhjuWVrohTaZw31eHQEsAL7ZCiot0lFpPSKX0k/ 8p9Fx/3ft60HFNur7I1t9silxQiWTOMUjOsOo6KYDQ/E0HIBErtx44RhCTyf RlYlW01CE8CCosLSunE11dKMdAFTQ6i0mgvyVxjzsam/cRgTGi6NkelU4S0Z ztWABg0sZwyXlAbyteRGmS2mjo4W8JkWcA7M7Ar8A2nfIQba9IGukXWQIYAV ugYzKbq/cGjcnNVdWUivN+4FvHHwDXAlbFBzMzuhdLQsKXvLe5rwpAUXjmli zmj18MGdABsOqGRYY8nADfgWDw9i2mqe9rTGdVvfG4znpChqn2M+GPPSfFDD lIFtOANiMKmARzY3JEi28uGckOSqsBTdB9WHRVSeSgrFwIx5/US/qNP8ZBsq OtgQ63T9YF9hI5+3VNOzev8vB1L60+x05CI3rXFddIIsLmsaakCXIxnaLLCq 2QpNhEGRDxL5qb3Er+saPaiIW+4Q2sUrLaBvgWjgKXFrWWYdeJ/TSQ2IFHhW VAAJWZKQYAADO+bJYfWqAO8t5ZxSCK36zQWPcXhIuk70jyjBvi47woM0MG3P vAcbUUEFRPdsxBlATBzKgTiiqBzSZb0t0wTMgQSUnJlnhzs7r8KHgBDrOXuE yUIbSogFkmMIzKjy8zSs4oBL8EjIRKJeDkn7GmZtfNYh0FOlokZlxqQjFbeG cvtYoGDQK4DYHujITtyQyB58zsp8oiC+wCoJAeIkDdE37Ql2gdyLOznSx9le w1Ey2VFMf2aHkSLzbjMnOMdrS333Ujk1NwgSpurkuAWomHxL8IuvI5NuKG8L bgP2yrNsi+yoyIihhw6Tptek5rlxEcYhz1DSdot4sTM1am5CoGTwIo9Ln6PQ AWu+eYcpOguMFLCVBvFaVyo7pBbaHTmMXLnKrUAJS1UNSQkIGa+xtCaslCw/ ooQCPdtUdFYWzy4ZTvynrtoEKNYLpZOl34zA1d+dZ2gpQiGO2d3oCmJEXhDm 701T9FOFU1NgVOO5d0yMabKO0odEedwzRhe48lIIE/w9wAaYJbZm0NEixmnE mZxi67WQdZUbx/Y88kWi45Zap9vYhk2VutAySFAqs9VDn/WX/FnTtLqxqYmu lgLA5723v7Ordbv5PDTJ87mC3d7wLR9uY8eDoXg29FM+PETlhxlueWc8/l7t 74D7QKlbXHf+fBuG81da4hdUY5vXltqqPzr61g+AUl85e/DPgZ5m+XQIsrMD nzB6AMfh/fsH/8DaJ9hIS4bAftJohvlnuzkTkfmU0dmidyHdgPC6h7FT0INA umwbTMYctOwpM4z69YSecIB6ARrtN/UENCQ1aO/4JOp/C1KLuP7+kwi9Y7lP 27B8AowgKbmVxFPa+WvfyefO4H4bRoQfhrMr9cwuwJRCzPbtZDL5fnjsx+SJ OlfEs8877h1Q+zDBQTZBfrRT/QoPf8sfhmaWvCyTnf2O3ff9OnxQ8qEKL1Yg 9UqeRU0vp+mx/s7+x3klteaBTciaJm45HcH7u71le6KzkwnsFKIV39oMmpzs cCZenVFysTkyqbw50elARwCYrRq3dKpgMUKfeezK9r3Mwy4DNmIIW77UIAuu wxSDY05D2KiJf3AOXPWOFpGB1q8g8jKzDbaZYJtjI27Ah88gML7GC3P8HxzP 4B4ksxEaKkNFn7kt66DmHkRwxUapPw0jwfxyDOLcBi8XqTD30WBGnE4p3nL1 wzD7MlFn13guOpsyrcV84fwVDi1ddSUBNwFm31NDWV4V/frLh+QSHWPP/3ht KI+IWTMM1eopRc4CFJ81CJcsBP7EjEl7Y+UaCgaVqRpCCznlQWfEUlRKwHH6 iVahAFkoTM0KpcpuBUjED70mMXsO1Fkb1+h95LNpz1dSeA8Q+E/MCQcTrd9K 7WSF58HHS77hg9qxApradGxCGFgB2rjdISyZH1ySQnW49EMpXKI3/4i0ifcU gofsQ4YIupSjTFd0ZCArOgJsWL/RxQXUl3KDbWzt0nMZBxjzihklHQ9KXrJy mezjyW+/1e1c+c61BM08Q4X2M9Afjas9u6UqwEnRgnRuzER4UMmcxiNwWSTP rnbVQwgomWvX1NVKzqcXFNJh0RSvDygwa8DlLcw1od8Pb8lZ68bOpRkmnpsE Xz/uj7JloFpny+yw/sOeWz3Ej3ZZswBGj4MK0kClxqYTKc33MyOZHIruCqn/ eTpuktqxcv02UtyazjcsiG6aW0NddXQcK7a7xIAp5IoSgfvtfuqVrC7Hw+iM 5TyyGvUtCp9nHWTAJC4LzwwssAEdpbhl0eGPQMyJfp61MArNBpuWSDJ2cGVt kZQdA3OPGeH3+mxCh7xDayPg9omr+KaPdLMIzpbbFdQSKE7L1GKK6jS76wzT vYb0P7xLvVehix+j7JAWQyGWBthMyXL6Mgsx+aRo4huS3CCrVg1WzlUEHocU 3Sq6rvH9I36YfMN0JIzB07d8/LCOYXqoFKN8RM9BhCyc2U444OYqMPr9AFdt CxjyGsnX7eLFtjJeu7NlLL2dBVu504RQCxr3jcLkZcidcNpKhRwKgEJsQ6dF w+nEYPkoU4Kp+QpP3ZuK+Dg7nIGH2GzVYe9XP7vFuRA2DOKljMDKcuK1f/vJ Afsk6NSH5MYKYvkZmvmQySaY8QlmMdIVKJEuoXbccGxBvegrtGPBEMoZVNTY DflQ1oIV3lXlST3CeMZ0kLOTm0BCOmCUJ9KjURFG4yYqqgaKOKfjqGK38VKf /BxhZpkkydjPxurYE5UurLlHl9Wwwgw3IrT1GpYbJu9C3tHlLZLkjezEA7Pf +fGL4wHrDa94EKR7KfsYOe5DVMXhXEM/ew9ogJnKbkViibvuXa7AzU9ev7YL YLBmoxStTaU1WkAuVsKrXyh+aDAEoenQXS40Nd6OX4IHuxeugdm7bZU9mJSX Yc0sOZt4oqnqn3FFtzhkZIVAqZcvnZ4f3CZCgU5W4KWucaompaN3DISgqBJ4 8NE/jJ9SLh2jRGY2oX3Pcqu3kaKGSOG8447LMbbO+ZFTRDiRQkRsFsEn3Ff7 xcPsIK+ARwUOi7dyhZ+c3DRnopMfL7wL57sCavFuAMVBWb0Crecy05y9NlEv OVIaXHVCN2hdS5MmXwdmso6SIVDhWrfCAmAEO258bq5hdICMW2x5UQ5MuZVP J0TrF+i/hkPdXC4nbqUOZro1E/0g+BK4ZPy/8FFINozve8SE7ydPR2B64I+/ p6TAizyB8WuQ8t9+i3do0C11LHO5tIVDBekuo8DWl8wEriBedHK71d7f98LJ 3i0x09tihlf67KVS6IQ6eyUaHEe2zhdglyJxIIyfhGD/Mv81hPM5BWSDfLg4 WkQks+pBiwECDSCwqcgeEuWdlxu/xIBl1+Gw7HgqY08t3hiRsVGaP79+lhb4 Ru7DIH+0hyLCELrPWOjtKA7PRj/cutznlsOht+ig/CjIXVXP4MhBTHQP5ttT kVGIKqnFJF/0dr6QizAxazYFE4z26ilMVyOA6M+enZ5fvnx9pF89Ozu+ONOv z56//OVMXz7F/51f6IuzE7wJSqk73Nr7gLJpY3TsWHXssKx0uS2/dkaXuGIJ 3PEAirf42Qm4IClsAQyA1xmi6iz6vYP+vwPchwL3WYh7iHCzvivp5UKUbfB8 Bh/6/aFxOJx0HxQ3/J1guq/ylTYx4uIjqhN++BQ76vO7MnOA4wUwt7sufw7H /a8DHOKUPT8+uffRdix6+9R5PhUdOmqwO0/uvYP/4kE1U0I4R64yHsGXQp/w jJdpzsF0NeC6cTtZZBe0fKRj+RJlNJI/gib72RTd1d129ZXsSr9+fcL3UYPX SMYO/bF4da4EpOHr3eb+Msz9tmaeyIqqnEUMFypQuwORVbLQPQrG/NQOKZL3 hSf93QB7jICNpX1rJ5OrnhTsZqywKB9qYY2J7kjodSXQVgaWrLAxc8wXqYbo RIIRivm3arx328YXvI3XlvuSbZHCdr136/GUvTvN/YjnTprJ00H4JOmi8z+/ 5VKCzyPRPr8Vks8zsuFix+QU7Dzo0ut9lVY6udIEA+SP9L/eDZUP+xyBV45T F0CNXsK0Axz4P32B82Ozq6q+KW2xiEo8jZLQVuVqpJc557twdz0PRY7U1tCb 2WUX8/YuFdnNsoxuujJ9zGBDxFm6cGaMpPROeHvAeHteBxVBHQH9CwowGVOa /KqIO0x8GHgbtRH5JaGFgZjq7U+0Meyuwnhfn59dPtGHOOoOc9/nuc/5jlu8 Y5LSaHRBfggiSHj3swKGiU1CfWcLsQfgHYSVG7lT/q6rh/XAG3krgPxEgJyn vNSn+SfoG0nETg0lyKohgiQ80dGE3qbpthmOs6RLDdQVGKmY1/oWNvIDInVS N4vvJzlwgSQ8E7XS9R9KoQlrBKwjRXUQYJSu0d8u23btj+7du7m5OZyEde4h CKBA75Xks8/rewDF9xBYNLMlXUcuvg9N1MtgmvZI5XP2pxwbnuDejZ3ilPek pfYe/jsG7yfLdlV+LzeUJulXz7Hnb21rrB/RAb4o+yGSGbbf8Z2eNxBrUr8j XVNNL5rqSvVbYDGlcO2KzpThYB/eqxtXcHz5CIZVf9F/B/P5b656j/l5rZ92 5sbiFf0b+gl//WFJv9Gl+xSJ8bgX7qr2+rm5buqFM1VVrwEsOv7y2hZPDfqi 1cpc/9DYYmna4ejLeuogKv+prooGL/OHneAPkwX/8IP8F5HMw/qZr91Y4Axx 7wRHa/yV9JG21qz0ylKqinqBn2Mur6J/ncDjedHn9e8QbJsDheqyQSYBJnja udaujN6nsiH42S9nbb0GNYH/kgO++jdTGX2+wbatRu//VNeL0uLvp6ZytgTn aVnpn2DeFdBh//jk2Rt8+MrgHd5X+vkM+AAmy9c+h1Uvbmzb5rMBrFfYr4bB 5hL2sf/E+LbcyLn+4S5Thg2P7WEyg00Blg4NXm5IKSPyobYanvk6uJb8FBJ5 5QovNzsujV+iQndyyW52m3mqloz4vkfnV47b75Z2FbKvxIjKVVaul55J8BWv Fe/FijtaUPmCAkXuA91HLBc0hg3yxYCgjXwWhlMbspj/XrdmjFLDNRJqaqmL clCH4d0Wli/AaeR+P3Ciu8Ys5OK2WH0KXblZ/gjXoYzm8dCeq7e7ORn/IY8a vG/M7Y4Cp552ePn8MwMAnGGLXjtK/vlIvzWodvTP3QpoPtLqSYPupp8Z4Lay Xk3B8IxA7lb6lW2xTv23GjjzYtaBmwRLXFhgu8uuqfAL/XMmv2yqGa6HW39d g9S0+q0rW+wDTjplEDLkBRyUUROK/EE6b7EYyFMNMCbJHViuukD4vF0v9YXB U2EbTjL0oExQYBaOrxHyHV0CQkDPrS0wNJ+o/wG8zRidcWcAAA== --></rfc>