4

As I understand, during TLS handshake phase, it is not legal for an endpoint to send its own handshake messages till the time it processes its peer's entire flight of messages completely. E.g. although a server is able to compute master secret after seeing client_key_exchange,
it cannot send its own change_cipher_spec and then finished messages
until it has processed client's finished message.

Why did the designers of TLS (say v1.2 and prior) disallow the possibility
of handshake messages flowing in parallel in both directions?

Vakul Garg
  • 425
  • 2
  • 12
  • My feeling is that it is just to ensure that each end can compute the same value of handshake_hash used in processing finished message. – Vakul Garg May 14 '17 at 01:35
  • Your understanding is not fully correct. While this was defined in the TLS 1.2 RFC this way it is no longer true when TLS False Start is used. – Steffen Ullrich May 14 '17 at 04:31
  • 1
    Isn't the entire handshake process half duplex? That certainly helps with simplifying protocol implementations, even at the cost of some performance. – Maarten Bodewes May 14 '17 at 09:58
  • Also note that non-concurrent sending may also make protocol analysis easier. – SEJPM May 14 '17 at 10:17
  • If a tls endpoint violates this half-duplex rule, i.e. starts sending its own records without fully consuming full flight of records from peer, is it detectable by the other end? – Vakul Garg May 14 '17 at 12:25
  • TCL is stateful; if one side produces something and it isn't consumed then the stream simply blocks. You can of course make calculations asynchronous in case enough information is present to perform them before the result is required. – Maarten Bodewes May 14 '17 at 12:41

0 Answers0