rfc9258.original.xml   rfc9258.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.4.14 --> <!DOCTYPE rfc [
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> <!ENTITY nbsp "&#160;">
<?rfc toc="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc sortrefs="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc symrefs="yes"?> <!ENTITY wj "&#8288;">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft ]>
-ietf-tls-external-psk-importer-08" category="std" obsoletes="" updates="" submi
ssionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
version="3"> -ietf-tls-external-psk-importer-08" number="9258" submissionType="IETF" category
<!-- xml2rfc v2v3 conversion 2.42.0 --> ="std" consensus="true" obsoletes="" updates="" xml:lang="en" tocInclude="true"
sortRefs="true" symRefs="true" version="3">
<front> <front>
<title abbrev="Importing External PSKs for TLS">Importing External PSKs for <title abbrev="Importing External PSKs for TLS 1.3">Importing External Pre-S
TLS</title> hared Keys (PSKs) for TLS 1.3</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-external-psk-importe <seriesInfo name="RFC" value="9258"/>
r-08"/>
<author initials="D." surname="Benjamin" fullname="David Benjamin"> <author initials="D." surname="Benjamin" fullname="David Benjamin">
<organization>Google, LLC.</organization> <organization>Google, LLC.</organization>
<address> <address>
<email>davidben@google.com</email> <email>davidben@google.com</email>
</address> </address>
</author> </author>
<author initials="C.A." surname="Wood" fullname="Christopher A. Wood"> <author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
<organization>Cloudflare</organization> <organization>Cloudflare</organization>
<address> <address>
<email>caw@heapingbits.net</email> <email>caw@heapingbits.net</email>
</address> </address>
</author> </author>
<date year="2022" month="April" day="22"/> <date year="2022" month="July"/>
<area>General</area>
<area>sec</area>
<workgroup>tls</workgroup> <workgroup>tls</workgroup>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<t>This document describes an interface for importing external Pre-Shared <t>This document describes an interface for importing external Pre-Shared
Keys (PSKs) Keys (PSKs) into TLS 1.3.</t>
into TLS 1.3.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>Discussion Venues</name>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/tlswg/draft-ietf-tls-external-psk-importer"/>
.</t>
</note>
</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>TLS 1.3 <xref target="RFC8446" format="default"/> supports Pre-Shared K ey (PSK) authentication, wherein PSKs <t>TLS 1.3 <xref target="RFC8446" format="default"/> supports Pre-Shared K ey (PSK) authentication, wherein PSKs
can be established via session tickets from prior connections or externally via some out-of-band can be established via session tickets from prior connections or via some extern al, out-of-band
mechanism. The protocol mandates that each PSK only be used with a single hash f unction. mechanism. The protocol mandates that each PSK only be used with a single hash f unction.
This was done to simplify protocol analysis. TLS 1.2 <xref target="RFC5246" form at="default"/>, in contrast, This was done to simplify protocol analysis. TLS 1.2 <xref target="RFC5246" form at="default"/>, in contrast,
has no such requirement, as a PSK may be used with any hash algorithm and the has no such requirement, as a PSK may be used with any hash algorithm and the
TLS 1.2 pseudorandom function (PRF). While there is no known way in which the sa me TLS 1.2 pseudorandom function (PRF). While there is no known way in which the sa me
external PSK might produce related output in TLS 1.3 and prior versions, only li mited external PSK might produce related output in TLS 1.3 and prior versions, only li mited
analysis has been done. Applications SHOULD provision separate PSKs for (D)TLS 1 analysis has been done. Applications <bcp14>SHOULD</bcp14> provision separate P
.3 and SKs for (D)TLS 1.3 and
prior versions. In cases where this is not possible, e.g., there are already dep prior versions. In cases where this is not possible (e.g., there are already-dep
loyed loyed
external PSKs or provisioning is otherwise limited, re-using external PSKs acros external PSKs or provisioning is otherwise limited), reusing external PSKs acros
s different s different
versions of TLS may produce related outputs, which may in turn lead to security versions of TLS may produce related outputs, which may, in turn, lead to securit
problems; y problems;
see <xref target="RFC8446" format="default"/>, Section E.7.</t> see <xref target="RFC8446" sectionFormat="of" section="E.7"/>.</t>
<t>To mitigate against such problems, this document specifies a PSK Import <t>To mitigate such problems, this document specifies a PSK importer
er
interface by which external PSKs may be imported and subsequently bound to a spe cific interface by which external PSKs may be imported and subsequently bound to a spe cific
key derivation function (KDF) and hash function for use in TLS 1.3 <xref target= "RFC8446" format="default"/> key derivation function (KDF) and hash function for use in TLS 1.3 <xref target= "RFC8446" format="default"/>
and DTLS 1.3 <xref target="DTLS13" format="default"/>. In particular, it describ es a and DTLS 1.3 <xref target="RFC9147" format="default"/>. In particular, it descri bes a
mechanism for importing PSKs derived from external PSKs by including the target KDF, mechanism for importing PSKs derived from external PSKs by including the target KDF,
(D)TLS protocol version, and an optional context string to ensure uniqueness. Th is process yields a set of candidate (D)TLS protocol version, and an optional context string to ensure uniqueness. Th is process yields a set of candidate
PSKs, each of which are bound to a target KDF and protocol, that are separate fr om those PSKs, each of which are bound to a target KDF and protocol, that are separate fr om those
used in (D)TLS 1.2 and prior versions. This expands what would normally have bee n a single used in (D)TLS 1.2 and prior versions. This expands what would normally have bee n a single
PSK and identity into a set of PSKs and identities.</t> PSK and identity into a set of PSKs and identities.</t>
</section> </section>
<section anchor="conventions-and-definitions" numbered="true" toc="default"> <section anchor="conventions-and-definitions" numbered="true" toc="default">
<name>Conventions and Definitions</name> <name>Conventions and Definitions</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SH <t>
OULD", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
document are to be interpreted as described in BCP 14 <xref target="RFC2119" for NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
mat="default"/> <xref target="RFC8174" format="default"/> 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>
</section> </section>
<section anchor="terminology" numbered="true" toc="default"> <section anchor="terminology" numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<t>The following terms are used throughout this document:</t> <t>The following terms are used throughout this document:</t>
<ul spacing="normal"> <dl newline="false" spacing="normal">
<li>External PSK (EPSK): A PSK established or provisioned out-of-band (i <dt>External PSK (EPSK):</dt>
.e., not <dd>A PSK established or provisioned out of band (i.e., not
from a TLS connection) which is a tuple of (Base Key, External Identity, Hash).< from a TLS connection) that is a tuple of (Base Key, External Identity, Hash).</
/li> dd>
<li>Base Key: The secret value of an EPSK.</li> <dt>Base Key:</dt>
<li>External Identity: A sequence of bytes used to identify an EPSK.</li <dd>The secret value of an EPSK.</dd>
> <dt>External Identity:</dt>
<li>Target protocol: The protocol for which a PSK is imported for use.</ <dd>A sequence of bytes used to identify an EPSK.</dd>
li> <dt>Target protocol:</dt>
<li>Target KDF: The KDF for which a PSK is imported for use.</li> <dd>The protocol for which a PSK is imported for use.</dd>
<li>Imported PSK (IPSK): A TLS PSK derived from an EPSK, optional contex <dt>Target KDF:</dt>
t string, <dd>The KDF for which a PSK is imported for use.</dd>
target protocol, and target KDF.</li> <dt>Imported PSK (IPSK):</dt>
<li>Non-imported PSK: An EPSK which used directly as a TLS PSK without b <dd>A TLS PSK derived from an EPSK, optional context string,
eing imported.</li> target protocol, and target KDF.</dd>
<li>Imported Identity: A sequence of bytes used to identify an IPSK.</li <dt>Non-imported PSK:</dt>
> <dd>An EPSK that is used directly as a TLS PSK without being imported.</d
</ul> d>
<t>This document uses presentation language from <xref target="RFC8446" fo <dt>Imported Identity:</dt>
rmat="default"/>, Section 3.</t> <dd>A sequence of bytes used to identify an IPSK.</dd>
</dl>
<t>This document uses presentation language from <xref target="RFC8446" se
ctionFormat="of" section="3"/>.</t>
</section> </section>
<section anchor="overview" numbered="true" toc="default"> <section anchor="overview" numbered="true" toc="default">
<name>Overview</name> <name>Overview</name>
<t>The PSK Importer interface mirrors that of the TLS Exporters interface <t>The PSK importer interface mirrors that of the TLS exporter interface (
(see <xref target="RFC8446" format="default"/>) see <xref target="RFC8446" format="default"/>)
in that it diversifies a key based on some contextual information. In contrast t in that it diversifies a key based on some contextual information. In contrast t
o the Exporters o the exporter
interface, wherein output uniqueness is achieved via an explicit label and conte xt string, interface, wherein output uniqueness is achieved via an explicit label and conte xt string,
the PSK Importer interface defined herein takes an external PSK and identity and "imports" it into the PSK importer interface defined herein takes an external PSK and identity and "imports" it into
TLS, creating a set of "derived" PSKs and identities that are each unique. Each of these TLS, creating a set of "derived" PSKs and identities that are each unique. Each of these
derived PSKs are bound to a target protocol, KDF identifier, and optional contex t string. derived PSKs are bound to a target protocol, KDF identifier, and optional contex t string.
Additionally, the resulting PSK binder keys are modified with a new derivation l abel Additionally, the resulting PSK binder keys are modified with a new derivation l abel
to prevent confusion with non-imported PSKs. Through this interface, importing e xternal to prevent confusion with non-imported PSKs. Through this interface, importing e xternal
PSKs with different identities yields distinct PSK binder keys.</t> PSKs with different identities yields distinct PSK binder keys.</t>
<t>Imported keys do not require negotiation for use since a client and ser ver will not agree upon <t>Imported keys do not require negotiation for use since a client and ser ver will not agree upon
identities if imported incorrectly. Endpoints may incrementally deploy PSK Impor identities if imported incorrectly. Endpoints may incrementally deploy PSK impor
ter support ter support
by offering non-imported PSKs for TLS versions prior to TLS 1.3. Non-imported an by offering non-imported PSKs for TLS versions prior to TLS 1.3.
d imported PSKs Non-imported and imported PSKs
are distinct since their identities are different. See <xref target="rollout" fo are not equivalent since their identities are different. See <xref target="rollo
rmat="default"/> for more details.</t> ut" format="default"/> for more details.</t>
<t>Endpoints which import external keys MUST NOT use the keys that are inp <t>Endpoints that import external keys <bcp14>MUST NOT</bcp14> use the key
ut to the s that are input to the
import process for any purpose other than the importer, and MUST NOT use the der import process for any purpose other than the importer, and they <bcp14>MUST NOT
ived </bcp14> use the derived
keys for any purpose other than TLS PSKs. Moreover, each external PSK fed to the keys for any purpose other than TLS PSKs. Moreover, each external PSK fed to the
importer process MUST be associated with at most one hash function. This importer process <bcp14>MUST</bcp14> be associated with one hash function at mos
is analogous to the rules in Section 4.2.11 of <xref target="RFC8446" format="de t. This
fault"/>. See <xref target="security-considerations" format="default"/> for is analogous to the rules in <xref target="RFC8446" sectionFormat="of" section="
4.2.11"/>. See <xref target="security-considerations" format="default"/> for
more discussion.</t> more discussion.</t>
</section> </section>
<section anchor="psk-import" numbered="true" toc="default"> <section anchor="psk-import" numbered="true" toc="default">
<name>PSK Import</name> <name>PSK Importer</name>
<t>This section describes the PSK Importer interface and its underlying di <t>This section describes the PSK importer interface and its underlying di
versification versification
mechanism and binder key computation modification.</t> mechanism and binder key computation modification.</t>
<section anchor="external-psk-diversification" numbered="true" toc="defaul t"> <section anchor="external-psk-diversification" numbered="true" toc="defaul t">
<name>External PSK Diversification</name> <name>External PSK Diversification</name>
<t>The PSK Importer interface takes as input an EPSK with External Ident
ity <tt>external_identity</tt> and base key <tt>epsk</tt>, <t>As input, the PSK importer interface takes an EPSK with External Iden
as defined in <xref target="terminology" format="default"/>, along with an optio tity <tt>external_identity</tt> and base key <tt>epsk</tt>
nal context, and transforms it into a set of PSKs (as defined in <xref target="terminology" format="default"/>) along with an opti
onal context. It then transforms the input into a set of PSKs
and imported identities for use in a connection based on target protocols and KD Fs. and imported identities for use in a connection based on target protocols and KD Fs.
In particular, for each supported target protocol <tt>target_protocol</tt> and K DF <tt>target_kdf</tt>, In particular, for each supported target protocol <tt>target_protocol</tt> and K DF <tt>target_kdf</tt>,
the importer constructs an ImportedIdentity structure as follows:</t> the importer constructs an ImportedIdentity structure as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<sourcecode name="" type="">
struct { struct {
opaque external_identity<1...2^16-1>; opaque external_identity&lt;1...2^16-1&gt;;
opaque context<0..2^16-1>; opaque context&lt;0..2^16-1&gt;;
uint16 target_protocol; uint16 target_protocol;
uint16 target_kdf; uint16 target_kdf;
} ImportedIdentity; } ImportedIdentity;
]]></artwork> </sourcecode>
<t>The list of ImportedIdentity.target_kdf values is maintained by IANA as described in <xref target="IANA" format="default"/>. <t>The list of ImportedIdentity.target_kdf values is maintained by IANA as described in <xref target="IANA" format="default"/>.
External PSKs MUST NOT be imported for (D)TLS 1.2 or prior versions. See <xref t arget="rollout" format="default"/> for External PSKs <bcp14>MUST NOT</bcp14> be imported for (D)TLS 1.2 or prior versio ns. See <xref target="rollout" format="default"/> for
discussion on how imported PSKs for TLS 1.3 and non-imported PSKs for earlier ve rsions discussion on how imported PSKs for TLS 1.3 and non-imported PSKs for earlier ve rsions
co-exist for incremental deployment.</t> coexist for incremental deployment.</t>
<t>ImportedIdentity.context MUST include the context used to determine t <t>ImportedIdentity.context <bcp14>MUST</bcp14> include the context used
he EPSK, if any exists. to determine the EPSK, if any exists.
For example, ImportedIdentity.context may include information about peer roles o r identities For example, ImportedIdentity.context may include information about peer roles o r identities
to mitigate Selfie-style reflection attacks <xref target="Selfie" format="defaul t"/>. See <xref target="mitigate-selfie" format="default"/> for more details. to mitigate Selfie-style reflection attacks <xref target="Selfie" format="defaul t"/>. See <xref target="mitigate-selfie" format="default"/> for more details.
Since the EPSK is a key derived from an external protocol or sequence of protoco ls, Since the EPSK is a key derived from an external protocol or sequence of protoco ls,
ImportedIdentity.context MUST include a channel binding for the deriving protoco ls ImportedIdentity.context <bcp14>MUST</bcp14> include a channel binding for the d eriving protocols
<xref target="RFC5056" format="default"/>. The details of this binding are proto col specific and out of scope for <xref target="RFC5056" format="default"/>. The details of this binding are proto col specific and out of scope for
this document.</t> this document.</t>
<t>ImportedIdentity.target_protocol MUST be the (D)TLS protocol version for which the <t>ImportedIdentity.target_protocol <bcp14>MUST</bcp14> be the (D)TLS pr otocol version for which the
PSK is being imported. For example, TLS 1.3 <xref target="RFC8446" format="defau lt"/> uses 0x0304, which will PSK is being imported. For example, TLS 1.3 <xref target="RFC8446" format="defau lt"/> uses 0x0304, which will
therefore also be used by QUICv1 <xref target="QUIC" format="default"/>. Note th at this means the number therefore also be used by QUICv1 <xref target="RFC9000" format="default"/>. Note that this means the number
of PSKs derived from an EPSK is a function of the number of target protocols.</t > of PSKs derived from an EPSK is a function of the number of target protocols.</t >
<t>Given an ImportedIdentity and corresponding EPSK with base key <tt>ep sk</tt>, an Imported PSK <t>Given an ImportedIdentity and corresponding EPSK with base key <tt>ep sk</tt>, an imported PSK
IPSK with base key <tt>ipskx</tt> is computed as follows:</t> IPSK with base key <tt>ipskx</tt> is computed as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
epskx = HKDF-Extract(0, epsk) epskx = HKDF-Extract(0, epsk)
ipskx = HKDF-Expand-Label(epskx, "derived psk", ipskx = HKDF-Expand-Label(epskx, "derived psk",
Hash(ImportedIdentity), L) Hash(ImportedIdentity), L)
]]></artwork> ]]></artwork>
<t>L corresponds to the KDF output length of ImportedIdentity.target_kdf as defined in <xref target="IANA" format="default"/>. <t>L corresponds to the KDF output length of ImportedIdentity.target_kdf as defined in <xref target="IANA" format="default"/>.
For hash-based KDFs, such as HKDF_SHA256(0x0001), this is the length of the hash function For hash-based KDFs, such as HKDF_SHA256 (0x0001), this is the length of the has h function
output, e.g., 32 octets for SHA256. This is required for the IPSK to be of lengt h suitable output, e.g., 32 octets for SHA256. This is required for the IPSK to be of lengt h suitable
for supported ciphersuites. Internally, HKDF-Expand-Label uses a label correspon ding to for supported ciphersuites. Internally, HKDF-Expand-Label uses a label correspon ding to
ImportedIdentity.target_protocol, e.g., "tls13" for TLS 1.3, as per <xref target ImportedIdentity.target_protocol (e.g., "tls13" for TLS 1.3, as per <xref target
="RFC8446" format="default"/>, Section 7.1, ="RFC8446" sectionFormat="of" section="7.1"/>
or "dtls13" for DTLS 1.3, as per <xref target="I-D.ietf-tls-dtls13" format="defa or "dtls13" for DTLS 1.3, as per <xref target="RFC9147" sectionFormat="of" secti
ult"/>, Section 5.10.</t> on="5.10"/>).</t>
<t>The identity of <tt>ipskx</tt> as sent on the wire is ImportedIdentit y, i.e., the serialized content <t>The identity of <tt>ipskx</tt> as sent on the wire is ImportedIdentit y, i.e., the serialized content
of ImportedIdentity is used as the content of PskIdentity.identity in the PSK ex tension. of ImportedIdentity is used as the content of PskIdentity.identity in the PSK ex tension.
The corresponding PSK input for the TLS 1.3 key schedule is 'ipskx'.</t> The corresponding PSK input for the TLS 1.3 key schedule is "ipskx".</t>
<t>As the maximum size of the PSK extension is 2^16 - 1 octets, an Impor <t>As the maximum size of the PSK extension is 2<sup>16</sup> - 1 octets
ted Identity that exceeds , an Imported Identity that exceeds
this size is likely to cause a decoding error. Therefore, the PSK Importer inter this size is likely to cause a decoding error. Therefore, the PSK importer inter
face SHOULD reject face <bcp14>SHOULD</bcp14> reject
any ImportedIdentity that exceeds this size.</t> any ImportedIdentity that exceeds this size.</t>
<t>The hash function used for HKDF <xref target="RFC5869" format="defaul t"/> is that which is associated with the EPSK. <t>The hash function used for HMAC-based Key Derivation Function (HKDF) <xref target="RFC5869" format="default"/> is that which is associated with the E PSK.
It is not the hash function associated with ImportedIdentity.target_kdf. If the EPSK It is not the hash function associated with ImportedIdentity.target_kdf. If the EPSK
does not have such an associated hash function, SHA-256 <xref target="SHA2" form at="default"/> SHOULD be used. does not have such an associated hash function, SHA-256 <xref target="SHA2" form at="default"/> <bcp14>SHOULD</bcp14> be used.
Diversifying EPSK by ImportedIdentity.target_kdf ensures Diversifying EPSK by ImportedIdentity.target_kdf ensures
that an IPSK is only used as input keying material to at most one KDF, thus sati sfying that an IPSK is only used as input keying material to one KDF at most, thus sati sfying
the requirements in <xref target="RFC8446" format="default"/>. See <xref target= "security-considerations" format="default"/> for more details.</t> the requirements in <xref target="RFC8446" format="default"/>. See <xref target= "security-considerations" format="default"/> for more details.</t>
<t>Endpoints SHOULD generate a compatible <tt>ipskx</tt> for each target ciphersuite they offer. <t>Endpoints <bcp14>SHOULD</bcp14> generate a compatible <tt>ipskx</tt> for each target ciphersuite they offer.
For example, importing a key for TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA3 84 would For example, importing a key for TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA3 84 would
yield two PSKs, one for HKDF-SHA256 and another for HKDF-SHA384. In contrast, if yield two PSKs: one for HKDF-SHA256 and another for HKDF-SHA384. In contrast, if
TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 are supported, only one TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 are supported, only one
derived key is necessary. Each ciphersuite uniquely identifies the target KDF. derived key is necessary. Each ciphersuite uniquely identifies the target KDF.
Future specifications that change the way the KDF is negotiated will need to upd ate this Future specifications that change the way the KDF is negotiated will need to upd ate this
specification to make clear how target KDFs are determined for the import proces s.</t> specification to make clear how target KDFs are determined for the import proces s.</t>
<t>EPSKs MAY be imported before the start of a connection if the target <t>EPSKs <bcp14>MAY</bcp14> be imported before the start of a connection
KDFs, protocols, and if the target KDFs, protocols, and
context string(s) are known a priori. EPSKs MAY also be imported for early data context string(s) are known a priori. EPSKs <bcp14>MAY</bcp14> also be imported
use for early data use
if they are bound to the protocol settings and configuration that are required f or if they are bound to the protocol settings and configuration that are required f or
sending early data. Minimally, this means that the Application-Layer Protocol Ne gotiation value sending early data. Minimally, this means that the Application-Layer Protocol Ne gotiation (ALPN) value
<xref target="RFC7301" format="default"/>, QUIC transport parameters (if used fo r QUIC), and any other relevant <xref target="RFC7301" format="default"/>, QUIC transport parameters (if used fo r QUIC), and any other relevant
parameters that are negotiated for early data MUST be provisioned alongside thes e EPSKs.</t> parameters that are negotiated for early data <bcp14>MUST</bcp14> be provisioned alongside these EPSKs.</t>
</section> </section>
<section anchor="schedule" numbered="true" toc="default"> <section anchor="schedule" numbered="true" toc="default">
<name>Binder Key Derivation</name> <name>Binder Key Derivation</name>
<t>To prevent confusion between imported and non-imported PSKs, imported PSKs change <t>To prevent confusion between imported and non-imported PSKs, imported PSKs change
the PSK binder key derivation label. In particular, the standard TLS 1.3 PSK bin der the PSK binder key derivation label. In particular, the standard TLS 1.3 PSK bin der
key computation is defined as follows:</t> key computation is defined as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 0
| |
v v
skipping to change at line 222 skipping to change at line 233
]]></artwork> ]]></artwork>
<t>This new label ensures a client and server will negotiate use of an e xternal PSK if <t>This new label ensures a client and server will negotiate use of an e xternal PSK if
and only if (a) both endpoints import the PSK or (b) neither endpoint imports th e and only if (a) both endpoints import the PSK or (b) neither endpoint imports th e
PSK. As <tt>binder_key</tt> is a leaf key, changing its computation does not aff ect any PSK. As <tt>binder_key</tt> is a leaf key, changing its computation does not aff ect any
other key.</t> other key.</t>
</section> </section>
</section> </section>
<section anchor="deprecating-hash-functions" numbered="true" toc="default"> <section anchor="deprecating-hash-functions" numbered="true" toc="default">
<name>Deprecating Hash Functions</name> <name>Deprecating Hash Functions</name>
<t>If a client or server wishes to deprecate a hash function and no longer use it for TLS 1.3, <t>If a client or server wishes to deprecate a hash function and no longer use it for TLS 1.3,
they remove the corresponding KDF from the set of target KDFs used for importing it removes the corresponding KDF from the set of target KDFs used for importing
keys. keys.
This does not affect the KDF operation used to derive Imported PSKs.</t> This does not affect the KDF operation used to derive imported PSKs.</t>
</section> </section>
<section anchor="rollout" numbered="true" toc="default"> <section anchor="rollout" numbered="true" toc="default">
<name>Incremental Deployment</name> <name>Incremental Deployment</name>
<t>In deployments that already have PSKs provisioned and in use with TLS 1 .2, attempting <t>In deployments that already have PSKs provisioned and in use with TLS 1 .2, attempting
to incrementally deploy the importer mechanism would then result in concurrent u to incrementally deploy the importer mechanism would result in concurrent use of
se of the already-provisioned PSK directly as both a TLS 1.2 PSK and an EPSK, which, i
the already provisioned PSK both directly as a TLS 1.2 PSK and as an EPSK, which n turn, could mean that the same KDF and key would be used in two different prot
in ocol contexts.
turn could mean that the same KDF and key would be used in two different protoco
l contexts.
This is not a recommended configuration; see <xref target="security-consideratio ns" format="default"/> for more details. This is not a recommended configuration; see <xref target="security-consideratio ns" format="default"/> for more details.
However, the benefits of using TLS 1.3 and of using PSK importers may prove suff iciently However, the benefits of using TLS 1.3 and PSK importers may prove sufficiently
compelling that existing deployments choose to enable this noncompliant configur ation for compelling that existing deployments choose to enable this noncompliant configur ation for
a brief transition period while new software (using TLS 1.3 and importers) is de ployed. a brief transition period while new software (using TLS 1.3 and importers) is de ployed.
Operators are advised to make any such transition period as short as possible.</ t> Operators are advised to make any such transition period as short as possible.</ 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>The PSK Importer security goals can be roughly stated as follows: avoid <t>The PSK importer security goals can be roughly stated as follows: avoid
PSK re-use across PSK reuse across
KDFs while properly authenticating endpoints. When modeled as computational extr KDFs while properly authenticating endpoints. When modeled as computationa
actors, KDFs l extractors, KDFs
assume that input keying material (IKM) is sampled from some "source" probabilit y distribution assume that input keying material (IKM) is sampled from some "source" probabilit y distribution
and that any two IKM values are chosen independently of each other <xref target= and that any two IKM values are chosen independently of each other <xref target=
"Kraw10" format="default"/>. This "Kraw10" format="default"/>. This source-independence requirement implies that t
source-independence requirement implies that the same IKM value cannot be used f he same IKM value cannot be used for two different
or two different
KDFs.</t> KDFs.</t>
<t>PSK-based authentication is functionally equivalent to session resumpti on in that a connection <t>PSK-based authentication is functionally equivalent to session resumpti on in that a connection
uses existing key material to authenticate both endpoints. Following the work of uses existing key material to authenticate both endpoints. Following the work of
<xref target="BAA15" format="default"/>, this is a form of compound authenticati on. Loosely <xref target="BAA15" format="default"/>, this is a form of compound authenticati on. Loosely
speaking, compound authentication is the property that an execution of multiple authentication speaking, compound authentication is the property that an execution of multiple authentication
protocols, wherein at least one is uncompromised, jointly authenticates all prot protocols, wherein at least one is uncompromised, jointly authenticates all prot
ocols. ocols. Therefore, authenticating with an externally provisioned PSK should ideal
Authenticating with an externally provisioned PSK, therefore, should ideally aut ly authenticate both
henticate both the TLS connection and the external provisioning process. Typically, the externa
the TLS connection and the external provisioning process. Typically, the externa l provisioning process
l provision process
produces a PSK and corresponding context from which the PSK was derived and in w hich it should produces a PSK and corresponding context from which the PSK was derived and in w hich it should
be used. If available, this is used as the ImportedIdentity.context value. We re fer to an be used. If available, this is used as the ImportedIdentity.context value. We re fer to an
external PSK without such context as "context-free".</t> external PSK without such context as "context-free".</t>
<t>Thus, in considering the source-independence and compound authenticatio n requirements, the PSK <t>Thus, in considering the source-independence and compound authenticatio n requirements, the PSK
Import interface described in this document aims to achieve the following goals: </t> importer interface described in this document aims to achieve the following goal s:</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>Externally provisioned PSKs imported into a TLS connection achieve c ompound authentication <li>Externally provisioned PSKs imported into a TLS connection achieve c ompound authentication
of the provisioning process and connection.</li> of the provisioning process and connection.</li>
<li>Context-free PSKs only achieve authentication within the context of a single connection.</li> <li>Context-free PSKs only achieve authentication within the context of a single connection.</li>
<li>Imported PSKs are not used as IKM for two different KDFs.</li> <li>Imported PSKs are not used as IKM for two different KDFs.</li>
<li>Imported PSKs do not collide with future protocol versions and KDFs. </li> <li>Imported PSKs do not collide with future protocol versions and KDFs. </li>
</ol> </ol>
<t>There are no known related outputs or security issues caused from the p rocess <t>There are no known related outputs or security issues caused from the p rocess
for computing Imported PSKs from an external PSK and the processing of existing for computing imported PSKs from an external PSK and the processing of existing
external PSKs used in (D)TLS 1.2 and below, as noted in <xref target="rollout" f ormat="default"/>. However, external PSKs used in (D)TLS 1.2 and below, as noted in <xref target="rollout" f ormat="default"/>. However,
only limited analysis has been done, which is an additional reason why applicati ons only limited analysis has been done, which is an additional reason why applicati ons
SHOULD provision separate PSKs for (D)TLS 1.3 and prior versions, even when the <bcp14>SHOULD</bcp14> provision separate PSKs for (D)TLS 1.3 and prior versions, even when the
importer interface is used in (D)TLS 1.3.</t> importer interface is used in (D)TLS 1.3.</t>
<t>The PSK Importer does not prevent applications from constructing non-im porter PSK identities <t>The PSK importer does not prevent applications from constructing non-im porter PSK identities
that collide with imported PSK identities.</t> that collide with imported PSK identities.</t>
</section> </section>
<section anchor="privacy-considerations" numbered="true" toc="default"> <section anchor="privacy-considerations" numbered="true" toc="default">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t>External PSK identities are commonly static by design so that endpoints may use them to <t>External PSK identities are commonly static by design so that endpoints may use them to
lookup keying material. As a result, for some systems and use cases, this identi ty look up keying material. As a result, for some systems and use cases, this ident ity
may become a persistent tracking identifier.</t> may become a persistent tracking identifier.</t>
<t>Note also that ImportedIdentity.context is visible in cleartext on the wire as part of <t>Note also that ImportedIdentity.context is visible in cleartext on the wire as part of
the PSK identity. Unless otherwise protected by a mechanism such as TLS Encrypte d the PSK identity. Unless otherwise protected by a mechanism such as TLS Encrypte d
ClientHello <xref target="ECH" format="default"/>, applications SHOULD NOT put s ensitive information ClientHello <xref target="I-D.ietf-tls-esni" format="default"/>, applications <b cp14>SHOULD NOT</bcp14> put sensitive information
in this field.</t> in this field.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default"> <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This specification introduces a new registry for TLS KDF identifiers, t <t>IANA has created the "TLS KDF Identifiers" registry under the existing
itled "Transport Layer Security (TLS) Parameters" registry.</t>
"TLS KDF Identifiers", under the existing "Transport Layer Security (TLS) Parame <t>The entries in the registry are as follows:</t>
ters" heading.</t>
<t>The entries in the registry are:</t>
<table anchor="kdf-registry" align="center"> <table anchor="kdf-registry" align="center">
<name>Target KDF Registry</name> <name>TLS KDF Identifiers Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">KDF Description</th>
<th align="left">Value</th> <th align="left">Value</th>
<th align="left">KDF Description</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td>
<td align="left">0x0000</td> <td align="left">0x0000</td>
<td align="left">N/A</td> <td align="left">Reserved</td>
<td align="left">RFC 9258</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0001</td>
<td align="left">HKDF_SHA256</td> <td align="left">HKDF_SHA256</td>
<td align="left">0x0001</td> <td align="left"><xref target="RFC5869" format="default"/></td>
<td align="left">
<xref target="RFC5869" format="default"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">HKDF_SHA384</td>
<td align="left">0x0002</td> <td align="left">0x0002</td>
<td align="left"> <td align="left">HKDF_SHA384</td>
<xref target="RFC5869" format="default"/></td> <td align="left"><xref target="RFC5869" format="default"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>New target KDF values are allocated according to the following process: </t> <t>New target KDF values are allocated according to the following process: </t>
<ul spacing="normal"> <ul spacing="normal">
<li>Values in the range 0x0000-0xfeff are assigned via Specification Req uired <xref target="RFC8126" format="default"/>.</li> <li>Values in the range 0x0000-0xfeff are assigned via Specification Req uired <xref target="RFC8126" format="default"/>.</li>
<li>Values in the range 0xff00-0xffff are reserved for Private Use <xref target="RFC8126" format="default"/>.</li> <li>Values in the range 0xff00-0xffff are reserved for Private Use <xref target="RFC8126" format="default"/>.</li>
</ul> </ul>
<t>The procedures for requesting values in the Specification Required spac e are specified in Section 17 of <xref target="RFC8447" format="default"/>.</t> <t>The procedures for requesting values in the Specification Required spac e are specified in <xref target="RFC8447" sectionFormat="of" section="17"/>.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-tls-esni" to="ECH"/>
<displayreference target="RFC9000" to="QUIC"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="BCP" value="14"/>
<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 sig
nify the requirements in the specification. These words are often capitalized.
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>
</reference>
<reference anchor="RFC8447" target="https://www.rfc-editor.org/info/rfc8
447">
<front>
<title>IANA Registry Updates for TLS and DTLS</title>
<seriesInfo name="DOI" value="10.17487/RFC8447"/>
<seriesInfo name="RFC" value="8447"/>
<author fullname="J. Salowey" initials="J." surname="Salowey">
<organization/>
</author>
<author fullname="S. Turner" initials="S." surname="Turner">
<organization/>
</author>
<date month="August" year="2018"/>
<abstract>
<t>This document describes a number of changes to TLS and DTLS IAN
A registries that range from adding notes to the registry all the way to changin
g the registration policy. These changes were mostly motivated by WG review of
the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 developme
nt process.</t>
<t>This document updates the following RFCs: 3749, 5077, 4680, 524
6, 5705, 5878, 6520, and 7301.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8
446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
<seriesInfo name="RFC" value="8446"/>
<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 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>
</reference>
<reference anchor="DTLS13" target="https://www.ietf.org/archive/id/draft
-ietf-tls-dtls13-43.txt">
<front>
<title>The Datagram Transport Layer Security (DTLS) Protocol Version
1.3</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-dtls13-43"/>
<author fullname="Eric Rescorla">
<organization>RTFM, Inc.</organization>
</author>
<author fullname="Hannes Tschofenig">
<organization>Arm Limited</organization>
</author>
<author fullname="Nagendra Modadugu">
<organization>Google, Inc.</organization>
</author>
<date day="30" month="April" year="2021"/>
<abstract>
<t>This document specifies version 1.3 of the Datagram Transport L
ayer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to com
municate over the Internet in a way that is designed to prevent eavesdropping, t
ampering, and message forgery.
The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protoc <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
ol and provides equivalent security guarantees with the exception of order prote xml"/>
ction / non-replayability. Datagram semantics of the underlying transport are pr <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8447.
eserved by the DTLS protocol. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.
xml"/>
<!-- [I-D.ietf-tls-dtls13] Published as RFC 9147. -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9147.
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.5056.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5869.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.
xml"/>
This document obsoletes RFC 6347.
</t>
</abstract>
</front>
</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>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="BCP" value="14"/>
<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 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>
</reference>
<reference anchor="RFC5056" target="https://www.rfc-editor.org/info/rfc5
056">
<front>
<title>On the Use of Channel Bindings to Secure Channels</title>
<seriesInfo name="DOI" value="10.17487/RFC5056"/>
<seriesInfo name="RFC" value="5056"/>
<author fullname="N. Williams" initials="N." surname="Williams">
<organization/>
</author>
<date month="November" year="2007"/>
<abstract>
<t>The concept of channel binding allows applications to establish
that the two end-points of a secure channel at one network layer are the same a
s at a higher layer by binding authentication at the higher layer to the channel
at the lower layer. This allows applications to delegate session protection to
lower layers, which has various performance benefits.</t>
<t>This document discusses and formalizes the concept of channel b
inding to secure channels. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5869" target="https://www.rfc-editor.org/info/rfc5
869">
<front>
<title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)<
/title>
<seriesInfo name="DOI" value="10.17487/RFC5869"/>
<seriesInfo name="RFC" value="5869"/>
<author fullname="H. Krawczyk" initials="H." surname="Krawczyk">
<organization/>
</author>
<author fullname="P. Eronen" initials="P." surname="Eronen">
<organization/>
</author>
<date month="May" year="2010"/>
<abstract>
<t>This document specifies a simple Hashed Message Authentication
Code (HMAC)-based key derivation function (HKDF), which can be used as a buildin
g block in various protocols and applications. The key derivation function (KDF
) is intended to support a wide range of applications and requirements, and is c
onservative in its use of cryptographic hash functions. This document is not an
Internet Standards Track specification; it is published for informational pur
poses.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8
126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="BCP" value="26"/>
<author fullname="M. Cotton" initials="M." surname="Cotton">
<organization/>
</author>
<author fullname="B. Leiba" initials="B." surname="Leiba">
<organization/>
</author>
<author fullname="T. Narten" initials="T." surname="Narten">
<organization/>
</author>
<date month="June" year="2017"/>
<abstract>
<t>Many protocols make use of points of extensibility that use con
stants to identify various protocol parameters. To ensure that the values in th
ese fields do not have conflicting uses and to promote interoperability, their a
llocations are often coordinated by a central record keeper. For IETF protocols
, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance des
cribing the conditions under which new values should be assigned, as well as whe
n and how modifications to existing values can be made, is needed. This documen
t defines a framework for the documentation of these guidelines by specification
authors, in order to assure that the provided guidance for the IANA Considerati
ons is clear and addresses the various issues that are likely in the operation o
f a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 52
26.</t>
</abstract>
</front>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="SHA2">
<front> <reference anchor="SHA2" target="https://doi.org/10.6028/NIST.FIPS.180-4">
<title>Secure Hash Standard</title> <front>
<seriesInfo name="FIPS PUB 180-3" value=""/> <title>Secure Hash Standard (SHS)</title>
<author> <author>
<organization>National Institute of Standards and Technology</orga <organization showOnFrontPage="true">National Institute of Standards
nization> and Technology</organization>
</author> </author>
<date year="2008" month="October"/> <date year="2015" month="August"/>
</front> </front>
</reference> <seriesInfo name="FIPS PUB" value="180-4"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
</reference>
<reference anchor="Selfie" target="https://eprint.iacr.org/2019/347.pdf" > <reference anchor="Selfie" target="https://eprint.iacr.org/2019/347.pdf" >
<front> <front>
<title>Selfie: reflections on TLS 1.3 with PSK</title> <title>Selfie: reflections on TLS 1.3 with PSK</title>
<author initials="N." surname="Drucker" fullname="Nir Drucker"> <author initials="N" surname="Drucker" fullname="Nir Drucker">
<organization/> <organization />
</author> </author>
<author initials="S." surname="Gueron" fullname="Shay Gueron"> <author initials="S" surname="Gueron" fullname="Shay Gueron">
<organization/> <organization />
</author> </author>
<date year="2019"/> <date month="May" year="2021"/>
</front> </front>
<seriesInfo name="DOI" value="10.1007/s00145-021-09387-y"/>
</reference> </reference>
<reference anchor="Kraw10" target="https://eprint.iacr.org/2010/264"> <reference anchor="Kraw10" target="https://eprint.iacr.org/2010/264">
<front> <front>
<title>Cryptographic Extraction and Key Derivation: The HKDF Scheme< /title> <title>Cryptographic Extraction and Key Derivation: The HKDF Scheme< /title>
<seriesInfo name="Proceedings of CRYPTO 2010" value=""/> <author initials="H" surname="Krawczyk" fullname="Hugo Krawczyk">
<author initials="H." surname="Krawczyk">
<organization/>
</author>
<date year="2010"/>
</front>
</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>
<seriesInfo name="DOI" value="10.17487/RFC5246"/>
<seriesInfo name="RFC" value="5246"/>
<author fullname="T. Dierks" initials="T." surname="Dierks">
<organization/>
</author>
<author fullname="E. Rescorla" initials="E." surname="Rescorla">
<organization/>
</author>
<date month="August" year="2008"/>
<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>
</reference>
<reference anchor="QUIC" target="https://www.rfc-editor.org/info/rfc9000
">
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
<seriesInfo name="DOI" value="10.17487/RFC9000"/>
<seriesInfo name="RFC" value="9000"/>
<author fullname="J. Iyengar" initials="J." role="editor" surname="I
yengar">
<organization/>
</author>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson">
<organization/> <organization/>
</author> </author>
<date month="May" year="2021"/> <date month="May" year="2010"/>
<abstract>
<t>This document defines the core of the QUIC transport protocol.
QUIC provides applications with flow-controlled streams for structured communic
ation, low-latency connection establishment, and network path migration. QUIC in
cludes security measures that ensure confidentiality, integrity, and availabilit
y in a range of deployment circumstances. Accompanying documents describe the i
ntegration of TLS for key negotiation, loss detection, and an exemplary congesti
on control algorithm.</t>
</abstract>
</front> </front>
<refcontent>Proceedings of Crypto 2010</refcontent>
</reference> </reference>
<reference anchor="I-D.ietf-tls-dtls13" target="https://www.ietf.org/arc
hive/id/draft-ietf-tls-dtls13-43.txt">
<front>
<title>The Datagram Transport Layer Security (DTLS) Protocol Version
1.3</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-dtls13-43"/>
<author fullname="Eric Rescorla">
<organization>RTFM, Inc.</organization>
</author>
<author fullname="Hannes Tschofenig">
<organization>Arm Limited</organization>
</author>
<author fullname="Nagendra Modadugu">
<organization>Google, Inc.</organization>
</author>
<date day="30" month="April" year="2021"/>
<abstract>
<t>This document specifies version 1.3 of the Datagram Transport L
ayer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to com
municate over the Internet in a way that is designed to prevent eavesdropping, t
ampering, and message forgery.
The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protoc <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.
ol and provides equivalent security guarantees with the exception of order prote xml"/>
ction / non-replayability. Datagram semantics of the underlying transport are pr <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9000.
eserved by the DTLS protocol. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7301.
xml"/>
This document obsoletes RFC 6347. <reference anchor="BAA15" target='https://doi.org/10.14722/ndss.2015.232
</t> 77'>
</abstract>
</front>
</reference>
<reference anchor="RFC7301" target="https://www.rfc-editor.org/info/rfc7
301">
<front>
<title>Transport Layer Security (TLS) Application-Layer Protocol Neg
otiation Extension</title>
<seriesInfo name="DOI" value="10.17487/RFC7301"/>
<seriesInfo name="RFC" value="7301"/>
<author fullname="S. Friedl" initials="S." surname="Friedl">
<organization/>
</author>
<author fullname="A. Popov" initials="A." surname="Popov">
<organization/>
</author>
<author fullname="A. Langley" initials="A." surname="Langley">
<organization/>
</author>
<author fullname="E. Stephan" initials="E." surname="Stephan">
<organization/>
</author>
<date month="July" year="2014"/>
<abstract>
<t>This document describes a Transport Layer Security (TLS) extens
ion for application-layer protocol negotiation within the TLS handshake. For ins
tances in which multiple application protocols are supported on the same TCP or
UDP port, this extension allows the application layer to negotiate which protoco
l will be used within the TLS connection.</t>
</abstract>
</front>
</reference>
<reference anchor="BAA15">
<front> <front>
<title>Verified Contributive Channel Bindings for Compound Authentic ation</title> <title>Verified Contributive Channel Bindings for Compound Authentic ation</title>
<seriesInfo name="DOI" value="10.14722/ndss.2015.23277"/> <author initials="K" surname="Bhargavan" fullname="Karthikeyan Bharg
<seriesInfo name="Proceedings 2015 Network and Distributed System Se avan">
curity" value="Symposium"/>
<author fullname="Karthikeyan Bhargavan" initials="K." surname="Bhar
gavan">
<organization/> <organization/>
</author> </author>
<author fullname="Antoine Delignat-Lavaud" initials="A." surname="De lignat-Lavaud"> <author initials="A" surname="Delignat-Lavaud" fullname="Antoine Del ignat-Lavaud">
<organization/> <organization/>
</author> </author>
<author fullname="Alfredo Pironti" initials="A." surname="Pironti"> <author initials="A" surname="Pironti" fullname="Alfredo Pironti">
<organization/> <organization/>
</author> </author>
<date year="2015"/> <date month="February" year="2015"/>
</front> </front>
<refcontent>Proceedings 2015 Network and Distributed System Security</
refcontent>
<seriesInfo name="DOI" value="10.14722/ndss.2015.23277"/>
</reference> </reference>
<reference anchor="ECH" target="https://www.ietf.org/archive/id/draft-ie
tf-tls-esni-14.txt">
<front>
<title>TLS Encrypted Client Hello</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-esni-14"/>
<author fullname="Eric Rescorla">
<organization>RTFM, Inc.</organization>
</author>
<author fullname="Kazuho Oku">
<organization>Fastly</organization>
</author>
<author fullname="Nick Sullivan">
<organization>Cloudflare</organization>
</author>
<author fullname="Christopher A. Wood">
<organization>Cloudflare</organization>
</author>
<date day="13" month="February" year="2022"/>
<abstract>
<t> This document describes a mechanism in Transport Layer Secur
ity (TLS)
for encrypting a ClientHello message under a server public key.
Discussion Venues
This note is to be removed before publishing as an RFC. <!-- [ECH] [I-D.ietf-tls-esni] IESG state I-D Exists -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tl
Source for this draft and an issue tracker can be found at s-esni.xml"/>
https://github.com/tlswg/draft-ietf-tls-esni
(https://github.com/tlswg/draft-ietf-tls-esni).
</t>
</abstract>
</front>
</reference>
</references> </references>
</references> </references>
<section anchor="acknowledgements" numbered="true" toc="default">
<name>Acknowledgements</name>
<t>The authors thank Eric Rescorla and Martin Thomson for discussions that
led to the
production of this document, as well as Christian Huitema for input regarding pr
ivacy
considerations of external PSKs. John Mattsson provided input regarding PSK impo
rter
deployment considerations. Hugo Krawczyk provided guidance for the security cons
iderations.
Martin Thomson, Jonathan Hoyland, Scott Hollenbeck, Benjamin Kaduk, and others a
ll
provided reviews, feedback, and suggestions for improving the document.</t>
</section>
<section anchor="mitigate-selfie" numbered="true" toc="default"> <section anchor="mitigate-selfie" numbered="true" toc="default">
<name>Addressing Selfie</name> <name>Addressing Selfie</name>
<t>The Selfie attack <xref target="Selfie" format="default"/> relies on a misuse of the PSK interface. <t>The Selfie attack <xref target="Selfie" format="default"/> relies on a misuse of the PSK interface.
The PSK interface makes the implicit assumption that each PSK The PSK interface makes the implicit assumption that each PSK
is known only to one client and one server. If multiple clients or is known only to one client and one server. If multiple clients or
multiple servers with distinct roles share a PSK, TLS only multiple servers with distinct roles share a PSK, TLS only
authenticates the entire group. A node successfully authenticates authenticates the entire group. A node successfully authenticates
its peer as being in the group whether the peer is another node its peer as being in the group whether the peer is another node
or itself. Note that this case can also occur when there are two or itself. Note that this case can also occur when there are two
nodes sharing a PSK without predetermined roles.</t> nodes sharing a PSK without predetermined roles.</t>
<t>Applications which require authenticating finer-grained roles while sti
ll <t>Applications that require authenticating finer-grained roles while stil
l
configuring a single shared PSK across all nodes can resolve this configuring a single shared PSK across all nodes can resolve this
mismatch either by exchanging roles over the TLS connection after mismatch either by exchanging roles over the TLS connection after
the handshake or by incorporating the roles of both the client and server the handshake or by incorporating the roles of both the client and the server
into the IPSK context string. For instance, if an application into the IPSK context string. For instance, if an application
identifies each node by MAC address, it could use the following identifies each node by the Media Access Control (MAC) address, it could use the following
context string.</t> context string.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="">
struct { struct {
opaque client_mac<0..2^8-1>; opaque client_mac&lt;0..2^8-1&gt;;
opaque server_mac<0..2^8-1>; opaque server_mac&lt;0..2^8-1&gt;;
} Context; } Context;
]]></artwork> </sourcecode>
<t>If an attacker then redirects a ClientHello intended for one node to a different <t>If an attacker then redirects a ClientHello intended for one node to a different
node, including the node that generated the ClientHello, the receiver will node, including the node that generated the ClientHello, the receiver will
compute a different context string and the handshake will not complete.</t> compute a different context string and the handshake will not complete.</t>
<t>Note that, in this scenario, there is still a single shared PSK across all nodes, <t>Note that, in this scenario, there is still a single shared PSK across all nodes,
so each node must be trusted not to impersonate another node's role.</t> so each node must be trusted not to impersonate another node's role.</t>
</section> </section>
<section anchor="acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors thank <contact fullname="Eric Rescorla"/> and <contact full
name="Martin Thomson"/> for discussions that led to the
production of this document, as well as <contact fullname="Christian Huitema"/>
for input regarding privacy
considerations of external PSKs. <contact fullname="John Preuß Mattsson"/> provi
ded input regarding PSK importer
deployment considerations. <contact fullname="Hugo Krawczyk"/> provided guidance
for the security considerations.
<contact fullname="Martin Thomson"/>, <contact fullname="Jonathan Hoyland"/>, <c
ontact fullname="Scott Hollenbeck"/>, <contact fullname="Benjamin Kaduk"/>, and
others all
provided reviews, feedback, and suggestions for improving the document.</t>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAPDHYmIAA81cW3MbN5Z+x6/AMg+Rask2KfkWZZIZWXJira9jydlKbe3a
YDdIImp2cxrdkhnb+e17LgAaaFK5VO3DqjJjkY0+AA7O5TsXaDKZiNa0pT6R
F+tN3bSmWsqnH1vdVKqUby6fW7moG3n14lKo+bzRN388rqjzSq2BYNGoRTsx
ul1M2tJOtBs92djriSEiuplMH4tctXpZN9sTadtCCLNpTmTbdLY9mk6/mR4J
1Wh1In/UlW5UKW7r5nrZ1N0GBpVWXOstfFPAsiokr9vJOU4rhG1VVbxXZV3B
Urbaio05kf/V1vlYWpi60QsLv23X+Mt/C6G6dlU3J0LKCfxPSlPZE3meySe6
+kWtTUVf8r7O1Y0p0gd1s1SV+VW1pq5gqXW9LPVYvnhxltFjvVamBIbgi3Nd
/WNJA7K8XqfznWXyNJP/WddFNN3ZqjG2rTcr3SRPYU54WNZdsSiBRfFEubr9
x0qrDRzS3LQ2A7YIIaq6WcMKbzTu8u0PZ0ez2Tfu18f37z86AdZXi3jM5bPT
oxOi60RkdKnzrtHymbIreYkMVk0xohFWN0ZbJHAif7h4cynfvHsiZ4+nk2N6
XMAZn8jXeVvPYRtwsI/p657r/DPhXb0iRoJgXVQWpu5aLetFmNBK+Fde6XxV
1WW93OJKdbkw2tHpF0tfSjjhUudI0cq6QhmVs+xY3pp2hZLL699ZijuX8EMH
9CqT502XX+smfcgn9co0u4/3kbnM5I+dbupqH5XLldomj5l3R9PZN25/qlnq
9kSu2nZjT+7d05vGVG1mVN5kwL57OPLe8f1H2aZYwBvPG3U7mw54c9ZsN229
bNRmZXJU5EYRh4i1z/VWnsN53jh5vlrBkT8//0Fe5iu91qPBsqb8OZaAN02d
a12A/Fk8ubO3P7+5eh2N/RNbmN47enh/z9EEfhInn2W0v/zX7bUQk8lEqrml
vQhxtTJWgjHq1rpqZaFt3pi5RuGBV8FWLFSuyWiZYNB0MGiNnsA5NJqYYeUB
WrhD0I+29vKT8XxrUxSlFuIrNEBNXXTERpjdSdmnT//G+vXwyxdpuw1OZQf0
ifwhbROWanJi+1jegsZrU5F1BSNZybmWGszavDR2BW/eGAVMtxaPDd661kB4
0dRrCcyEbeV1VQWxb8Leyi2/WK9Bqbp2Ui8mczh0sQZ9Ahtm1xmd96apwVbW
pVyj0rXAt3alWqlVTkoDigSEYEGdhZWQKgFN4GGp5Qqtw6KraO6Mz+FW4VlU
WgIDLTC8NIttP4eCdW2tsZlj7hGw7e/AtgdHyLYxnBfuBs7VtmMB5GUFVDpY
SaP/1ZlG4wmPJXyvaG1rNVxateVVqRIcDXyzJjkHdgs/4cbqrqgb+BoY6BcP
B/P2h0OwuSsD+2rxPKSh2a+r+raCXW1xbbegQyt8LC1osNCRWwT5WK5a3ClI
hob1lsDLAhm/6Vp818sJrofP7UY3eKTgnYjHpVkbeEV4HuFGYHe6In6Cw9gA
M1lkLFjs1+9enON0N4bkwuqNamDK3kUfnB9Gc4p0zgykGLwHSBVLH2wKZqQt
wyZqkLU5OjadLbOx44fC/5XgoostKNmmrLewWJ0gA5ggrAjVDOjV+PKtsdrv
bwy8mXQ21UJ8GUwCzCsLs1jAdFUr/FrRsOBO8LT389eO3dGs+ZzarqlkCSsl
KURXZlp6Fza1tt8Kq3Wir2PwKywHT7NHoO9XNRxna5bIT7VUYIBaFkNPYsz8
CkbHbnRuwAd5wbxwqEf0Bmi+dWtMd+1E2MGkgsTDdnML8g6EUfXqrqJ9KD9L
jlgIjsDb7UiKwXYfEolENUkcQEliMYy3L/CN8+gJ/j47/u5icp4FVFfA/82O
v3whyQFZA0PUARwBnU1sbm9eBiaXdkuLhl2S9UoZMceTy8sOfQmpGLsOCVsa
CyfLwY440RjTXsFg1huHI9B6AF0AmA3RqaWuLCKZrjLIUbCiaPbg7DbouUDe
tkaXiDRATlqUNLC/hUFDKHBZYzaE8D0fHipBdCL9Gp1e8/rGbENxcNBL2jK4
N6sF2Ss4i6ChR3usglum/riBZ6ilQPC27spCErxD875SN5othDfJuGaiZQp0
MC3ylEWHN8eK1j8Hic3QpZ3V1Q1+gdpGwqAXpjL0Gf2rlihxCL+tHL18d3k1
GvO/8tVr+v3t03++u3j79Bx/BzD54kX4xY9ggzUaC/db/+bZ65cvn74655fh
Wzn46uXpzyM+6NHrN1cXr1+dvhiRkgN7RNBA5DXsFFUJVW7TaNImG2STOP7k
7I2c3QcRd6gYXLVThNmj+6AIYAudUJFJ5o8gjFupNhutGqQBrAch2ZhWlZZ8
kV2hi0AbSby80g1ECwRY5aev2v7TF2bloi7L+pakE55ZWjlJRLuCaGe5ApOW
WhfA65MkBJMHTxFHnMhT+hRDhdgCs3n0fl8emEyDMQcDD8CKpFGRNejhw6ET
coPq0HabktD4wRNwE4hexv0iLpx4jSlCOMxggX4Uo0gwunAC8kaVHREBHcU1
Z/FOPBHcB9u7nMbOt4hCmCW1k1QAERGJK1Y7r24nKZBBu+O0lfiDjs2bV2cJ
IyKgu/w+KvGffPXCf0eHceEPA7mJ3yRWzi17fJeNGguPkiPzQaAlrA+nfFVX
ExNNC/MxYbdeYlcBEClHp0EIyS8HkREK1VyTT3ZEkn389aO4oKMYYO8O8QSo
noUP7JpKVS07tXTmj/Ru6HKPSWteg927MfqWdST2oRGIX5umqRuHUGF56CZw
l08/8lAbjT1gJ+8m7Kd7lD348gURPlNB72XI5jr3jZZurnDHiKoQPLvz6uDo
QtwMeJcQlAOryB1cTFhI7/h7eO+wYO+JSNHyldE3DuQDX8HeA8qDVZVqrksS
hKG8tHczqEC7DcTcjK265jgoQaqJfyC7yjJhR8gNdBgIlscSNFiR6w7uY+Qk
e7TPkfQ+j1wmbzOTT53/hFWD6/Oqwe/vdaa9FqBGOpkzunF2eb8WZeK0KAw/
KrdkswEj2q702EPOTQWT4/HyxOu6QLIhpqn0bYypiP0C1gXijK4R51t0BLXp
hWqgj+SvyX47KN2f/27YSdCC6QS4G3PSYZLCWHgtb4frB4UJmkv7KWrC7S5I
gq0s69aoBPoBPgD5UDIvDblLhJmgcUDx1oBDw9fVsgGV6TYQ1UZrMYveBAKN
umETAwdbFZsatmkd6s45PCNkwvFBKqUuJhYA9GrcMzJkh4s+uRhgkENFUTie
mkKSwZgCZhF7zvG2QRpMEzOYxzjOZ2Ab0FQ06Ji7FjABLmJd4xjdKlMiw/vd
Oh9Jc/aKRefgIRFxvGXYFOmFqVD/2VQIR8DDUJwSo9dN10D4pTluwlcrIuTT
qKwEO/M4tRI03++Qci4BhPUlbK++QYKkrYmBWLC571epm7BOmhpQlrK2zg3F
YKxALXAMDCGG/mleQBKQFWjrYIJ6WXfWm8umK1HCqmCc72dH2WyG5iKOT/wB
+UhuArpo4TQbDob5wAQfmLF5R5kS8iq9ADpXZd1EfcTyO9aUZAtOvEPNK7co
sMFXcCAeRTs4uNdRMBdrOGzWQTY1/AYu66sUzZ0PaP6eB3QW3TpZUh4D4BHs
ACv5wR/re2/vP/A6EavhKj/ojb3+MBaEk9l1wGl8+hSjVnDVmFxf+gzLjgl2
cKVRlUXvaL0XScMOkWhqpItRcKoiMNo74YFfYL8DvgHUchCKIikSZ2drdDF8
WX7gL977Lz54auHJdbH4wE42CD/KW9t0eUvO1NvewGZ+hlGmsg7eWwDtv/32
m+BH8hPmMuuNAo8od87kb7Msy47+Z/ZwMvv+22igY+/fpunTDng7eygH+9jz
CDbyrfiys9xvaWEkZBA00PkMh2Q9BYbwBFXWCsgrEhKw4Renr0534qtPn/Br
0FiRloyCwYpTHUmS6ohDlzQC3mOXRa/hKBsQesn9DsTn2va7GIjlwBH2c4m8
nuiPyA7KWvTOzLky/BC53cAoj0Jog5y/YIvsH3jsDJ6EdIqfckRgFmSnaV4Q
5h8oeavWG8y83TmTc7Y0UQRHpZojxt9o2BQwTFMyrtcyRDIhpcX1koltt6WO
iiZgw1uVX1tgOY/oLa9/dWLdgz0u8tK7WjZJxoPpYTQUXE3QSSAVBx1B0cd/
kt9gNsAIVwCX0QCjmcbVBb+IXwSagh3Lg+kDcixXq7ADBqmwbE8EXXZYo8+9
MQjtSG1sXm+osiCSeH2fnAy0NbhRXOQdya0oGEVP7Hg6COJkIjR7axEUlE0/
To+n932aFCGfoKzuoqasrq1DHh1U+5/vLs5uZpiax9++A1LfTKdTZNerutWM
Z2jHaw02n/ZQdeu5boRPMe2LgFkiQk7ShW/8In0amHlg449ApNprcjkuAixq
Aa7SafV+cOjdYgK4PHGxZ6iBoR8/4BrZc3PyKDXmWHfFYfI7qpJNXDXtYDqm
7w9xgEkHYPJu8gJjiQN6dRxiKAkfR+O0Ljj8weTKwXDvh2P54pBt+IuIBwFU
oS9zoWapq2W7+iMLP3T+3oSjaCGUm7AnRo875jQ4vIH7e4914wcPD0C4ptPZ
4TgUEXAZ/dz4KYGEgpfnywvHYPvzlopaMCPTdNlP+M8FNUXQaTo9TvUBcTeN
7QwmwbTAUb33zw1W0/GhppKHr4yNd8+H9US5uDuVLYiI/0ij/WZGlCYfxW6I
koQbEPK96Y9H2WwsYPCoiN48333173uz8T2dB9lsmrFbD8E98McLNuYpMfCr
OZ64NVzhGm4LnBJlCanGBYKqSvOrdimIqhV7JAmpkOFQtnd8FcM+ex3YFSWk
A+RGT1BZVzvUA56TxSCQ6w/eWzfUV5uvdAHRA87+NW3xa9j8KS9hrT6adbeG
4O9X7QUwmQ/fQkglJ3LmZC+1EmFzXAv9iDVuy1aeiMK/pbnWEOmCIOYK4asC
JcprWrrGLBX5Fjaw498LMlw6vNG/wEEKxAM7HI4XIcMi3GGnlR46CWQYlfGd
r3v8EBPdxkWifY53EMJ51w2wuvWlwB3d3XnrdywLaNwiUBVFrZkmlS3YjiTk
knnGaAgmYAkQjYBJgA04TjlHlQkfN22D+Z/vMi82dFwKwnNUrc9hUo0Sc/1e
hlnmQMaQKmArUgJKUEURLhalYGcQyVpAX5aWIDjnFOrUlq3pXwxj7847uO0v
qT2qJdQDngreBbMX1DxEQM6bRgaQ6xiUehlgzT5BxYjN2a73p08v38+OHr//
8eylM/XckOMewWf/6PjxfS5OCUpdyfa2llw+Q255eZxERFTFaYn4GVBJsqqI
kMUfLOTs2Sn8dzR9/+b1i59nx9MHYQAW37wjcCV2WEzIQOJGUcg1pjVUs3WZ
yphhnMKE90IS0g4qk8DIjgI/Dw9deZ4kDEHpkiEe9g9430yTcoKOdAizb5qD
hG6DhUeubCUU8eEaQn+Zl1iFwqinX4RLZ/kAo/eUaYoJhYmDsdOfkzhsziiQ
TD5QJdOdROJmMdg2nGsP0qm7IM3GHthDWhM3TyiO60wm+/k95EyCQQzKtthu
pFAbBU+7TdPEbVzpsbptqfXIpckXZtk1jmE+6RbjBwEukC10mCmTL01l1j5r
HIFaxdYvarsAoLAFkX3jp38V5VkpTBbczfLoeDpD14zomfMifA6qUWtNZYoD
2Fsw1Tjs0Jeyty5d1+hS3yhwudFbYU+R/Az45uOKuAhI2Rs0NJyD51PgPNQT
TlilfWDy01fevX6hXojdFPhct7dYd07SsDuR9ngQmrNChPpFlC0bJt53mgyc
cFJbYAACPRExTLmZHtPug/H+Zxp/+Bx/uBFEfvK9TLA+IPunxO1LKnDe+fq/
T/Dne+aqnvDoA8SHqCW86JH8LEfgj/xHeDg6TCjuDQq+c+Pfw57j0T9xTHCR
sNwniF0/BFZ6wuygKSExnCwL0Wi0LqqK96H0h376D67pq48DozP9o1Dq/8cZ
/DG/B6f0516I+Px/c6zEZ6xRcXzioMzvFHS8iSAR4Ap8kuQH1xr6HMAaHahD
MLKA53QAHM59eHXFbN38EAgbEhs/zg2zPkmRSUDhsYxw3A9+a4FiMWYrQEmM
1iY6GwCiAoyS45a2go0hvEfp/HMNpijnoiS1Jv/g0KIFuV/0zKCEkuOFXWnL
CTh+F4HTANGS7ZJoJbVLRbdJ/CbIDQGqq298ci+OVKhxgLt7tM94x945GPoe
Z3EVzxXP012HEH7jgGGUQkQ5TlIZ3L1zEaUrz0O6Esy4z5wKTJT3iUzvSVwz
H+FxshaJ16goHYDsIJzv0rRjzBLq9aYlxFvvr/slyfO+RMLtS9j76mqzrt8T
4HDj2geAd+Qf/NriFZG5r6lmOmxzwPyxL20r2/dcuFinEtQRmNP8aKx6946N
nKF/i7uccJDPhmG0Cli2r9IG7OEQjz9GFy8p2BnINDCk0ANI8q20fxn+P6tv
NRXpyLYC8l+g0tQIHlCM4jx3+JKUe+0bIlzTJEVcC4CThroKBeqdLkvutaPo
kiqmy0RK8lWN9UNqosPkCuMjcPP4dmmUgwQ96EKIpeS8MXrBuIcq8pjAMHWB
h1FqsmG2XrS3CGQOdvcRln7ITpwbTTPxmvQBuz+oEbUAsWC1IFyMwIlCyt1p
uUMLDBmmUlxnK6nNpW8MPUsOYk/9LbSQLmsArtK1aFO1v8Tyjxr4OKluasMC
S82u2jW3CrIHzAc4lA1WFZNucISm3v5iN7Km4iFAQSIfGUvQdM3eEDhCnRJW
QCjdrV16dn8Ue3Dx/CWx1VLk5/Kz1OQysnXX5HpELa5qbkrcLpbRGzPvKGnH
jdQUOW9JKYCYrw7hkeTY24gt93BmKP7UvQpSyQ2UZMc/feI7Cpx5xyCHJp30
7+RJCC2pgVzbgbqGifEkUOu8tlLgE6ur4DIh+iWXxUx775EX3g+QAcO5gTTO
Ta3DXGhCa7Xe8As+tIgCJEGpw6BCaEWSxEE/pR74WMzfh25AjBPr5hpNIMQR
T05PZw++O399gXm92f1HR0f3qgKiuKPp7EF2dHz06BGGGD7jqnDva+pfBSGh
YCndaSZfoDKD6kNgqa6xkeiuoT6DyxLq80+EH0APfPJ+jb012CKYviyiwNA3
PinMRCuXOsF0IRkQED1U4bH8BVmRKgKKVFnGtYDTVEt8LTq67DBwFa5tnfNv
YADQqoOS09CdExE+vxhFve7iQFKv6lvbfVAtr7YboBOajnZH+6HC9a77HvHd
EoYPokkr+7sGVK1QfVHFeWbn21q3OeHzYph0UzfgPxS18HsJiXO0d5bVSKvA
8FBZUFPbjarSew6+m5CsrX8P6I7c75NFo/WIkpOd9Tc6yLx6Id+n9MyM/eIY
59RCKtXFOUnvW1SITtvzlVkTBnTNdkSjb8Mlow5xySwLLRS74mTjLijqbRiK
i6N9xy6orr/werUjRz6D4ahl4ihDtxQY6u5XIFj3Ew24hOficuv+VCiP4+7q
xLSPsxREck6hboOMoIHdsaWu5eL+8GXXfAZqWmKOgTRzwVmxYUkzbt0QV+FW
SbhmM7jVwTjeuV4D3k1bTrYXPd72yrWgi1DoH5Gr6Qp3Ks9e/SIC+BY6K2fE
Bxdb7ujYh0isvqUaDXDAl89Cu0ImPXwT8QUfuf+CzzhKzIM0hW5GYIqyeL4r
akIPV4DEX74CtHPtCLM61OOetnr1KmX27Pw42wOQQhDjU0XxSpn/oYdm0PfX
MGCNOhUodxpLU5xFGt5ceIOJo3wXwyUdVoPOPwTodCKI3EyOZQMwHmaJ/b4O
Die9jS6JssY6YFnX191miKwo6FUuquE+JEJVdmshWGKxRyp048rbZGd8BV8B
ynG8QtAKokEVNIR31xQohx5Y2DKV4Cl9Siu905TDDCgXCNvRBmPemI1CVABE
RMwJ35CU86vK5LuqRMPUX+BCbQYTwj0CKorrfE2YWrEhHtxu8B7bGcXizyDK
qLF8+fTsWXqhSNvKUHPZnntt2CqEANZqAvM3SauL8PZ9gbUGjoCxGSkVAQh/
qZDtG/+SdLpxVzjJGWNE0uglYt1Q+xj0HuOZ4YXaQoz8w4v+4WjMLYIOADgY
OLoKmV/OG4d44wBoHMo3IbE7kisIdqmLmVQLCDeGGyO5puTWBrILbuozTX9O
3o4xKeWUfiJADL+81WSvc/wgPp9Mdn/Cl8lTGAzvUt6kSLJVVN6fys+v7p1G
ibbPcQvAYPBMfo5Lj/FgrBSlg4+Ggz+dyK+ui8Uk7JtY/92ov7AB6+RHIzje
VzouhsQRCfjxOufYLAek5Ur5A+/v7D9dsvnJ9bo5vlP5hnc/mX5c6MWCyVq0
Fa5l/zKRq7e+2OBvFR1h3e9OyosFU144yo1nP0ohWTbQ9XdWD8iJK++3CkoC
4mgESZoF7yaZ644F2g11uPalKzbzvptg9ihpwn1E0+I16DnYJNS40xxdNmjE
koEZL4ovcFO8Vl3Lpw0YVxAp4H2puHEZU/oVxH712roOp76fz4V5Zd99vAn3
rENzlsd05HVvwbjgv/yXEwz4zWdYuFsr18WHJgSkSPHRb9hViDTvwl4/cvaZ
/I96VcFS29Zahu83piD2pPTiRIvo8yYypQ8ooFvW4fJ6T27ZmUJV7mo6pw6d
fRgQECnXxrC+SlHW/lm9LYGtY3mZ120LH0uIXMGVXI/DX62Qz1XRXbu7E2jK
KbISYRXgr42+Bfu20LrAwx27K6jLJYoTuW9OXeIbDsFHnW4gCUXROADFbYNg
eYf9giwd7jG3GUZdhoj70N4hipYQFLqMdXBJHo9kAXhEV4KoIdolHPnmDOVB
Nn0V0F9lxxZ0xpnk/EHGMB6N8uf4kfPGFESFCJeHIBwV4TseFy5xuOsG3Hlp
V2QmOApFf4HziTS8bdnOoxemP3ICCAJQUUGNEWiPFt0wULUCc3/U4KlCHyDr
OFFAJOcKOpqHEZTkzAuSxi4jIAFM32nkQ1xCaS0CFnUOghiAoQPpEAsIpMLb
42aBOB4E5BeVoIkR2JETO3cGuP6WyiDvhcW6ZrJsVP++y5QBb0FifabRXUji
qMbyn1YgPM/XxxVdZik0Z+lAMOvyxlXUQbIAQOBlB65gzLH1NlQjXNPsje6b
jeLoboFKzt0wVQHTXmuMTvjSct2AEeBdkHVnSgvO9VBANqzR8B+YCN1sg7tM
1NSJl87RPLg24RgmiagfgYSbBAfW8vL0DCMHVEe6l80Jb18DDD5vUK3PfEku
blYPTei09PdrlXMf+mPfhu4H8IZ2B3zx8avrN7/gXZDuM4/xeDiVjygshouo
3pRAR9ODWkkbpKi7T+3hd+PBnXEeh2Lt22Q4yIuI+7thuTa+WCZcnTImP7xJ
7sPF/vjDvSnKhoPoe3CO849DEsLmugJ9qf2fUcCvUKD/lBCPBahjf8TrzlKy
k/5oki64Q6tGywemCJ2CThT+a0uymIn/BbFL2w79SQAA
</rfc> </rfc>
 End of changes. 93 change blocks. 
730 lines changed or deleted 267 lines changed or added

This html diff was produced by rfcdiff 1.48.