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