Re: [TLS] Thoughts on Hardware Support

[Michael StJohns <[e-mail]>]

A private message indicated that it might be useful if I clarified my 
thoughts below.  The problem is the embedded use of the term "IV" in the 
TLS documents.

The master_secret expansion (section 6.3 of rfc5246) still refers to the 
last part of the data generated as IVs - but TLS1.2 eliminated the use 
of these as actual IVs (plus implicit generation of per-message IVs) for 
the existing non-AEAD, non-counter modes in favor of explicit 
per-message randomly generated IVs.

The AEAD ciphersuite documents resurrected the use of the iv data from 
the master secret expansion for use as the per-key (identical for all 
TLS messages in a session) nonce.


pure IVs (mostly - check the specific mode) require unpredictability.  
Nonces (at least for defined modes) only require uniqueness on a per-key 
basis.

Where the mode needs per-message IV unpredictablity, follow section 
6.2.3.2 of the TLS1.2 RFC.  Where you need to establish a common unique 
nonce, use an entropy expansion/extraction from client/server random 
without dependency on key material.  There shouldn't be any middle cases.

Mike


On 2/14/2015 3:24 PM, Michael StJohns wrote:
> On 2/14/2015 2:23 PM, Watson Ladd wrote:
>> I think the easiest way is to eliminate the IV derivation entirely,
>> and have the record layer send the entire nonce each time. if that's
>> too much a waste of bandwidth, then we can specify entirely the
>> portion that is in TLS 1.2 derived from the MS. I think this is in
>> spirit similar to his proposal, but I don't recall the exact details.
>
> The other way of doing this is to not make IV derivation dependent on 
> secret material.  Basically, I suggested that instead to use the same 
> KDF function, but with a key of zero and a context of the server and 
> client randoms.  That makes IV (or for most AEAD counter based 
> thingies - nonce) derivation a straightforward entropy extraction from 
> the two generated random numbers. Alternately, use output of the hash 
> of those two concatenated values plus a counter (so you can get more 
> than 1 block of extracted data) plus a label (so you can use the same 
> randoms for different expansions if you need to).
>
>
> E.g.
>
>
> IVDATA = {};
> label = { <some number of well known bytes> };
> numblocks = CEIL (numBytesNeeded/hashOutputSize);
>
> for (i = 1; i < numblocks; i++) {
>     IVDATA = IVDATA || HASH (counter(as uint32 big endian) || label || 
> serverRandom || clientRandom);
> }
>
> return LTRUNC(IVDATA, numBytesNeeded);
>
>
> This uses all public data and functions to produce public data (the IV 
> or Nonce).
>
>
> I apologize as I haven't had the cycles to do a pull request and add 
> the crypto constructs changes I'm proposing.
>
> Mike
>
>
>