[tor-dev] Tor over QUIC

[Q Misell]

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.
QUIC also provides in-built padding frames to protect against traffic
analysis.
The connection setup and handshake is protected by the usual TLS mechanisms
(with a minimum version of TLS 1.3). We already know recent TLS versions to
be almost bullet proof if used correctly,
and TLS is already the base transport for Tor anyway.
A read of the security considerations section of RFC 9000 seems to confirm
that even an active attacker can at most cause a connection to fail.
Another concern is this making Tor traffic stand out more. This is a very
legitimate concern, however with the increasing deployment of HTTP/3 I
don't think it will make Tor stand out against the background of HTTP/3
traffic,
see: https://e.as207960.net/w4bdyj/uJdzhSHvRZOf5dPL

I recognise this is a rather large project - and may not be worthwhile. I
only expect this to be implemented in Arti, so deployment of Tor over QUIC
in the real world will take at least until Arti is widely used.
What are people's thoughts on this?

Q
------------------------------

Any statements contained in this email are personal to the author and are
not necessarily the statements of the company unless specifically stated.
AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace,
Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company
registered in Wales under № 12417574
<https://find-and-update.company-information.service.gov.uk/company/12417574>,
LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876
<https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU
VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №:
522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru
maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca
Digital, is a company registered in Estonia under № 16755226. Estonian VAT
№: EE102625532. Glauca Digital and the Glauca logo are registered
trademarks in the UK, under № UK00003718474 and № UK00003718468,
respectively.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20241004/49ff49e0/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4640 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20241004/49ff49e0/attachment.bin>