Original text:
1. <del> TLS 1.3 RFC8446 supports pre-shared key (PSK) resumption, wherein </del>  PSKs can be established via session tickets from prior connections or externally via some out-of-band mechanism.  The protocol mandates that each PSK only be used with a single hash function.  This was <del> done to simplify protocol analysis.  TLS 1.2, in contrast, has no such requirement, as a PSK may be used with any hash algorithm and the TLS 1.2 PRF.  This means that external PSKs could possibly be re- used in two different contexts with the same hash functions during </del>  key derivation.  Moreover, it requires external PSKs to be provisioned for specific hash functions. Imported keys do not require negotiation for use, as a client and server will not agree upon identities if not imported correctly. Thus, importers induce no protocol changes with the exception of <del> expanding the set of PSK identities sent on the wire. </del>  3.1. 5.  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> 6. </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 However, critically, the derived PSK will not be the same since the importer differentiates the PSK via the identity and hash function. Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS <del> 1.2, and thereby avoid cross-protocol collisions. </del>  <del> 7. </del>  This is a WIP draft and has not yet seen significant security analysis. <del> 8. </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> 9. </del>  This document makes no IANA requests.

Reviewer comments:
Importantly, add details regarding incremental deployment, and clarify label values for non TCP-based variants of TLS.
Fixed in .
Fixed in .
Both endpoints must adopt importers for interoperability's sake.
Fixed in .
"TLS 1.3 supports pre-shared key s/resumption/authentication"
Fixed in .

Revised text:
1.  <ins> TLS 1.3 RFC8446 supports pre-shared key (PSK) authentication, wherein </ins> PSKs can be established via session tickets from prior connections or externally via some out-of-band mechanism.  The protocol mandates that each PSK only be used with a single hash function.  This was  <ins> done to simplify protocol analysis.  TLS 1.2 RFC5246, in contrast, has no such requirement, as a PSK may be used with any hash algorithm and the TLS 1.2 PRF.  This means that external PSKs could possibly be re-used in two different contexts with the same hash functions during </ins> key derivation.  Moreover, it requires external PSKs to be provisioned for specific hash functions. Imported keys do not require negotiation for use, as a client and server will not agree upon identities if not imported correctly. Thus, importers induce no protocol changes with the exception of  <ins> 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.  (Negotiation and use of imported PSKs requires both endpoints support the importer API described herein.) </ins> 3.1. 5. <ins> For clarity, the following table specifies PSK importer labels for varying instances of the TLS handshake. 6. </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> 7. </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 However, critically, the derived PSK will not be the same since the importer differentiates the PSK via the identity and hash function. Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS  <ins> 1.2, and thereby avoid cross-protocol collisions.  Note that this does not preclude endpoints from using non-imported PSKs for TLS 1.2. Indeed, this is necessary for incremental deployment. </ins>  <ins> 8. </ins> This is a WIP draft and has not yet seen significant security analysis.  <ins> 9. </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> 10. </ins> This document makes no IANA requests.