Code change:
TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384 would 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 <del> supported, only one derived key is necessary. </del> <ins> supported, only one derived key is necessary.  Each ciphersuite uniquely identifies the target KDF.  Future specifications that change the way the KDF is negotiated will need to update this specification to make clear how target KDFs are determined for the import process. </ins> EPSKs MAY be imported before the start of a connection if the target KDFs, protocols, and context string(s) are known a priori.  EPSKs MAY <del> 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.  Minimally, that means Application-Layer Protocol Negotiation RFC7301, QUIC transport parameters (if used for QUIC), and any other relevant parameters that are negotiated for early data MUST be provisioned alongside these EPSKs. </del> <ins> also be imported for early data use if they are bound to the protocol settings and configuration that are required for sending early data. Minimally, that means Application-Layer Protocol Negotiation value RFC7301, QUIC transport parameters (if used for QUIC), and any other relevant parameters that are negotiated for early data MUST be provisioned alongside these EPSKs. </ins> 4.2.

Related discussion:
text: (Similarly, is it accurate to say that "[a]pplications SHOULD provision separate PSKs [...], but the mechanism defined in this document provides a partial mitigation for use when that is not possible"? Also, we only use the word "interference" twice in this document (this is the first instance), so it might be worth a couple more words to clarify the nature of the potential interference. Section 3 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 Section 6 for more details. (side note?) I think the precise story here is a little subtle -- for any given key, the imported and non-imported identities are distinct, but in principle one could construct a non-imported identity that overlaps with an imported identity for a different key (and we say as much at the end of Section 7). This is vanishingly rare to happen by chance, but makes the statement as written not quite categorically true. That said, the change to the binder key derivation (§ 4.2) seems to obviate any potential consequences to such a collision (though the connection attempt would presumably fail). Endpoints which import external keys MUST NOT use either the external keys or the derived keys for any other purpose. Moreover, each IIUC, this is "MUST NOT use the keys that are input to the import process for any purpose other than the importer, and MUST NOT use the derived keys for any purpose other than TLS PSKs". Is it worth spelling it out explicitly like that? external PSK MUST be associated with at most one hash function, as per the rules in Section 4.2.11 from [RFC8446]. See Section 7 for more discussion. Does this requirement apply to the inputs to the importer process, the outputs, or both? Section 3.1 Imported PSK (IPSK): A PSK derived from an EPSK, External Identity, optional context string, target protocol, and target KDF. There is an "External Identity" that is contained within the EPSK itself; is the "External Identity" listed here distinct from that?