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

[Michael StJohns <[e-mail]>]

On 9/25/2013 5:08 AM, Paul Bakker wrote:
>> 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.
> Wouldn't using the 'ciphersuite id' in the KDF provide the same (as the
> ciphersuite determines all those values) and is simpler in the process?
>

Considered that, but that would mean that a PKCS11 implementation would 
need to have the mapping between each and every TLS ciphersuite and the 
composition of its keys.  That would mean that each time a new cipher 
suite ID was issued, PKCS11 implementations would have to change.  Not 
the most general solution.

There's also this problem that the pre-master mechanism can be used for 
many different ciphersuites - and figuring out how to make sure policy 
controls apply to the downstream (master, key expansions, etc) keys is a 
pain.

Mike