[tor-dev] Tor over QUIC

[George Hartley]

-   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 <tor-dev at lists.torproject.org> 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.
> 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://blog.cloudflare.com/http3-usage-one-year-on/
> 

> 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, LEI 875500FXNCJPAPF3PD10. ICO register №: 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/bad7775d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - hartley_george at proton.me - 0xAEE8E00F.asc
Type: application/pgp-keys
Size: 657 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20241004/bad7775d/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20241004/bad7775d/attachment.sig>