On Tue, Sep 17, 2019, at 7:03 PM, Martin Thomson wrote: > 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'.
It was an editorial thing meant to help disambiguate keys. We can probably clean this up. > > > 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. Great! I'll draft a PR with this restriction that builds on https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/18. > > > 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. Assuming you're referencing imported keys by "these", the identity sent on the wire is the constructed ImportedIdentity structure. I'll try to make that more clear. > > 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. Agreed. A downside here is that we're then forced into a registry for the KDFs. I'd prefer referencing something like HPKE for that. > > > 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. Ah, so, I think this is where the miscommunication is happening! The target KDFs I've been envisioning are not protocol specific. So, we wouldn't use the TLS 1.2 PRF. We'd just use the identifier for HKDF-SHA256, or whatever. (Since the hash algorithm is what's important, and is effectively what identifies the TLS 1.2 PRF, I don't see the need to specifically reference the 1.2 PRF. It seems we can just target a hash-specific KDF.) In an attempt to clarify my mental model, here's a proposal of I mean. First, define ImportedIdentity as follows: ~~~ struct { opaque external_identity<1...2^16-1>; opaque context<0..2^16-1>; uint16 protocol; uint16 kdf; } ImportedIdentity; ~~~ And then define the KDF registry (here or elsewhere) as: ~~~ | KDF Name. | KDF ID | ---------------------------- | HKDF-SHA256 | 0x0001 | | HKDF-SHA384 | 0x0002 | | ... | ... | // maybe add one for the MD5+SHA1 PRF ~~~ Then, when importing one PSK for TLS 1.2 and 1.3, targeting SHA256, we'd import two keys: one with ImportedIdentity.protocol = 0x0303 and ImportedIdentity.kdf = 0x0001, and another with the same KDF identifier but ImportedIdentity.protocol = 0x0304. If I'm still missing your point (or if the preceding proposal is simply wrong!), can you update the text above or propose new text to clarify? Thanks again for the continued discussion. Best, Chris _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
