Change:
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> <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, <del> that means ALPN, QUIC transport parameters (if used for QUIC), etc., must be provisioned alongside these EPSKs. </del> <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.

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).