Re: [tor-dev] Tor over QUIC

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Fri, Oct 4, 2024 at 3:57 AM Q Misell via tor-dev
<tor-dev@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev