Re: [TLS] Thoughts on Hardware Support

[Ilari Liusvaara <[e-mail]>]

On Sat, Feb 14, 2015 at 11:23:30AM -0800, Watson Ladd wrote:
> Dear all,
> 
> A while ago I promised Michael St. Johns to think hard about his goal
> of making it possible to use hardware to secure the record layer
> without dirty hacks. For those unaware of the problem, the same key is
> used to derive encryption keys that shouldn't go out on the wire, and
> IVs that do, and so it becomes difficult to ensure that keys can't be
> leaked, if you expose the IV generation.

IVs derived from keys do not go on the wire, at least not in any AEAD
cipher defined for TLS I have seen.

The schemes I am aware have two styles here:

1) First 4 octets are fixed per connection (derived from MS), the
   remaining 8 are given for each record (too short for nondeteministic
   operation!).
2) First 4 octets are fixed per connection (derived from MS), the
   remaining 8 are taken from RSN+epoch (saves 8 octets/record).


IIRC, the problem was that by specifying garbage parameters for key
derivation, it was possible to get the key as IV.

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

I think his proposal was to feed the key derivation parameters (complete
with key types) to the PRF (and doing odd things with the IV).

But if one has typed keys, one can easily define a IV type and use that
for IVs (safe if the PRF is any good).


So I think the simplest fix would be to append a array of (type, length)
descriptors to the current client and server randoms in seed for the
subkeys PRF invocation (no need for length of array).

E.g.
<type byte, 0=>AEAD key, 1=>IV, others reserved>
<bit-7-mpint (shortest) length for subkey in bytes>


For AES-128-GCM:
<server random, 32 bytes>    //As currently
<client random, 32 bytes>    //As currently
00 10          //AEAD encryption subkey, 16 bytes.
00 10          //AEAD encryption subkey, 16 bytes.
01 04          //IV, 4 bytes.
01 04          //IV, 4 bytes.

(Total of 72 bytes).

For AES-256-GCM and CHACHA-POLY1305:
<server random, 32 bytes>    //As currently
<client random, 32 bytes>    //As currently
00 20          //AEAD encryption subkey, 32 bytes.
00 20          //AEAD encryption subkey, 32 bytes.
01 04          //IV, 4 bytes.
01 04          //IV, 4 bytes.

(Total of 72 bytes).

For XXX-1024-HMAC-YYY256 (128 byte keys, 32 byte IVs):
<server random, 32 bytes>    //As currently
<client random, 32 bytes>    //As currently
00 80 01        //AEAD encryption subkey, 128 bytes.
00 80 01        //AEAD encryption subkey, 128 bytes.
01 20           //IV, 32 bytes.
01 20           //IV, 32 bytes.

(Total of 74 bytes).


-Ilari