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

[Michael StJohns <[e-mail]>]

On 4/26/2015 8:23 PM, Watson Ladd wrote:
>
> > If I call the HSM version of the same KDF with the same key, context 
> and label and tell it to produce a single HMAC-SHA256 key of length 8 
> bits I will get a single byte of key stream which is identical to your 
> call above.   Using the TLS 1.2 KDF I can even tell it to not produce 
> any key material but to provide me with IVs - which have the same key 
> stream material as from your call.  All because the length and types 
> of the keys to be produced are not mixed into the key stream 
> production calculation.
> >
>
> But the context told you what key I wanted, and how I was going to use 
> it. Why is that easier to enforce then one time use? I'm also not sure 
> why we want to protect non cert keys in an HSM: the attacker can 
> always use the HSM to decrypt.
>

This is a good question from a different direction.

In general, HSMs don't do "one time use" except as buried inside 
compound functions (e.g. the fake key pair inside an ECDSA signature).  
And it may be difficult to ensure the key is zeroized before an attacker 
can use it.    I'd rather not depend on ephemeralness as I expect 
different HSM implementations to deal with that differently.   Doing it 
by getting the derivation process correct stands a better chance of 
getting good implementations in HSMs.

In the current model, the context says how the user wants to use the 
key, but it doesn't constrain the HSM to use it that way or even to 
constrain it to produce a specific type and length of key - those are 
user inputs.  And in TLS1.2 and before the master_secret is used 
multiple times.

To the HSM, current TLS context is opaque unstructured data that gets 
mixed in without affecting the key stream to key assignment process.

With respect to protecting non-cert keys:  think about extracting the 
master secret and using steganography to hide it inside a picture on 
non-encrypted side of the server (or even the encrypted side if publicly 
available).  An attacker can retrieve that, capture the traffic stream 
externally, derive the session keys and capture the traffic safely 
remote without the betraying large amount of stolen data wandering past 
the server interface.  The attack can even forge data in the stream.  
This is obviously a made up example, but it was the first way I thought 
of using this - but consider that if an attacker can extract the master 
secret he can send it off to someone who can read the stream externally 
either in real time or later.


Later, Mike