[TLS] Re: Open Issue: verify_data processing

[Simon Josefsson <jas@xxxxxxxxxxx>]

Vipul Gupta <Vipul.Gupta@xxxxxxx> writes:

> On Oct 17, 2006, at 2:55 PM, Wan-Teh Chang wrote:
>
>> Eric Rescorla wrote:
>>> The argument against is that it puts the security of the handshake
>>> on an unkeyed hash rather than a MAC (since you only need to mount
>>> a 2nd preimage attack on the hash
>>> and then you have 2nd preimage on MAC(K,hash).).
>>
>> You can use this argument against RSA, DSA, and ECDSA
>> signatures, too.
>>
>> My preference is to hash the handshake_messages first.
>> The issue isn't that new PRFs can't cope with large data.
>> The issue is the new burden on TLS implementations to buffer
>> data of an indefinite length. Also consider the memory usage
>> of a busy TLS server that has a lot of handshakes in progress.
>>
>> Wan-Teh
>
>   I would also prefer hashing. Our research team has successfully
> created a TLS stack for tiny, wireless sensor devices like the
> Berkeley "motes" with only 4KB of RAM (see
> http://research.sun.com/spotlight/2004-12-20_vgupta.html
> http://research.sun.com/projects/crypto/guptav_sizzle_pmc.pdf).
> If the spec were modified to require storing the handshake messages
> in full, then TLS (and derivatives like DTLS) would pretty much
> be ruled out for this emerging class of devices.

One idea would be to make it possible to negotiate whether to hash the
handshake messages or not.

Perhaps by having the ciphersuite implies that a particular PRF is
used with or without hashing.

Personally, I would prefer to use the entire handshake messages as
input to the PRF, but I agree that you have a compelling argument to
hash them.

/Simon

_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls