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

[Martin Rex <[e-mail]>]

Bodo Moeller wrote:
> 
> 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"?   

Yes.  See my proposal in the first message of the thread
"Protected Renegotiation -- refined proposal"

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

I would strongly recommend against several different methods of
signaling.  It will be more work for implementors, more to interop-test
more to get wrong.  Just one signal for existing protocol specs
SSLv3 -> TLSv1.2 is perfectly sufficient.  Implied new behaviour
with TLSv1.3 is fine.


-Martin