On Fri, Oct 4, 2024 at 3:57 AM Q Misell via tor-dev tor-dev@lists.torproject.org wrote: [...]
What are people's thoughts on this?
Hi, Q!
I think migrating to QUIC over time might help a lot, particularly in relay-to-relay communications where we have a large number of circuits to multiplex.
## Design points
* I agree we'll need TLS-over-TCP basically forever. Dodgy middleboxes, PTs, and censorship will keep TLS as a requirement. That said, I don't see making relays support two encrypted transports as a complete nonstarter.
* We should keep an eye on the current state of QUIC and HTTP/3 adoption in the wild. I'm seeing statistics around 10%-30% adoption for HTTP/3 and websites, depending on what we count and how. IMO we can only consider QUIC so long as it is ubiquitous, maintained, and very widely used: otherwise, we'll be standing out as weird.
* For this email I'll only talk about using QUIC as a channel transport (between a client and a relay, or a relay and a relay) while keeping our current reliable-in-order circuit and cell behavior— so this won't actually help UDP-over-Tor at all. IMO the fundamental problem with _unreliable_ UDP over Tor is that we don't know really how to anonymize an unreliable out-of-order transport. See https://research.torproject.org/techreports/side-channel-analysis-2018-11-27... for a discussion of the open issues in that area: although that whitepaper discusses DTLS-over-UDP, the problems remain for any unreliable and/or out-of-order version of Tor.
(If anybody wants to talk about that whitepaper or the issues involved in a secure UDP-over-Tor, let's maybe start another thread.)
## Open design and performance questions
There are a few open questions I have that I think we'd want to figure out before we could deploy QUIC in production, but there's no reason not to start thinking about them now, and to start sketching solutions. A project like this would have a multi-year horizon, so we may as well start analyzing now.
* We should figure out how much of our existing circuit scheduling and prioritization tools that we use when stuffing multiple circuits' traffic onto a channel (ewma-priority circuitmux, kist-lite, etc) are still even necessary with QUIC; and to what extent QUIC's native behavior in prioritizing multiple circuits' traffic would be exactly what we want for Tor circuit prioritization and performance.
* We should figure out what, if anything, we would want ether we would want a new end-to-end flow control mechanism if we used QUIC for our circuits.
## Small open security questions
* I believe that QUIC encrypts its stream IDs. That's good: it's essential for Tor's traffic analysis resistance.
* We should look at the QUIC protocol with a fine-toothed comb. There are probably plenty of things that are fine within QUIC's threat model, but questionable for ours. (For example, I could be wrong about this, but there appear to be permissible QUIC token implementations that would leak the responder's current timestamp. That's not a great idea in our protocols; we try to keep everybody's timestamp a bit vague to avoid fingerprinting attacks against time-skew. Thus, we'd need to look hard at what our implementation actually did.)
## Big open security questions
Somebody needs to analyze whether QUIC's resilience to packet loss provides any new traffic analysis or traffic tagging opportunities. I don't know if there are any such attacks at present, but we should think hard about the changes properties we would get with QUIC , and identify what they'd do to traffic analysis.
Here's one example of what I mean. As it stands today in Tor, messing with a TCP packet will just stall the channel until TCP retransmits occur, and messing with a TLS record will kill off the channel with an error. But with QUIC, if you drop a packet, only a single QUIC stream (corresponding to a Tor circuit) would be disrupted until the loss could be detected and the data transmitted. I don't *think* that's necessarily a problem, but we should probably analyze it. (For all I know, this property might make traffic analysis _weaker_.)
And also: under the current Tor design, if a relay has a channel on which it receives a cell for circuit 1 and then a cell for circuit 2, it can't credibly pretend to have gotten the second cell but not the first. But if we use QUIC, then a relay can pretend that circuit traffic has arrived in any order it wants. FWIW, I don't currently see a way to actually make our security worse with
## In conclusion
I like Tor-over-QUIC and think it's a neat idea, but there's a lot of investigation to be done. I wonder what some logical next steps would be here?