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/AAAA/PTR).On Tue, 8 Oct 2024 at 10:29, George Hartley via tor-dev <tor-dev@lists.torproject.org> 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 <tor-dev@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,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.
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
