Code change:
6. <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 underlying HMAC hash algorithm) as TLS 1.3 with importers.  However, critically, the derived PSK will not be the same since the importer differentiates the PSK via the identity and target KDF and protocol. Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS 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.  Specifically, existing applications using TLS 1.2 with non-imported PSKs can safely enable TLS 1.3 with imported PSKs in clients and servers without interoperability risk. </del> <ins> The mechanism defined in this document requires that an EPSK is only ever used as an EPSK and not for any other purpose.  In particular, this requirement disallows direct use of the EPSK as a PSK in TLS 1.2.  The importer process produces distinct IPSKs derived from the target protocol and KDF, which in turn protects against cross- protocol collisions for protocol versions using this process by ensuring that each IPSK can only be used with one protocol and KDF. This is a distinct contrast to TLS 1.2, where a given PSK might be used with multiple KDFs in different handshakes, and importers are not available.  Furthermore, the KDF used in TLS 1.2 might be the same KDF used by the importer mechanism itself. 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 use of the already provisioned PSK both directly as a TLS 1.2 PSK and as an EPSK, which in turn could mean that the same KDF and key would be used in two different protocol contexts.  There are no known related outputs or security issues that would arise from this arrangement.  However, only limited analysis has been done, and as such is not a recommended configuration. However, the benefits of using TLS 1.3 and of using PSK importers may prove sufficiently compelling that existing deployments choose to enable this noncompliant configuration for a brief transition period while new software (using TLS 1.3 and importers) is deployed. Operators are advised to make any such transition period as short as possible. </ins> 7.

Related discussion:
text: L corresponds to the KDF output length of ImportedIdentity.targetkdf as defined in Section 9. For hash-based KDFs, such as HKDFSHA256(0x0001), this is the length of the hash function output, i.e., 32 octets. This is required for the IPSK to be of length (32 octets for SHA256, not all hash-based KDFs) 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. The corresponding TLS 1.3 binder key is "ipskx". In RFC 8446, the "binderkey" is the output of the key schedule, but ipskx is an input to the key schedule. So I think we want to say something like "the corresponding PSK input for the TLS 1.3 key schedule is 'ipskx'". The hash function used for HKDF [RFC5869] is that which is associated with the EPSK. It is not the hash function associated with ImportedIdentity.targetkdf. If no hash function is specified, I predict that someone will mess up the hash function selection while implementing this. Perhaps we could provide test vectors for the full matrix of (EPSK Hash, targetkdf hash) pairs using SHA256/SHA384? SHA-256 [SHA2] MUST be used. Diversifying EPSK by I think we might be able to tolerate the protocol* having a strict requirement that the associated hash function is specified, and provide a recommended value that would be used by people deploying the protocol in the absence of other information. This might in some sense help future-proof the document for the scenario where SHA256 weakens or is broken and the default should change. KDFs, protocols, and context string(s) are known a priori. EPSKs MAY also be imported for early data use if they are bound to protocol settings and configurations that would otherwise be required for early data with normal (ticket-based PSK) resumption.