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 & non-tampering of handshake messages.

In this case, can the handshake protocol do away with finished message without compromising on the security guarantees?

  • $\begingroup$ It would make the formal analysis of the handshake even more of a nightmare than it already is, because you then lose modularity and composability guarantees and thelike. $\endgroup$ – SEJPM May 8 '17 at 20:55
  • 2
    $\begingroup$ Also note that finished authenticates the transcript (and especially all parts of the handshake that weren't part of the actual key derivation process). $\endgroup$ – SEJPM May 8 '17 at 21:40
  • $\begingroup$ We may be a bit reluctant to answer this as Dave is around... :) $\endgroup$ – Maarten Bodewes May 8 '17 at 22:01
  • $\begingroup$ Regarding transcript authentication, doesn't it gets indirectly achieved since transcript hash was used to generate extended master secret? Can you kindly elaborate? $\endgroup$ – Vakul Garg May 9 '17 at 1:30

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!


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.