[TLS] AD review of draft-ietf-tls-external-psk-importer-05

[Roman Danyliw <[e-mail]>]

Hi!

I've assumed the role of responsible AD on this document.  As such, I performed an AD review of draft-ietf-tls-external-psk-importer-05.  All in all, it is in good shape.  My feedback is primarily around clarifying the content of the new KDF registry and a few of editorial suggestions.  Given that, I'm going to advance this document to IETF LC and the feedback below can be discussed/addressed concurrently.

** 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 'target_kdf' ...", other parts of this text refer to elements of struct ImportIdentity with the notation "ImportedIdentity.*".  Consider s/The list of "target_kdf" values/The list of ImportedIdentity.target_kdf 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 HKDF_SHA256 (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 HKDF_SHA256 and _SHA384 are (per previous comment about needing a reference).

Regards,
Roman