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

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

Marsh Ray wrote:
> Dr Stephen Henson wrote:
>> Marsh Ray wrote:
>>> 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.
>> 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.
> 
> PKCS#11 looks like it defines structures for CK_SSL3_KEY_MAT_PARAMS and
> CK_SSL3_KEY_MAT_OUT (these are also used by TLS).
> 

Yes, it provides handles to the keys but the keys are not necessarily
accessible. Some applications set the parameters so the keys are never
extractable for security reasons. Some security standards *require* that keys
can never leave the token.

That kind of thing causes problems with adding new algorithms (or algorithms
with new inputs). Changing the inputs (as opposed to adding new ones) is less
likely to cause a problem.

Adding new mechanisms or modifying existing ones in incompatible ways is
problematical if there is another standards process where it all has to be
approved/discussed. If the hardware is FIPS 140-2 validated and needs a new
validation to add a new mechanism that's a real pain.

As regards PKCS#11 I'm wondering if the use of interfaces like C_DecryptVerify()
(which improve throughput by decrypting and MACing in one go) places additional
restrictions on what can be done. I'm thinking here if they cause problems with
feeding additional data into a handshake which isn't part of the actual
handshake and might mess up state with e.g. stream ciphers.

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.