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

From: Michael StJohns <[email-masked]>
Date: Sat, 21 Sep 2013 15:29:51 -0400

Following up on the previous discussion, I propose the following changes 
to the key derivation steps for TLS.  This adds a length field for each 
key being derived to the PRF seed value.  For the pre-master to master 
secret derivation, this is a single 32 bit length field of value 48.  
For the master to key expansion derivation, these are 6 32 bit fields 
each representing the length of one of the keys (or IVs to be derived).

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

As a side note, most of the KDFs spec'd by NIST require the key length 
to be included as part of the public information fed into the Key 
Derivation Function (KDF).

Mike

>       Computing the Master Secret
>
>
>
>     For all key exchange methods, the same algorithm is used to convert
>     the pre_master_secret into the master_secret.  The pre_master_secret
>     should be deleted from memory once the master_secret has been
>     computed.
>
>        master_secret = PRF(pre_master_secret, "master secret",
>                            ClientHello.random + ServerHello.random +
48  (expressed as 32 bit NBO)
> )
>                            [0..47];
>
>     The master secret is always exactly 48 bytes in length.  The length
>     of the premaster secret will vary depending on key exchange method.

Key Calculation
> When keys and MAC keys are generated, the master secret is used as an
>     entropy source.
>
>     To generate the key material, compute
>
>        key_block = PRF(SecurityParameters.master_secret,
>                        "key expansion",
>                        SecurityParameters.server_random +
>                        SecurityParameters.client_random +
SecurityParameters.mac_key_length +
SecurityParameters.mac_key_length +
SecurityParameters.enc_key_length +
SecurityParameters.enc_key_length +
SecurityParameters.fixed_iv_length +
SecurityParameters.fixed_iv_length
> );
>
>     until enough output has been generated.  Then, the key_block is
>     partitioned as follows:
>
>        client_write_MAC_key[SecurityParameters.mac_key_length]
>        server_write_MAC_key[SecurityParameters.mac_key_length]
>        client_write_key[SecurityParameters.enc_key_length]
>        server_write_key[SecurityParameters.enc_key_length]
>        client_write_IV[SecurityParameters.fixed_iv_length]
>        server_write_IV[SecurityParameters.fixed_iv_length]

---

From: Wan-Teh Chang <[email-masked]>
Date: Tue, 24 Sep 2013 18:49:58 -0700

On Sat, Sep 21, 2013 at 12:29 PM, Michael StJohns
<[email-masked]> wrote:
> Following up on the previous discussion, I propose the following changes to
> the key derivation steps for TLS.  This adds a length field for each key
> being derived to the PRF seed value.  For the pre-master to master secret
> derivation, this is a single 32 bit length field of value 48.  For the
> master to key expansion derivation, these are 6 32 bit fields each
> representing the length of one of the keys (or IVs to be derived).
>

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

---

From: Michael StJohns <[email-masked]>
Date: Tue, 24 Sep 2013 23:36:10 -0400

> Could you elaborate on how your proposed change affects the TLS keying

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

---

From: "Paul Bakker" <[email-masked]>
Date: Wed, 25 Sep 2013 11:08:28 +0200

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

---

From: Michael StJohns <[email-masked]>
Date: Wed, 25 Sep 2013 11:22:47 -0400

> 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