Original text:
4.  A key importer takes as input an EPSK with external identity 'external_identity' and base key 'epsk', as defined in terminology, along with an optional label, and transforms it into a set of PSKs that means ALPN, QUIC transport settings, etc., must be provisioned alongside these EPSKs. <del> 5. </del>  For clarity, the following table specifies PSK importer labels for varying instances of the TLS handshake. <del> 6. </del>  If a client or server wish to deprecate a hash function and no longer use it for TLS 1.3, they may remove this hash function from the set of hashes used during while importing keys.  This does not affect the KDF operation used to derive concrete PSKs. <del> 7. </del>  Recall that TLS 1.2 permits computing the TLS PRF with any hash algorithm and PSK.  Thus, an external PSK may be used with the same does not preclude endpoints from using non-imported PSKs for TLS 1.2. Indeed, this is necessary for incremental deployment. <del> 8. </del>  This is a WIP draft and has not yet seen significant security analysis. <del> 9. </del>  DISCLAIMER: This section contains a sketch of a design for protecting external PSK identities.  It is not meant to be implementable as precompute these obfuscated identities to ease the burden of trial decryption. <del> 10. </del>  This document makes no IANA requests.

Reviewer comments:
Discussed in Singapore; will merge and add security considerations motivation in a followup to .
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 .
This seems harmless, but it is predicated on a need to separate keys that I don't understand. Is there more rationale somewhere?

Revised text:
4. <ins> 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: 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. </ins> A key importer takes as input an EPSK with external identity 'external_identity' and base key 'epsk', as defined in terminology, along with an optional label, and transforms it into a set of PSKs that means ALPN, QUIC transport settings, etc., must be provisioned alongside these EPSKs.  <ins> 6. </ins> For clarity, the following table specifies PSK importer labels for varying instances of the TLS handshake.  <ins> 7. </ins> If a client or server wish to deprecate a hash function and no longer use it for TLS 1.3, they may remove this hash function from the set of hashes used during while importing keys.  This does not affect the KDF operation used to derive concrete PSKs.  <ins> 8. </ins> Recall that TLS 1.2 permits computing the TLS PRF with any hash algorithm and PSK.  Thus, an external PSK may be used with the same does not preclude endpoints from using non-imported PSKs for TLS 1.2. Indeed, this is necessary for incremental deployment.  <ins> 9. </ins> This is a WIP draft and has not yet seen significant security analysis.  <ins> 10. </ins> DISCLAIMER: This section contains a sketch of a design for protecting external PSK identities.  It is not meant to be implementable as precompute these obfuscated identities to ease the burden of trial decryption.  <ins> 11. </ins> This document makes no IANA requests.