- 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.
Hey, looks like you misunderstood me, I was not talking about relay detection, but malicious exit nodes gathering domain names even with DNS over TLS in place. -GH On Tuesday, October 8th, 2024 at 12:36 PM, trinity pointard <trinity.point...@gmail.com> wrote: > 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, > > > 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. > > > > _______________________________________________ > > tor-dev mailing list > > tor-dev@lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
publickey - hartley_george@proton.me - 0xAEE8E00F.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
