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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
