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

["Paul Bakker" <[e-mail]>]

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