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
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/tls
> >
>
> _______________________________________________
> TLS mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
