4 ms·

This article exaggerates the deficiencies of TLS 1.2. - Because of the TCP handshake, the difference between plain HTTP and TLS 1.2 is 2 RTTs vs 4 RTTs, not 1

This article exaggerates the deficiencies of TLS 1.2. - Because of the TCP handshake, the difference between plain HTTP and TLS 1.2 is 2 RTTs vs 4 RTTs, not 1 vs 3. - TLS 1.2 supports session resumption, which can bring it down from 4 RTTs to 3. - The article's "TLS 1.3 Session Resumption" diagram is actually describing "0-RTT" resumption, which is vulnerable to replay attacks and can't be used without carefully considering semantics of the HTTP POST request. (https://blog.cloudflare.com/introducing-0-rtt/#whatsthecatch https://blog.cloudflare.com/introducing-0-rtt/#whatsthecatch) TLS 1.3 is still better in a bunch of ways, but there's no need to be misleading.

tialaramex 7y ago
You're correct that people MUST NOT use 0-RTT without actually understanding its semantics and designing their systems accordingly (e.g. if you think "But HTTP defines GET as idempotent so that's enough" then you already lost) But you can get rid of the extra RTT for a resumption on TCP in two ways. Firstly Systems can agree to do "Fast open". https://en.wikipedia.org/wiki/TCP_Fast_Open https://en.wikipedia.org/wiki/TCP_Fast_Open Secondly you can get rid of TCP from your TLS stack, by integrating the TLS layer into your connection-oriented protocol, which is what the IETF QUIC does/ will do. Then your connection setup can (again pending DDOS mitigation if appropriate) be zero round trip. So the end result is that in practice TLS 1.2 can be brought down to 1-RTT for second and subsequent connections (TCP Fast Open + TLS resumption + TLS False Start) and TLS 1.3 can match that for all connections, and beat it with 0-RTT for resumptions that meet extra security criteria. TLS session resumption does have a bunch of privacy implications, which are worse in TLS 1.2 and earlier but still present in TLS 1.3, and so privacy-focused clients might choose either to sharply limit resumption (e.g. only use it for connections that happen in the 15 seconds after the original connection) or get rid of it altogether. If you don't do resumption for this reason, TLS 1.3 beats TLS 1.2 because the no-resumption case is less round trips.

tialaramex 7y ago

You're correct that people MUST NOT use 0-RTT without actually understanding its semantics and designing their systems accordingly (e.g. if you think "But HTTP defines GET as idempotent so that's enough" then you already lost) But you can get rid of the extra RTT for a resumption on TCP in two ways. Firstly Systems can agree to do "Fast open". https://en.wikipedia.org/wiki/TCP_Fast_Open https://en.wikipedia.org/wiki/TCP_Fast_Open Secondly you can get rid of TCP from your TLS stack, by integrating the TLS layer into your connection-oriented protocol, which is what the IETF QUIC does/ will do. Then your connection setup can (again pending DDOS mitigation if appropriate) be zero round trip. So the end result is that in practice TLS 1.2 can be brought down to 1-RTT for second and subsequent connections (TCP Fast Open + TLS resumption + TLS False Start) and TLS 1.3 can match that for all connections, and beat it with 0-RTT for resumptions that meet extra security criteria. TLS session resumption does have a bunch of privacy implications, which are worse in TLS 1.2 and earlier but still present in TLS 1.3, and so privacy-focused clients might choose either to sharply limit resumption (e.g. only use it for connections that happen in the 15 seconds after the original connection) or get rid of it altogether. If you don't do resumption for this reason, TLS 1.3 beats TLS 1.2 because the no-resumption case is less round trips.