On Wed, Sep 18, 2019, at 00:56, Christopher Wood wrote: > > In thinking about the first point, we might want to consider whether > > the KDF that is used in the importer might need to be used in other > > ways. > > To be clear, you're referring to HKDF and its role in deriving ipsk > from epsk, right?
Right. Though I see epsk -> ipskx in the draft. Not sure why that has an 'x'. > I agree. We can state something along the lines of "clients MUST NOT > use an external TLS PSK for any other purpose." And also say that > external PSKs can only be associated with a single hash function. As > you mention above and in your followup message, if this isn't done, > then a client may import the same IKM using different hash functions. > > Is this what you had in mind? Yeah. `epsk` can only be used for importation into TLS using this mechanism and only with a single hash function. > Right. Tricky and likely impossible. There's nothing stopping someone > from crafting a PSK with an identity which matches an ImportedIdentity, > and then advertising that on the wire. We can't stop all the bad ideas :) One thing that bothers me a little: how did you plan to identify these? I imagine that you would only need to identify the epsk in the TLS handshake. You don't plan to use some derived means of identification, do you? The doc is light on details here and could probably use some text on this point. > I suspect you meant "KDF identifier" here? (The proposal below uses the > TLS version and a KDF identifier. It could also use the TLS version and > a HashAlgorithm value. Using a KDF identifier is probably more future > proof, though.) Yeah, a KDF identifier is more robust, for sure. It is probably not coincidence that version+hash is enough for now, but we can be a tad more general in the interests of making this more robust. > Sure, it's possible, though I think that's already done? Was there > something below or in the draft that made you think otherwise? Probably just the discussions on GitHub and the lack of discrete identifiers for the TLS 1.2 KDFs in the IANA section. If we're identifying KDFs, then we should identify TLS 1.2 KDF separately from the TLS 1.3 ones. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
