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

[Sean Turner <[e-mail]>]

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 <[e-mail]> 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).