Hi all,
For my master's thesis this summer I looked into the performance impact from using QUIC instead of TCP/TLS as the relay transport. Results from the experiments look quite promising.
For more details and the thesis, please see my blog post: https://www.benthamsgaze.org/2016/09/29/quux-a-quic-un-multiplexing-of-the-t...
I'm happy to respond to questions either here or in comments on the blog post.
Ali
On 09/30/2016 07:02 AM, Ali Clark wrote:
For my master's thesis this summer I looked into the performance impact from using QUIC instead of TCP/TLS as the relay transport. Results from the experiments look quite promising.
For more details and the thesis, please see my blog post: https://www.benthamsgaze.org/2016/09/29/quux-a-quic-un-multiplexing-of-the-t...
Hi Ali,
Well done, this looks really neat! A couple of questions: 1) Are you looking into publishing your work in a peer-reviewed journal such as CSS, NDSS, PoPETS, or elsewhere? 2) Did you examine the performance improvements for 6-hop onion/hidden service circuits? 3) Tor currently multiplexes circuits over the same TLS connection. This is by design to avoid leaking circuit-level metadata, including the observation of construction and tear-down. The first paragraph on page 21 seems to suggest that QUUX leaks this information. Is this correct, or did you take steps to address this? For that matter, does QUUX leak any additional metadata that could assist with de-anonymization attacks?
Well done, this looks really neat! A couple of questions:
Thanks Jesse :)
- Are you looking into publishing your work in a peer-reviewed journal
such as CSS, NDSS, PoPETS, or elsewhere?
Not at the moment, however there's another research group investigating QUIC and I've also shared my code with them.
- Did you examine the performance improvements for 6-hop onion/hidden
service circuits?
Afraid I didn't have time, but I expect performance should improve for that case too.
- Tor currently multiplexes circuits over the same TLS connection. This
is by design to avoid leaking circuit-level metadata, including the observation of construction and tear-down. The first paragraph on page 21 seems to suggest that QUUX leaks this information. Is this correct, or did you take steps to address this? For that matter, does QUUX leak any additional metadata that could assist with de-anonymization attacks?
That paragraph only refers to the internal code buffers before send so shouldn't be an issue. The stream frames are contained in an encrypted QUIC packet for transfer over a QUIC connection, and it shouldn't be possible to tell what streams/circuits are communicating just by looking at an encrypted QUIC packet from a connection between relays.
The initial stream creation currently sends an "unusual" 32 byte hash and 4 byte circ-id on the connection. If the connection is busy this would hopefully be resegmented with other streams' data on the connection to create a full packet. If it's an issue the size could be rounded up to a full cell size instead though. However, in truth I would be surprised if Tor currently resists traffic analysis on creation of circuits, since I expect handshake cell timings would be quite identifiable, especially over a quiet relay.
I agree for a busy relay (both in and out) analysis of a Tor relay's established circuit traffic should be difficult, and I expect it'd be about as difficult for QUIC, depending on its algorithm/heuristics for how it chooses to resegment stream data onto packets send them.
-
Ali Clark -
Jesse V