Re: [TLS] New Key derivations for TLS1.3

[Michael StJohns <[e-mail]>]

On 9/24/2013 9:49 PM, Wan-Teh Chang wrote:
>> >By doing this, varying the length of any one of the sub keys completely
>> >changes the key stream.  That prevents the type of attack described by
>> >Juraj.
> I like this proposal!
>
>> >I spec'd 6 fields for the key expansion derivation instead of three to make
>> >this completely general - and to allow it to be used with the key material
>> >export RFCs.
> Could you elaborate on how your proposed change affects the TLS keying
> material exporter RFCs?
>
> Thanks,
> Wan-Teh Chang
>
>

Simply by adding the length fields to the KDF inputs used with the key 
material exporters.  So if an exporter needs 4 keys, there are 4 length 
values, 2 keys, 2 length values etc.   That makes what gets passed into 
the KDF the secret, the public values including the label,  and the 
length of each key and that construct can be used for the pre-master to 
master, master to key expansion and for any key exporters.  This is just 
an off-the-cuff suggestion at this point.

One other alternative is to only provide lengths for keys - anything 
after the end of the keys is public data.   That allows the 
private/public division  of data consistent with the current model 
without having to build a special function just for the key-expansion 
step.  And -  if you run this without providing any key lengths, you end 
up with the same key stream as the old function -and that simplifies the 
PKCS11 implementation.

Mike