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

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