3 ms·

Please explain how it is more complicated. Also, QUIC is not just about the performance improvements offered today. Existing protocols like TCP and TLS are not

by uluyol 6y ago

Please explain how it is more complicated. Also, QUIC is not just about the performance improvements offered today. Existing protocols like TCP and TLS are not really simpler than QUIC, you just don't think about them because we have implementations of them already. However, _changing_ TCP and TLS is extremely difficult to impossible because middleboxes snoop on traffic and mess it up in various ways. As an example, multipath TCP has been engineered to look like regular TCP and automatically downgrade to regular TCP if middleboxes can't handle it. Making this work is hard and 100% a waste of time just to work around the fact that people deploy these boxes. I believe TLS 1.3 also had deployment challenges due to middleboxes. QUIC encrypts ~everything so that middleboxes can't make broken assumptions and manipulate traffic. Adopting it is a one time pain that enable later improvements to be possible.

tialaramex 6y ago
> I believe TLS 1.3 also had deployment challenges due to middleboxes. There was about one year delay between the point where the protocol was initially "done" and experiments showed it could not be deployed partly because of middleboxes although also due to server intolerance (web servers that go "What? TLS 1.3? No, rather than negotiating TLS 1.2 I'll just ignore you and hope you go away you weirdo") - until the point where the revised TLS 1.3 wire spelling was finished and tested (about six months before it was published as RFC 8446) The core idea in TLS 1.3 as shipped is that the initial setup phase looks outwardly very much like TLS 1.2 resumption. Interpreted as if it was TLS 1.2 the TLS 1.3 client claims to be trying to resume a previous connection, a TLS 1.3 server claims to accept that resumption, but really they actually just agreed a brand new connection. A TLS 1.2 server would see the resumption attempt, but it has no memory of any such prior connection (there wasn't one, the "connection ID" is just random bytes) so it offers a new one using TLS 1.2 and everything goes swimmingly. This way of doing things allows TLS 1.3 to be as fast on first connection as TLS 1.2 was on resumption without causing problems with incompatible middleboxes or servers. It does make the "spelling" on the wire pretty weird looking though if you are used to looking at TLS 1.2. The other essential goal was to never back off. A TLS 1.3 client will never go "Huh, TLS 1.3 didn't work, let's try again with TLS 1.2 instead". The design means if the remote server can speak TLS 1.2 (or 1.0 or 1.1) it will respond as such to your TLS 1.3 connection. This means adversaries can't try to "downgrade" you to a bad older version.

by uluyol 6y ago

tialaramex 6y ago

> I believe TLS 1.3 also had deployment challenges due to middleboxes. There was about one year delay between the point where the protocol was initially "done" and experiments showed it could not be deployed partly because of middleboxes although also due to server intolerance (web servers that go "What? TLS 1.3? No, rather than negotiating TLS 1.2 I'll just ignore you and hope you go away you weirdo") - until the point where the revised TLS 1.3 wire spelling was finished and tested (about six months before it was published as RFC 8446) The core idea in TLS 1.3 as shipped is that the initial setup phase looks outwardly very much like TLS 1.2 resumption. Interpreted as if it was TLS 1.2 the TLS 1.3 client claims to be trying to resume a previous connection, a TLS 1.3 server claims to accept that resumption, but really they actually just agreed a brand new connection. A TLS 1.2 server would see the resumption attempt, but it has no memory of any such prior connection (there wasn't one, the "connection ID" is just random bytes) so it offers a new one using TLS 1.2 and everything goes swimmingly. This way of doing things allows TLS 1.3 to be as fast on first connection as TLS 1.2 was on resumption without causing problems with incompatible middleboxes or servers. It does make the "spelling" on the wire pretty weird looking though if you are used to looking at TLS 1.2. The other essential goal was to never back off. A TLS 1.3 client will never go "Huh, TLS 1.3 didn't work, let's try again with TLS 1.2 instead". The design means if the remote server can speak TLS 1.2 (or 1.0 or 1.1) it will respond as such to your TLS 1.3 connection. This means adversaries can't try to "downgrade" you to a bad older version.