Original text:
used.  This produces a set of candidate PSKs, each of which are bound to a specific target protocol and KDF.  This expands what would normally have been a single PSK identity into a set of PSK <del> identities.  However, importantly, it requires no change to the TLS 1.3 key schedule. </del>  2. diversify a key based on some contextual information before use in a connection.  In contrast to key exporters, wherein differentiation is done via an explicit label and context string, the key importer <del> defined herein uses an optional context string along with a target protocol and KDF identifier to differentiate an external PSK into one or more PSKs for use. </del>  Imported keys do not require negotiation for use, as a client and server will not agree upon identities if not imported correctly. <del> Thus, importers induce no protocol changes with the exception of expanding the set of PSK identities sent on the wire.  Endpoints may incrementally deploy PSK importer support by offering non-imported keys for TLS versions prior to TLS 1.3.  Non-imported and imported PSKs are distinct since their identities are different on the wire. See rollout for more details. </del>  Clients which import external keys TLS MUST NOT use these keys for any other purpose.  Moreover, each external PSK MUST be associated 4. <del> To prevent PSK Importers from being confused with standard OOB PSKs we change the label used in the computation of the PSK binder key. In TLS 1.3 the PSK binder key computation is defined as follows: </del>  <del> We replace the string "ext binder" with "imp binder".  This means the binder key is now computed as follows: This new label differentiates non-imported and imported external PSKs.  Specifically, a client and server will negotiate use of an external PSK if and only if (a) both endpoints import the PSK or (b) neither endpoint imports the PSK.  The "binder_key" is a leaf key. Therefore, changing its computation doesn't affect any other key. 5. </del>  A key importer takes as input an EPSK with external identity "external_identity" and base key "epsk", as defined in terminology, constructs an ImportedIdentity structure as follows: The list of "target_kdf" values is maintained by IANA as described in <del> IANA.  External PSKs MUST NOT be imported for versions of (D)TLS 1.2 or prior versions.  See rollout for discussion on how imported PSKs for TLS 1.3 and non-imported PSKs for earlier versions co-exist for </del>  incremental deployment. ImportedIdentity.context MUST include the context used to derive the output, i.e., 32 octets.  This is required for the IPSK to be of length suitable for supported ciphersuites. <del> The identity of 'ipskx' as sent on the wire is ImportedIdentity. </del>  The hash function used for HKDF RFC5869 is that which is associated with the EPSK.  It is not the hash function associated with that means ALPN, QUIC transport settings, etc., must be provisioned alongside these EPSKs. <del> 6. </del>  If a client or server wish 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 keys.  This does not affect the KDF operation used to derive Imported PSKs. <del> 7. </del>  Recall that TLS 1.2 permits computing the TLS PRF with any hash algorithm and PSK.  Thus, an EPSK may be used with the same KDF (and does not preclude endpoints from using non-imported PSKs for TLS 1.2. Indeed, this is necessary for incremental deployment. <del> 8. </del>  The Key Importer security goals can be roughly stated as follows: avoid PSK re-use across KDFs while properly authenticating endpoints. [[ TODO: point to stable reference which describes the analysis of these goals ]] <del> 9. </del>  External PSK identities are typically static by design so that endpoints may use them to lookup keying material.  However, for some systems and use cases, this identity may become a persistent tracking identifier. <del> 10. </del>  This specification introduces a new registry for TLS KDF identifiers and defines the following target KDF values: <del> +-------------+-----+ | Description | Value | +-------------+-----+ | Reserved | 0x0000 | | | | | HKDF_SHA256 | 0x0001 | | | | | HKDF_SHA384 | 0x0002 | +-------------+-----+ </del> New target KDF values are allocated according to the following process:

Reviewer comments:
Addresses . cc NAME
The document says: Aside from this statement needing update in light of the changes to the binder label, the core statement here isn't expanded upon. The document needs to very clearly say that the PSK ID that is sent in the psk extension is literally the serialized content of .
Fixed in .

Revised text:
used.  This produces a set of candidate PSKs, each of which are bound to a specific target protocol and KDF.  This expands what would normally have been a single PSK identity into a set of PSK  <ins> identities. </ins> 2. diversify a key based on some contextual information before use in a connection.  In contrast to key exporters, wherein differentiation is done via an explicit label and context string, the key importer  <ins> defined herein diversifies external one PSK into one or more PSKs for use via a target protocol, KDF identifier, and optional context string.  Additionally, the resulting PSK binder key is modified with a new derivation label to prevent confusion with non-imported PSKs. </ins> Imported keys do not require negotiation for use, as a client and server will not agree upon identities if not imported correctly.  <ins> Endpoints may incrementally deploy PSK importer support by offering non-imported keys for TLS versions prior to TLS 1.3.  Non-imported and imported PSKs are distinct since their identities are different on the wire.  See rollout for more details. </ins> Clients which import external keys TLS MUST NOT use these keys for any other purpose.  Moreover, each external PSK MUST be associated 4.  <ins> A key importer diversifies an input EPSK into one or more PSKs advertised on the wire via a target protocol, KDF identifier, and optional context string.  Additionally, the resulting PSK binder key is modified with a new derivation label to prevent confusion with non-imported PSKs.  This section describes the diversification mechanism and binder key computation change. </ins>  <ins> 4.1. </ins> A key importer takes as input an EPSK with external identity "external_identity" and base key "epsk", as defined in terminology, constructs an ImportedIdentity structure as follows: The list of "target_kdf" values is maintained by IANA as described in  <ins> IANA.  External PSKs MUST NOT be imported for (D)TLS 1.2 or prior versions.  See rollout for discussion on how imported PSKs for TLS 1.3 and non-imported PSKs for earlier versions co-exist for </ins> incremental deployment. ImportedIdentity.context MUST include the context used to derive the output, i.e., 32 octets.  This is required for the IPSK to be of length suitable for supported ciphersuites.  <ins> The identity of 'ipskx' as sent on the wire is ImportedIdentity, i.e., the serialized content of ImportedIdentity is used as the content of PskIdentity.identity in the PSK extension. </ins> The hash function used for HKDF RFC5869 is that which is associated with the EPSK.  It is not the hash function associated with that means ALPN, QUIC transport settings, etc., must be provisioned alongside these EPSKs.  <ins> 4.2. To prevent PSK Importers from being confused with standard out-of- band PSKs, imported PSKs change the PSK binder key derivation label. In particular, the standard TLS 1.3 PSK binder key computation is defined as follows: Imported PSKs replace the string "ext binder" with "imp binder" when deriving "binder_key".  This means the binder key is now computed as follows: This new label differentiates non-imported and imported external PSKs.  Specifically, a client and server will negotiate use of an external PSK if and only if (a) both endpoints import the PSK or (b) neither endpoint imports the PSK.  As "binder_key" is a leaf key, changing its computation does not affect any other key. 5. </ins> If a client or server wish 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 keys.  This does not affect the KDF operation used to derive Imported PSKs.  <ins> 6. </ins> Recall that TLS 1.2 permits computing the TLS PRF with any hash algorithm and PSK.  Thus, an EPSK may be used with the same KDF (and does not preclude endpoints from using non-imported PSKs for TLS 1.2. Indeed, this is necessary for incremental deployment.  <ins> 7. </ins> The Key Importer security goals can be roughly stated as follows: avoid PSK re-use across KDFs while properly authenticating endpoints. [[ TODO: point to stable reference which describes the analysis of these goals ]]  <ins> 8. </ins> External PSK identities are typically static by design so that endpoints may use them to lookup keying material.  However, for some systems and use cases, this identity may become a persistent tracking identifier.  <ins> 9. </ins> This specification introduces a new registry for TLS KDF identifiers and defines the following target KDF values:  New target KDF values are allocated according to the following process: