QUIC permissiveness

Posted Nov 28, 2023 11:07 UTC (Tue) by DemiMarie (subscriber, #164188)
In reply to: OpenSSL 3.2.0 released by paulj
Parent article: OpenSSL 3.2.0 released

Where does QUIC allow too much?

QUIC permissiveness

Posted Nov 28, 2023 11:36 UTC (Tue) by paulj (subscriber, #341) [Link] (11 responses)

QUIC specifies 2 ways to identify connections - by 4-tuple, or by negotiated "Connection IDs" (CIDs). So your demux path has to be able to switch between 4-tuple or CIDs to route packets through to the appropriate state for connection-packet processing. Further, the CIDs are negotiated, rotated and retired by other means, so you have to keep track of all that and get it right (and some implementations just have convoluted quirks in their code as a result). Further, there is an implicit binding between CID and 4-tuple, if using CIDs, which must also be tracked and acted on if changes are sensed.

The point of all this complexity is to try prevent middle-boxes correlating paths to connections, to try enhance privacy. Which is something it can not at all guarantee or do well. If you have this level of privacy requirements, you need Tor - not this network-visible-CID rotating stuff in QUIC, which is giving you only minimal privacy guarantees, at best.

QUIC permissiveness

Posted Nov 28, 2023 11:52 UTC (Tue) by farnz (subscriber, #17727) [Link] (10 responses)

I was under the impression that the goal is not to enhance privacy specifically; rather, it's to prevent the situation we see in TCP, where cheap middle-boxes drop or modify packets that don't conform to their idea of what TCP "should" look like, making things like MPTCP a pain to design and deploy. This has effects like middle-boxes changing parts of the packet to get specific congestion control behaviour out of TCP on the assumption that a specific algorithm is in use, making it hard to change the algorithm.

Thus, it doesn't need to be a privacy guarantee - it just needs to be work that the end-points can do, but that middle-boxes will struggle to do, so that middle-boxes don't interfere with QUIC expecting certain behaviours from it.

QUIC permissiveness

Posted Nov 28, 2023 12:58 UTC (Tue) by paulj (subscriber, #341) [Link] (9 responses)

Keeping as much of the packet state encrypted as possible prevents midlde-boxes from having ideas about state.

The CID is there to give a packet demux ID independent of the 4-tuple - so a connection can survive a NAT change. "Ah, but that means a middle-box could know that different end-points were in fact the same!" - so the CID rotation stuff is added. Except an observer in the middle will get to see the old CID on the changed 4-tuple anyway - before the end-points see. Rotating CIDs there after doesn't give any great privacy benefit.

There isn't any need to change it in QUIC now that it's there, but I also think it was... slightly over complicated for minimal benefit.

QUIC permissiveness

Posted Nov 28, 2023 19:40 UTC (Tue) by riking (guest, #95706) [Link] (3 responses)

And don't forget that they added the spin bit back in, which explicitly allows middleboxes to measure E2E latency. More complexity!

QUIC permissiveness

Posted Nov 29, 2023 13:58 UTC (Wed) by paulj (subscriber, #341) [Link] (2 responses)

Spin bit is kind of neat. Not too complicated to support. Though, not entirely accurate either.

I'm in 2 minds about the loss of insight into performance of transport flows with QUIC. With TCP you can capture and make nice sequence graphs showing exactly what's going on from a network POV. With QUIC, that is lost - unless you have the private key. Which a network operator will not have, and which even the application owner generally will not retrospectively have. It's a real shame to lose that insight. On the other hand, it's nice to make the transport opaque.

Does QUIC have the balance right? I don't know.

QUIC permissiveness

Posted Nov 29, 2023 14:32 UTC (Wed) by farnz (subscriber, #17727) [Link] (1 responses)

The network operators have demonstrated that if they have the private key, they will misuse it (as they have misused the ability to tamper with TCP traffic beyond port numbers changing in a NAPT). It's just a shame that applications don't make it easy to record the private keys for retrospective analysis by the owner of an endpoint.

QUIC permissiveness

Posted Nov 29, 2023 15:02 UTC (Wed) by paulj (subscriber, #341) [Link]

You don't need to give operators the private key to let them see information. E.g. the QUIC header is not encrypted (but is part of the MAC, so can not be tampered with) - that's why they can see the spin bit.

Might it be better to give the network a bit more and higher-quality information about the congestion-related state of the flow, so network operators could debug problems?... maybe.

QUIC permissiveness

Posted Nov 29, 2023 15:15 UTC (Wed) by wtarreau (subscriber, #51152) [Link] (4 responses)

The purpose of the multiple CIDs are only to break the tracking during a connection migration: let's say you start from 4G and you migrate to the local WiFi or conversely. Someone elsewhere on the path seeing the two connection flows has no useful information to correlate them (IP:ports differ, connection IDs have rotated), so for example nothing allows to figure it's the same person for both connections, hence it's not really possible to geolocate one client by correlating its multiple source IPs. Beyond that it doesn't bring much.

QUIC permissiveness

Posted Nov 29, 2023 16:13 UTC (Wed) by paulj (subscriber, #341) [Link] (3 responses)

Thing is, you have a shared secret - negotiated in crypto setup. You could also just use a derivation function to allow both sides to calculate the same set of N currently valid CIDs, and retirement can be automatically done via a sliding window.

No real need to have all this machinery to send messages to update and retire CIDs.

QUIC permissiveness

Posted Nov 29, 2023 16:51 UTC (Wed) by wtarreau (subscriber, #51152) [Link] (2 responses)

Here it allows the client to decide when to switch. A sliding window would not exactly, unless the client indicates which key number it's using. But that info would need to pass one way or another and be detectable, I suspect that's the reason why it was not adopted. With that said, the machinery is not *that* complex, the server produces N CIDs that it's willing to recognize, the client is free to drop them if it does not intend to use them. It's not exactly something terribly difficult.

QUIC permissiveness

Posted Nov 29, 2023 16:59 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

You just update the window when the other side uses a new CID. (Maintain 1 pool for each side, as is done now). Yeah, the explicit message based stuff is not terribly difficult. But it's a bunch of extra pointless code on top of that (and at least some implementations are already using a derivation function from the shared secret to generate their CIDs!). Anyway, just a nit.

My real gripe though is that QUIC /also/ requires to support no-CID, 4-tuple. So 2 distinct ways required to demux the incoming packet and match up to and validate to the connection state (and /both/ ways require 4-tuple lookup and validation, just differently). Just... annoying.

QUIC permissiveness

Posted Nov 29, 2023 17:06 UTC (Wed) by paulj (subscriber, #341) [Link]

Oh, one other annoyance in QUIC. A network protocol, created in the 21st C, and the framing does /not/ have a length field. (And QUIC has variable length encoding!). So if you add a frame type, any tooling like wireshark will fail to parse a packet once that new frame type is there. Any other frames past that that it could recognise - tough.

Really annoying.