4 ms·
> This is outright wrong. With TCP you have fast open, which provides 0-RTT send just like the TLS 0-RTT handshake. Yes in theory but it fails on its face in p
by riobard 7y ago
> This is outright wrong. With TCP you have fast open, which provides 0-RTT send just like the TLS 0-RTT handshake.
Yes in theory but it fails on its face in practice. Many middle boxes are not happy with TCP Fast Open, and there's the tracking problem. Chrome dropped TFO.
- the8472 7y agoDoesn't the tracking problem also apply to 0RTT TLS? So we would have to discount either.
- tialaramex 7y agoTLS lives in the browser stack. So your browser can provide policy here. For example the browser can say "OK, this is a Porn tab, so we shouldn't re-use the google.com TLS connection from the tab that's logged into GMail and searching for Tom Hanks movies, we'll spin up a new one (without 0RTT)". But TCP lives down in the OS stack, so maybe without knowing it the browser's new TLS connection has TFO cookies the OS learned from the Tom Hanks connection, which ties the two sessions together. Oops.
- the8472 7y agoThe application has to explicitly ask for fast open to happen, so just as it does with TLS it can choose not to do so with TFO. But you're right, it has no control over the cookies themselves. That could be added with some ioctl or socket option, but I guess things haven't developed that far. But cookieless TFO is also an option, combined with 0RTT TLS the application would be in charge of either accepting or rejecting the connection based on the TLS resumption cookie.