Re: [TLS] Binding imported PSKs to KDFs rather than hash functions

["Christopher Wood" <[e-mail]>]

Hi Martin,

Thanks for the reply! Please see inline below.

On Mon, Sep 16, 2019, at 6:26 PM, Martin Thomson wrote:
> There are two points here to consider:
> 
> 1. Whether the key that we are feeding into this process is going to be 
> used exclusively for that purpose, or whether it might be used for 
> something else.
> 
> 2. How the key that is output from this process might need diversification.
> 
> What we learned from TLS 1.3 is that HKDF is effectively a completely 
> different KDF when it is used with a different hash function.  And that 
> taking the same key into two different functions was not advisable 
> because there isn't a lot of analysis to support that particular usage 
> pattern.
> 
> 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?

> Personally, when I see the question formulated this way, I am 
> inclined to suggest that this key should be used exclusively for key 
> import.  If that's the decision, that should be made very clear.

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?

> If we decide that we're gaining exclusive access, then the only other 
> consideration I'm aware of on the input side is the binding to the 
> origination of the key, as raised by Jonathan.  That is something we 
> might gain by integrating something into the identity, or by adding a 
> context attribute to the expansion (which might carry a session hash).  
> That concern is not reflected in the proposal here though.
>
> If you have exclusive access to the input keying material, then you can 
> very easily restrict this to HKDF.  If not, then I'd suggest that you 
> need to use the more general form.  But then you also need to ensure 
> that whatever inputs you feed into the KDF can't collide with inputs 
> for the other usages.  That's tricky.

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.

> Then the question is how we identify the diversification parameters.  
> Right now, we want to diversify outputs based on TLS version and the 
> hash algorithm associated with the cipher suite.  If this is only ever 
> used for TLS, then we have a simple process: we identify the specific 
> type of TLS PRF somehow and bake that into the KDF label.
>
> How we do that is simple mechanics: each version of TLS we care about 
> has a template KDF, which is parameterized by hash function.  As Chris 
> proposes, we could include a TLS version and a hash function 
> identifier.  That seems enough.

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.)

> The final question is about multiple PRFs in TLS 1.2.  We never 
> restricted input PSKs in TLS 1.2 to a single KDF, so in theory we could 
> use a single output of this importer function for TLS 1.2.  However, 
> I'm not sure that this is necessary if we allow for the possibility of 
> an importer.  We could use different keys depending on the final 
> selection of cipher suite (and therefore hash function).  I don't see 
> any reason not to fix TLS 1.2 PSK usage at the same time as TLS 1.3.

Sure, it's possible, though I think that's already done? Was there something below or in the draft that made you think otherwise?

Thanks again!
Chris

> 
> On Sun, Sep 15, 2019, at 00:53, Christopher Wood wrote:
> > Hi folks,
> > 
> > Martin reviewed the external PSK draft [1] and filed a couple issues 
> > [2,3] that are worth discussion here. I’d like to call attention to #16 
> > [3] in particular. 
> > 
> > TL;DR: Should we bind the importer to a KDF rather than a hash function?
> > 
> > Currently, the importer draft assumes that an external PSK is 
> > optionally associated with some hash function, and, if not, assumes 
> > SHA256. The importer uses this hash function when deriving the imported 
> > key. In particular, it’s the hash function used for HKDF-Extract and 
> > HKDF-Expand, which runs over the external PSK blob and the constructed 
> > ImportedIdentity to produce a unique, imported PSK. ImportedIdentity is 
> > the structure that contains the external PSK identity, a protocol 
> > label, and target hash function:
> > 
> > ~~~
> > struct {
> >   opaque external_identity<1...2^16-1>;
> >   opaque label<0..2^8-1>;
> >   HashAlgorithm hash;
> > } ImportedIdentity;
> > ~~~
> > 
> > The issue raised pointed out that the (protocol label, hash) tuple 
> > effectively identifies a KDF. (Martin, please correct me if I’m 
> > misinterpreting your comments!) Thus, perhaps it makes sense to replace 
> > this with something simpler, e.g., 
> > 
> > ~~~
> > struct {
> >   opaque external_identity<1...2^16-1>;
> >   uint16 protocol_version;
> >   uint16 kdf_identifier;
> > } ImportedIdentity;
> > ~~~
> > 
> > Where ImportedIdentity.protocol_version is a code point (e.g., 0x0304 
> > for TLS 1.3) and ImportedIdentity.kdf_identifier is a unique 
> > (registry-defined) KDF function (e.g., 0x0001 for HKDF-SHA256). If we 
> > did this, a couple interesting questions arise. 
> > 
> > First, should we keep using HKDF as the importer KDF? Note that the 
> > current ImportedIdentity.hash field is what diversifies imported PSKs 
> > by hash function. The actual key derivation still uses HKDF with the 
> > hash function associated with the external PSK. (SHA-256 is assumed if 
> > none is specified.) If we replaced ImportedIdentity.hash with 
> > ImportedIdentity.kdf_identifier, we would still get this 
> > diversification, since each target KDF is bound to one hash function. 
> > However, should the KDF corresponding to 
> > ImportedIdentity.kdf_identifier be the KDF used by the importer for 
> > derivation? That is, let’s say I have an external PSK "epsk" that's 
> > associated with SHA-512. Moreover, let's assume 
> > ImportedIdentity.kdf_identifier = 0xFEFE, which corresponds to some KDF 
> > called MySpecialKDF. Should the derivation step be this?
> > 
> > ~~~
> > epskx = HKDF-SHA512-Extract(0, epsk)
> > ipskx = HKDFSHA512-Expand-Label(epskx, "derived psk", 
> > Hash(ImportedIdentity), Hash.length)
> > ~~~
> > 
> > Or this?
> > 
> > ~~~
> > epskx = MySpecialKDF-Extract(0, epsk)
> > ipskx = MySpecialKDF-Label(epskx, "derived psk", 
> > MySpecialKDF.Hash(ImportedIdentity), MySpecialKDF.length)
> > ~~~
> > 
> > Or something else entirely?
> > 
> > Second, keys need to be imported for each supported ciphersuite and 
> > corresponding hash function. How would we specify that if we now speak 
> > of importers in terms of a target KDF?
> > 
> > Thanks,
> > Chris (no hat)
> > 
> > [1] https://github.com/tlswg/draft-ietf-tls-external-psk-importer
> > [2] https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/15
> > [3] https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/16
> > 
> > _______________________________________________
> > TLS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tls
> >
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>