Message-ID: <523DF6E3.70408@nthpermutation.com>
Date: Sat, 21 Sep 2013 15:43:31 -0400
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative;
 boundary="------------030300090309060304090504"
Subject: [TLS] New Key derivations for TLS1.3
Precedence: list

This is a multi-part message in MIME format.
--------------030300090309060304090504
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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]




--------------030300090309060304090504
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Following up on the previous discussion, I propose the following
    changes to the key derivation steps for TLS.&nbsp; This adds a length
    field for each key being derived to the PRF seed value.&nbsp; For the
    pre-master to master secret derivation, this is a single 32 bit
    length field of value 48.&nbsp; 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).&nbsp; <br>
    <br>
    By doing this, varying the length of any one of the sub keys
    completely changes the key stream.&nbsp; That prevents the type of attack
    described by Juraj.<br>
    <br>
    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.<br>
    <br>
    <br>
    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).<br>
    <br>
    Mike<br>
    <br>
    <br>
    <blockquote type="cite">
      <pre class="newpage"><span class="h3"><h3> Computing the Master Secret</h3></span>

   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 + </pre>
    </blockquote>
    48&nbsp; (expressed as 32 bit NBO)<br>
    <blockquote type="cite">
      <pre class="newpage">)
                          [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.</pre>
    </blockquote>
    <br>
    <br>
    <br>
    Key Calculation<br>
    <blockquote type="cite">
      <pre class="newpage">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 +</pre>
    </blockquote>
    SecurityParameters.mac_key_length +<br>
    SecurityParameters.mac_key_length +<br>
    SecurityParameters.enc_key_length +<br>
    SecurityParameters.enc_key_length +<br>
    SecurityParameters.fixed_iv_length +<br>
    SecurityParameters.fixed_iv_length <br>
    <blockquote type="cite">
      <pre class="newpage">);

   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]</pre>
    </blockquote>
    <br>
    <br>
    <br>
    <blockquote type="cite"> </blockquote>
  </body>
</html>

--------------030300090309060304090504--