Original text:
that each PSK only be used with a single hash function.  This was 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 <del> and the TLS 1.2 PRF.  While there is no known way in which the same external PSK might produce related output in TLS 1.3 and prior versions, only limited analysis has been done.  Applications SHOULD provision separate PSKs for TLS 1.3 and prior versions when possible. </del>  To mitigate against any interference, this document specifies a PSK Importer interface by which external PSKs may be imported and <del> subsequently bound to a specific KDF and hash function for use in (D)TLS 1.3.  In particular, it describes a mechanism for differentiating external PSKs by the target KDF, (D)TLS protocol version, and an optional context string.  This process yields a set of candidate PSKs, each of which are bound to a target KDF and protocol, that are separate from those used in (D)TLS 1.2 and prior versions.  This expands what would normally have been a single PSK and identity into a set of PSKs and identities. </del>  2. Target KDF: The KDF for which a PSK is imported for use. Imported PSK (IPSK): A PSK derived from an EPSK, External <del> Identity, optional context string, and target protocol and KDF. </del>  Imported Identity: A sequence of bytes used to identify an IPSK. protocol "target_protocol" and KDF "target_kdf", the importer constructs an ImportedIdentity structure as follows: <del> The list of "target_kdf" values is maintained by IANA as described in 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 incremental deployment. </del>  ImportedIdentity.context MUST include the context used to derive the EPSK, if any exists.  For example, ImportedIdentity.context may Selfie-style reflection attacks Selfie.  See mitigate-selfie for more details.  If the EPSK is a key derived from some other protocol or sequence of protocols, ImportedIdentity.context MUST include a <del> channel binding for the deriving protocols RFC5056. </del>  ImportedIdentity.target_protocol MUST be the (D)TLS protocol version for which the PSK is being imported.  For example, TLS 1.3 RFC8446 <del> and QUICv1 QUIC use 0x0304.  Note that this means future versions of TLS will increase the number of PSKs derived from an external PSK. </del>  Given an ImportedIdentity and corresponding EPSK with base key "epsk", an Imported PSK IPSK with base key "ipskx" is computed as The hash function used for HKDF RFC5869 is that which is associated with the EPSK.  It is not the hash function associated with ImportedIdentity.target_kdf.  If no hash function is specified, <del> SHA-256 MUST be used.  Diversifying EPSK by </del>  ImportedIdentity.target_kdf ensures that an IPSK is only used as input keying material to at most one KDF, thus satisfying the requirements in RFC8446.  See security-considerations for more if TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 are supported, only one derived key is necessary. <del> 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, <del> that means ALPN, QUIC transport parameters (if used for QUIC), etc., must be provisioned alongside these EPSKs. </del>  4.2. 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. <del> Indeed, this is necessary for incremental deployment. </del>  7. external PSKs used in (D)TLS 1.2 and below.  However, only limited analysis has been done, which is an additional reason why applications SHOULD provision separate PSKs for (D)TLS 1.3 and prior <del> versions when possible, even when the importer interface is used in (D)TLS 1.3. </del>  The PSK Importer does not prevent applications from constructing non- importer PSK identities that collide with imported PSK identities.

Reviewer comments:
, and . cc NAME
Reviewer: Al Morton Review result: Has Nits OPS-DIR Review of: Importing External PSKs for TLS draft-ietf-tls-external-psk-importer-05 Note that Brian Carpenter provided a useful review for GEN-ART, far beyond general questions. Brian's comments on Section 6, Incremental Deployment, are relevant to operational considerations, which are the focus of this review. The draft provides a useful capability and considers possible issues stemming from interaction with (D)TLS 1.2. There are some implementations and other parties are interested. Nits: Intro:not expanded on first use PRF KDF Terminology: one-too-many "and" in: ... Imported PSK (IPSK): A PSK derived from an EPSK, External Identity, optional context string, and target protocol and KDF.
Nits in the introduction are also listed in Roman's review. section 3.1 should be updated.
Document: draft-ietf-tls-external-psk-importer-05 Reviewer: Brian Carpenter Review Date: 2020-10-07 IETF LC End Date: 2020-10-15 IESG Telechat date: Summary: Ready with issues Issues: >1. Introduction I think that "when possible" could easily be used as a loophole by a lazy implementer. ("Impossible, because I'd have to refactor my code.") Since presumably this rule is to avoid all risk of a "related output" cryptanalytic vulnerability, why weaken the RFC2119 definition of SHOULD? The formal definition of SHOULD is stronger, with "the full implications must be understood and carefully weighed before choosing a different course." So I suggest simply deleting "when possible". >6. Incremental Deployment I read this three times and I have to ask whether "TLS 1.2" is really what you want in the penultimate line. Nits: >4.1. External PSK Diversification ... As far as I can tell, [QUIC] doesn't specify this, but draft-ietf-quic-tls does specify that QUICv1 uses TLS1.3. So the phrasing is a bit misleading. Maybe: For example, TLS 1.3 [RFC8446] uses 0x0304, which will therefore also be used by QUICv1 [QUIC-TLS]. Are all the RFC2119 terms capitalised when required? For example, there are lower case 'may' and 'must' in the last paragraph of section 4.1 (External PSK Diversification). I couldn't determine whether they were intended to be normative.
Section 1. Editorial. Expand acronym on first use: -- s/TLS 1.2 PRF/TLS 1.2 Pseudorandom Function (PRF)/ -- s/KDF/Key Derivation Function (KDF)/ Section 1. Editorial. Since the text says "... this document specifies a PSK Importer interface ... for use in D(TLS 1.3)" perhaps the this scoping should also be upfront in the first sentence too: s/TLS 1.3 [RFC8446] supports/(D)TLS 1.3 [RFC8446][ID-DTLS]/ Section 4.1. Editorial. Per "The list of 'targetkdf' ...", other parts of this text refer to elements of struct ImportIdentity with the notation "ImportedIdentity.". Consider s/The list of "targetkdf" values/The list of ImportedIdentity.targetkdf values/ Section 4.1. If the EPSK is a key derived from some other protocol or sequence of protocols, ImportedIdentity.context MUST include a channel binding for the deriving protocols [RFC5056]. To the end of this normative guidance, I'd recommend adding something to the effect of: "The details of this binding will be protocol specific and out of scope in this document". Section 4.1. Per "If no hash function is specified, SHA-256 MUST be used" -- Please provide a reference for SHA-256 (per "... If no hash function is specified, SHA-256 MUST be used"). -- It is likely worth saying that this is the equivalent of HKDFSHA256 (i.e., 0x0001) Section 4.1. Per "EPSKs may be imported before the started of the connection ..." and "EPSKs may also be imported for early data use ..." should be these be a normative MAYs? Section 4.1. Per "Minimally, that means ALPN, QUIC ... must be provisioned alongside these EPSK" -- Please expand ALPN -- should this be a normative MUST? Section 9. Per the columns in the registry: -- Is there a reason why there isn't a Reference column in the registry to capture which specification describes the particular KDF? I think it needs one to eliminate guesswork from the label in "KDF Description" to an algorithm. -- Was a Recommended column (and the associated processed for populating it like a few of the other TLS registries) discussed/considered? Section 9. While it is implied by the label, the text doesn't explicitly say what HKDFSHA256 and SHA384 are (per previous comment about needing a reference).

Revised text:
that each PSK only be used with a single hash function.  This was 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  <ins> and the TLS 1.2 pseudorandom function (PRF).  While there is no known way in which the same external PSK might produce related output in TLS 1.3 and prior versions, only limited analysis has been done. Applications SHOULD provision separate PSKs for TLS 1.3 and prior versions. </ins> To mitigate against any interference, this document specifies a PSK Importer interface by which external PSKs may be imported and  <ins> subsequently bound to a specific key derivation function (KDF) and hash function for use in TLS 1.3 RFC8446 and DTLS 1.3 DTLS13.  In particular, it describes a mechanism for differentiating external PSKs by the target KDF, (D)TLS protocol version, and an optional context string.  This process yields a set of candidate PSKs, each of which are bound to a target KDF and protocol, that are separate from those used in (D)TLS 1.2 and prior versions.  This expands what would normally have been a single PSK and identity into a set of PSKs and identities. </ins> 2. Target KDF: The KDF for which a PSK is imported for use. Imported PSK (IPSK): A PSK derived from an EPSK, External  <ins> Identity, optional context string, target protocol, and target KDF. </ins> Imported Identity: A sequence of bytes used to identify an IPSK. protocol "target_protocol" and KDF "target_kdf", the importer constructs an ImportedIdentity structure as follows:  <ins> The list of ImportedIdentity.target_kdf values is maintained by IANA as described in 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 incremental deployment. </ins> ImportedIdentity.context MUST include the context used to derive the EPSK, if any exists.  For example, ImportedIdentity.context may Selfie-style reflection attacks Selfie.  See mitigate-selfie for more details.  If the EPSK is a key derived from some other protocol or sequence of protocols, ImportedIdentity.context MUST include a  <ins> channel binding for the deriving protocols RFC5056.  The details of this binding are protocol specific and out of scope for this document. </ins> ImportedIdentity.target_protocol MUST be the (D)TLS protocol version for which the PSK is being imported.  For example, TLS 1.3 RFC8446  <ins> uses 0x0304, which will therefore also be used by QUICv1 QUIC.  Note that this means future versions of TLS will increase the number of PSKs derived from an external PSK. </ins> Given an ImportedIdentity and corresponding EPSK with base key "epsk", an Imported PSK IPSK with base key "ipskx" is computed as The hash function used for HKDF RFC5869 is that which is associated with the EPSK.  It is not the hash function associated with ImportedIdentity.target_kdf.  If no hash function is specified,  <ins> SHA-256 SHA2 MUST be used.  Diversifying EPSK by </ins> ImportedIdentity.target_kdf ensures that an IPSK is only used as input keying material to at most one KDF, thus satisfying the requirements in RFC8446.  See security-considerations for more if TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 are supported, only one derived key is necessary.  <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 </ins> 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,  <ins> 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. </ins> 4.2. 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.  <ins> 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. </ins> 7. external PSKs used in (D)TLS 1.2 and below.  However, only limited analysis has been done, which is an additional reason why applications SHOULD provision separate PSKs for (D)TLS 1.3 and prior  <ins> versions, even when the importer interface is used in (D)TLS 1.3. </ins> The PSK Importer does not prevent applications from constructing non- importer PSK identities that collide with imported PSK identities.