Change:
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> <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 <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> <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.

Discussion:
, 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).