You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While preparing the WIP #204, I noticed that the answer to the question "TLS still adds an extra RTT; can we fix that?" was written in a pre-RFC8446 world and is now a little stale.
The text was updated successfully, but these errors were encountered:
Can you clarify that? Neither the FAQ or you referencing the RFC does.
TLS 1.3 is 1-RTT(without 0-RTT) and TLS 1.2 is 2-RTT, with both versions having a follow-up 1-RTT for the actual request as far as I understand? (I'm referencing the following, which has a nice graphic for it as well)
I assume the Cloudflare article is out of date too?
One possible route is to leverage TCP Fast Open, which would allow us to send the ClientHello within the TCP SYN packet — that would cut another RTT. In the meantime, both TLS 1.3 and QUIC are experimenting with "zero-RTT" handshake mechanisms. See QUIC crypto doc and this GDL episode for a general introduction to QUIC.
So ignore the TFO thing, two points of staleness come to mind:
TLS 1.3 has shipped, so it is not experimental.
There are now two main flavours of QUIC, the original "gQUIC" that uses QUIC crypto, and IETF QUIC which uses the TLS 1.3 handshake.
IMO a suitable fixup would be to focus on TLS 1.3 0-RTT and then mention its applicability to IETF QUIC, with links to both. We might relegate mention of QUIC crypto to a legacy follow up sentence, or for clarity just omit it.
While preparing the WIP #204, I noticed that the answer to the question "TLS still adds an extra RTT; can we fix that?" was written in a pre-RFC8446 world and is now a little stale.
The text was updated successfully, but these errors were encountered: