Authentication in TLS protocol TLS session keys are derived as a result of authenticated key agreement.

Is being able to decrypt a record at an endpoint after receiving change_cipher_spec sufficient guarantee that the endpoint is accepting record from the authenticated peer? I believe 'yes'.

I understand that the verification of TLS finished message ensures that the handshake messages were not tampered by MITM. The decryption of TLS record containing finished message proves the record arrived from authenticated peer.

In the case of extended-master-secret extension, the master secret (and hence session keys too) are derived as a function hash of handshake message (i.e. transcript hash). Therefore, if extended master secret is used, being able to decrypt records after change_cipher_spec should prove both authenticity of peer &amp; non-tampering of handshake messages.

In this case, can the handshake protocol do away with finished message without compromising on the security guarantees?
Probably, yes, just testing the first message is secure.

However, I've seen implicit authentication before in a protocol, and it is not nice to deal with it. Basically, you handle the handshake and report to the user of a library that the handshake has finished and the symmetric session keys have been generated: everything is ready to actually transport data.

If you remove the finished message from the handshake then you don't know that everything is alright. You now have to send or receive the message without knowing it should be OK. Now if you have an error then what are you going to answer to the client? Is it that the channel has become corrupted or that the handshake failed?

In this sense, an explicit verification that the handshake failed is much easier to deal with. After the handshake is verified you can simply notify that the channel has become corrupted if anything happens to it.

So yes, implicit authentication and verification of the handshake is possible. In practice, you really want to implement explicit authentication. 



An odd situation is where you would send a byte valued 00 or 01 if a condition is true and nothing if a condition is false. In the false case no data record needs to be send: but that means that the handshake is never verified!