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