Re: [TLS] Redefine Finished message for TLS 1.3 ?

[Bodo Moeller <[e-mail]>]

On Nov 15, 2009, at 11:31 AM, Martin Rex wrote:
> Bodo Moeller wrote:

>> One way to avoid most of the overhead from the current ID would be to
>> keep the extension *always* empty.  If the client and server both  
>> send
>> it during any given handshake, then the Finished messages concluding
>> that handshake will be computed mostly in the standard way, but if
>> it's a renegotiation handshake, including the previous handshake's
>> Finished messages in the handshake_messages that will be hashed.
>> [Open question: Where should they go?  Maybe the easiest is to always
>> hash them at the end; client first, server second.]
>
> My suggestion: always after ServerHello.  At that point, servers
> and clients know whether they need to fallback to the old behaviour
> or not, provided that their policy/configuration should allow that.
>
> They should definitely go before the CertificateVerify message, so  
> that
> the signature with the client certificate is also securely
> cryptographically bound to the channel (I don't like the idea to
> have the CertificateVerify succeed on a MITM attack and only the  
> finished
> mac fail, if we can easily make both fail.

That's a very good point!

So we'd actually be changing the handshake_message definition not just  
for purposes of the Finished messages, but also for purposes of the  
CertificateVerify message.  We'd always pretend that the previous  
Finished messages occur in the present handshake after both Hello  
messages are done.

[Do you agree with "client Finished first, server Finished second"?   
This is the obvious order if the previous handshake was a full  
handshake -- in case if was an abbreviated handshake (i.e., resuming a  
session), however, these messages would actually have been exchanged  
in the opposite order.  *Not* following the original order in this  
case seems easier.]



>> The step up to TLS 1.3 will be easy: Just make the modified Finished
>> computation the default for the new protocol (i.e., no longer
>> requiring the extension-based negotiation).
>
> Correct!  There really is no need to keep the old, unprotected
> negotiation around in TLS v1.3.  If TLSv1.3 is proposed by the client
> and agreed to by the server, no additional signaling is necessary
> anymore.  This is why adding the verify_data to the handshake messages
> hashes (my suggestion, always after ServerHello)

By the way, it would even be possible to specify more signals that  
could be used to switch to this modified handshake_message (and thus,  
Finished.verify_data) specification.  If we assume that the extension  
is one way to enable this behavior, and the protocol version will be a  
second way, a magic ciphersuite number that new servers are expected  
to look out for could be a third option.

Bodo