I submitted these as an Issue in the repo: https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/37
spt > On Oct 1, 2020, at 16:22, Roman Danyliw <r...@cert.org> wrote: > > ** 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). _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
