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

[Martin Rex <[e-mail]>]

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.

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


-Martin