TLS false start / early data

Question

How often such mechanisms are used by application. Is it real requirement to support these features for TLS ?

Answer 1

There is a push by browser vendors to reduce latency. It seems that, in their measures, the initial latency by the TLS handshake is large enough to be detrimental to the perceived user experience. It is true that a complete TCP handshake + TLS handshake can have a large latency (three round trips, which may add up to a significant time, in particular when considering links through geostationary satellites).

Old theory is that TLS handshake latency does not matter since you can keep the connection open, so you just pay for it once. However, the modern Web user does not engage with Web sites like he does with a local application; he will jump from site to site. Also, Web sites are now complicated assemblages of scripts that load other scripts, possibly from other servers, and all the latencies just add up.

This has led browser vendors to explore other strategies, including the false start / early data thing for TLS, to reduce latency. At Google's, they even decided to dispense with the TCP three-way handshake by defining QUIC to use UDP instead.

---

You may note that all of the above is about Web browsers. Requirements for applications vary quite a lot, depending on context. The modern Web has a combination of many short-lived connections and impatient human users, which may explain the quest for a reduced latency.

Of course, these modifications are not purely a matter of optimization. For instance, with TLS "false start", the client sends its data before having verified the Finished message from the server: at that point, the client does not have any guarantee that it has been talking with the intended server^(*); it only knows that what it sends won't be intelligible to a fake server.

The "0-RTT" feature of TLS 1.3 is inherently vulnerable to replay attacks, and it is quite hard to know when 0-RTT can be used safely. TLS 1.3 draft 23, section E.5, gives some guidance, but (characteristically) uses the term "idempotent" without defining it, leaving the reader a bit nonplussed as what is meant there.

It can be expected that, when TLS 1.3 is finally deployed beyond some specific Web browsers and servers, 0-RTT will be activated in unsafe contexts, because developers and administrators just want "more speed".