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

[Dr Stephen Henson <[e-mail]>]

Marsh Ray wrote:
> 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.
> 

I think this will give problems for external crypto libraries like PKCS#11 where
session key derivation is a mechanism with fixed parameters and the actual keys
are not available in plain text outside the hardware. You'd need to develop a
new mechanism, add it to the PKCS#11 spec and update firmware on every piece of
crypto hardware.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.