Re: [TLS] Consensus call for keys used in handshake and data messages

[Ilari Liusvaara <[e-mail]>]

On Mon, Jun 20, 2016 at 11:43:41PM -0400, Dave Garrett wrote:
> 
> An idea for an option 4: Keep typing and keying as it currently is
> (as of draft 13), but mandate a KeyUpdate immediately following
> (and/or before) non-application traffic. We already have a mechanism
> to use different keys in series, which sounds like it might be
> simpler than trying to figure out a good way to do so in parallel.
>
> Is this a viable thought to pursue, or does this still not help
>enough with our key separation worries? An additional thought
> might be adding a random to KeyUpdate to make the new key not
> based entirely on the old entropy.

I don't think that would work. AFAIK, Basically using the appdata keys
for anything else (and you do in the idea) breaks generic security.

Of course, that generic security breaks does NOT imply that actual
protocol security breaks, since for that one must actually make the
actual protocol misuse the keys (and no reasonable way to do so is
known for draft-13).

And devising one seems very hard, since the operations you can try to
misuse (and all are outside normal message space) are:
- Rekey one direction of connection with a fresh key (key_update).
- Request a certificate, send a certificate and proof of key holding
  (certificate_request, certificate, certificate_verify, finished)
- Send a handle into separate dynamic PSK (new_session_ticket).

And none of those seems to lend itself to misusing the key (the
second has other known problems, but even fully separating the
keys would not fix that).


-Ilari