[TLS] Perhaps there's another way. Was: Verify data in the RI extension?

[Marsh Ray <[e-mail]>]

Yoav Nir wrote:
> 
> As far as implementation complexity, it's a wash. You have to have
> some long-term "state", which now must include the old verify_data.
> There's no way around that.

Perhaps, but that state does not need to be more that a bit or two in
each direction for the signaling.

State derived from the previous handshake is already available at both
endpoints. It is not necessary to carry over more!

This state currently resides in:
    client write MAC secret
    server write MAC secret
    client write key
    server write key

These secure entropy within these parameters are considered sufficient
to protect all the application data, why aren't they good enough to
establish continuity-of-identity across the renegotiation?

Seems to me the MAC_secret is better than the Finished message if for no
other reason than it's 20 bytes instead of 12. Currently, all this
hard-won entropy is discarded at the CCS. A tragedy!

My proposal:

At the CCS, instead of replacing the client/server MAC secret data,
simply XOR-merge the incoming values with the previous ones.

* A one-line software change.
* Easy even in hardware.
* Preserves more entropy.
* No changes to PRF.

Please actively attempt to shoot it down.

- Marsh