Re: [TLS] confirming the room’s consensus: adopt HKDF PRF for TLS 1.3

[Ilari Liusvaara <[e-mail]>]

On Tue, Apr 28, 2015 at 01:48:35AM -0400, Hugo Krawczyk wrote:
> Mike, thanks a lot for the clear explanation!
> I think I can now understand the issues you were raising. Sorry for my
> ignorance.
> 
> One thing I (think I) understand now is that this discussion had little to
> do with HKDF (specifically) but rather has to do with the inputs to the KDF
> function defined by the calling protocol, say TLS 1.3.
> 
> We can define TLS 1.3 so that calls to HKDF will always include a info
> string composed of:
> label, context (say, session-hash) and the length L of the output key
> material.
> Now, in the HSM implementation you will read the values label and context
> from the user's input but L will  be added by the HSM itself by calculating
> the length of the required key. In non-HSM implementations the software
> will add L.

I think some proposals also had key usage for derived key as an input.

Some examples of possible usages:
- KDF input key (e.g. handshake master secret)
- AES-GCM key
- AES-CCM key
- AES-CCM8 key
- Chacha20-Poly1305 key
- HMAC-SHA256 key (MAC-only key)
- Initial IV (you have other exportables anyway)
- Exportable octet string (e.g. the unique output)


This doesn't look too difficult to add (e.g. just stick as two first
octets of info or something).


-Ilari