[tor-dev] Tor over QUIC

Tue Oct 8 10:36:40 UTC 2024

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 at 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 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/
> <https://e.as207960.net/w4bdyj/4gqJBJBF1SNzQQL1>
>
> 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://e.as207960.net/w4bdyj/sqSRGqIbkYjA68zi>, LEI
> 875500FXNCJPAPF3PD10. ICO register №: ZA782876
> <https://e.as207960.net/w4bdyj/e9215D5RGZrsM2sm>. 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20241008/0d6aae70/attachment-0001.htm>