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

Marsh Ray <marsh@extendedsubset.com> Tue, 06 July 2010 15:39 UTC

Message-ID: <4C334E3C.3040704@extendedsubset.com>
Date: Tue, 06 Jul 2010 10:39:40 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4
MIME-Version: 1.0
To: Brian Smith <brian@briansmith.org>
References: <003001cb1d1b$7d279660$7776c320$@briansmith.org>
In-Reply-To: <003001cb1d1b$7d279660$7776c320$@briansmith.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: 'Marsh Ray' <marsh@xs01.extendedsubset.com>, tls@ietf.org
Subject: Re: [TLS] Finished message hash length/algorithm (was RE: draft-turner-ssl-must-not)
Precedence: list

On 07/06/2010 09:56 AM, Brian Smith wrote:
>
> 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.

That may or may not help. Since the Finished message is what provides 
integrity protection for the handshake, if the attacker can defeat the 
96 bit hash he can probably alter the hello messages so the extension 
isn't negotiated.

> 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.

Perhaps there's something to be said for a hash function not living on 
the bleeding edge of performance?

- Marsh

[TLS] Finished message hash length/algorithm (was… Brian Smith
Re: [TLS] Finished message hash length/algorithm … Marsh Ray