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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
