Re: [tor-dev] Tor over QUIC
On Fri, Oct 4, 2024 at 3:57 AM Q Misell via tor-dev 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.pdf 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? -- Nick ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor over QUIC
- I don't understand why SNI is being be discussed here, ESNI/ECH wouldn't bring much to Tor, there are better ways than looking at the client hello to detect a Tor relay, starting by its IP being public. Hey, looks like you misunderstood me, I was not talking about relay detection, but malicious exit nodes gathering domain names even with DNS over TLS in place. -GH On Tuesday, October 8th, 2024 at 12:36 PM, trinity pointard wrote: > I think QUIC could be an improvement, though I'm worried adding QUIC wouldn't > remove the need for Tor over TLS, which might add more maintenance burden. > > Even with QUIC, we will need to support TLS for some time so as to not > partition the network. Also, it used to be that UDP was 2nd class citizen in > some networks, and you'd never be able to get as good of a connection over > UDP (both in term of bandwidth and drop rate). So we might need more than a > transition period, > and possibly have to support both ad vitam æternam. > > It might simplify the implementation of UDP-over-Tor, but to me that's > something that would come later, and wouldn't change much things if we also > have to support TLS (over QUIC might be simpler, but over TLS would still > have to exist). > > It would be interesting to know how much head of line blocking we get. > Between relays, i would expect it to be less frequent than between relay and > client, but any blocking between relay might impact a lot of people at once. > It may well be that if we try to measure that, we find that the network would > feel much faster with no HOL blocking, or it could be that we find the > problem is negligible today. > > QUIC connection migration might be something to look at. It sounds like > something that can be useful especially for mobile users whose IP might > change, currently that would reset their connection. But that might also be a > tracking hazard somehow? > > > I don't understand why SNI is being be discussed here, ESNI/ECH wouldn't > bring much to Tor, there are better ways than looking at the client hello to > detect a Tor relay, starting by its IP being public. > ECH would be good to have so that exit relays know even less about what they > transmit, but that's not for c-tor/arti to do (and ECH needs proper DNS > support over Tor, which could be considered a child item of UDP over Tor, or > something we can already do with DNS over tcp/tls/https, or something > orthogonal where a client could query directly the DNS of an exit node with > more than A//PTR). > > On Tue, 8 Oct 2024 at 10:29, George Hartley via tor-dev > wrote: > > > - What are people's thoughts on this? > > > > > > To be honest, I don't really care about UDP support. > > > > Adding UDP support also would presumably add a lot of torrent load to the > > network, and yes I know that torrent clients can fall back to TCP and this > > is already an issue. > > > > Regarding TLS, it's still somewhat insecure, as it transmits the target > > domain name during the ClientHello packet (SNI char buf in the packet, aka. > > Server Name Indication). > > > > There was some work regarding ESNI (encrypted SNI) but Firefox removed it > > eventually. > > > > This would also need to be worked on. > > > > Just my quick thoughts on this. > > > > > > On Friday, October 4th, 2024 at 9:56 AM, Q Misell via tor-dev > > wrote: > > > > > Hi all, > > > > > > I know the discussion on how best to support UDP applications over Tor > > > has dragged on for a long time, so I thought what better to do than to > > > throw another item to bikeshed into the discussion :) > > > On a more serious note I think running Tor over QUIC would provide > > > several advantages - both for the current stream transport and for > > > possible future datagram transports. > > > > > > On a technical level I don't think this would require huge changes to the > > > Tor specification, circuit IDs map nicely to QUIC stream IDs, and > > > datagram packets - whatever form they take - can be sent as QUIC datagram > > > frames (c.f. RFC 9221). > > > The primary advantage I see QUIC providing is the removal of head of line > > > blocking. As Tor currently multiplexes everything over one TCP > > > connection, a single dropped packet will delay all circuits and streams. > > > This impacts bandwidth utilisation and makes Tor less than ideal for > > > real-time applications. > > > Given this it might make more sense to provide a mapping of Tor streams > > > to QUIC streams rather than Tor circuits - but this is a minor technical > > > detail to be worked out in any specification. > > > > > > Now, that's great and all, but is it secure? I think yes - although I > > > haven't done an in depth analysis yet. > > > QUIC is very resistant against de-anonymization by passive attackers - > > > the only thing a passive observer can see is a cryptographically > > > generated random connection ID. > > >
Re: [tor-dev] Tor over QUIC
On 10 Oct (09:57:20), Nick Mathewson wrote: [...] > 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? Many moons ago, Mike spent considerable time evaluating this. You can see a summary here: https://lists.torproject.org/pipermail/tor-dev/2018-March/013026.html Deconstructing the above to see if still holds today could be a good start imo. Cheers! David -- OIA801GlIC38M7YQhAY3ojyedelKPpxaBcjfGrWKhDo= signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
