[TLS] Finished message hash length/algorithm (was RE: draft-turner-ssl-must-not)

["Brian Smith" <[e-mail]>]

Marsh Ray wrote:
> On Tue, Jul 06, 2010 at 04:17:14AM +0200, Martin Rex wrote:
> > Personally, I dislike the extreme truncation of the Finished messages
> > in TLS to 12 octets. My expectation is that this limits the overall
> > strength, and that it spoils the use of SHA-2 in TLSv1.2.
> 
> +1.
> 
> There's no logic to it, or whatever there might be is too clever by half.
> 
> Apparently, someone was convinced that collision resistance was
irrelevant. So
> convinced that they were willing to bet your data on it and not use
another 8 or
> so bytes to transmit the full hash that had already been computed. I
wonder if
> they realized that higher layer protocols were attaching semantic value to
the
> receipt of the Finished message.
> 
> But since their reasoning didn't make it into the RFCs so we must live
without it
> when reviewing things like False Start/Snap Start.
> It'd be nice to know what other unstated dependencies and assumptions the
> security rests on.

This is an easy problem to solve, if it is a problem:

1. Define a new extension that allows the client to request a Finished
message that is truncated to a different length.

2. Make False Start / Snap Start require this extension be used.

Such an extension could even switch the finished hashes and/or the PRF from
SHA-256 to a more efficient algorithm like GHASH. This would eliminate the
performance penalty of switching from TLS 1.0/1.1 to TLS 1.2 if widely
deployed.

Regards,
Brian