Re: [TLS] Re: Open Issue: verify_data processing

[David Hopwood <david.nospam.hopwood@xxxxxxxxxxxxxxxx>]

Simon Josefsson wrote:
> 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.
>>
>>  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.

Please, no. Not only does this unnecessarily complicate the protocol and
its security analysis, it gives an attacker more options as to what to
attack.

(In general, adding negotiated alternatives as to how the handshake is
*verified* is a bad idea. Just decide on one of the possibilities; that
will almost never be worse than negotiation from a security point of view.)

-- 
David Hopwood <david.nospam.hopwood@xxxxxxxxxxxxxxxx>



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