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.
- 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.
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/ <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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
- 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.pointard@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
On Fri, Oct 4, 2024 at 3:57 AM Q Misell via tor-dev <tor-dev@lists.torproject.org> wrote: [...]
What are people's thoughts on this?
Hi, Q! I think migrating to QUIC over time might help a lot, particularly in relay-to-relay communications where we have a large number of circuits to multiplex. ## Design points * I agree we'll need TLS-over-TCP basically forever. Dodgy middleboxes, PTs, and censorship will keep TLS as a requirement. That said, I don't see making relays support two encrypted transports as a complete nonstarter. * We should keep an eye on the current state of QUIC and HTTP/3 adoption in the wild. I'm seeing statistics around 10%-30% adoption for HTTP/3 and websites, depending on what we count and how. IMO we can only consider QUIC so long as it is ubiquitous, maintained, and very widely used: otherwise, we'll be standing out as weird. * For this email I'll only talk about using QUIC as a channel transport (between a client and a relay, or a relay and a relay) while keeping our current reliable-in-order circuit and cell behavior— so this won't actually help UDP-over-Tor at all. IMO the fundamental problem with _unreliable_ UDP over Tor is that we don't know really how to anonymize an unreliable out-of-order transport. See https://research.torproject.org/techreports/side-channel-analysis-2018-11-27... for a discussion of the open issues in that area: although that whitepaper discusses DTLS-over-UDP, the problems remain for any unreliable and/or out-of-order version of Tor. (If anybody wants to talk about that whitepaper or the issues involved in a secure UDP-over-Tor, let's maybe start another thread.) ## Open design and performance questions There are a few open questions I have that I think we'd want to figure out before we could deploy QUIC in production, but there's no reason not to start thinking about them now, and to start sketching solutions. A project like this would have a multi-year horizon, so we may as well start analyzing now. * We should figure out how much of our existing circuit scheduling and prioritization tools that we use when stuffing multiple circuits' traffic onto a channel (ewma-priority circuitmux, kist-lite, etc) are still even necessary with QUIC; and to what extent QUIC's native behavior in prioritizing multiple circuits' traffic would be exactly what we want for Tor circuit prioritization and performance. * We should figure out what, if anything, we would want ether we would want a new end-to-end flow control mechanism if we used QUIC for our circuits. ## Small open security questions * I believe that QUIC encrypts its stream IDs. That's good: it's essential for Tor's traffic analysis resistance. * We should look at the QUIC protocol with a fine-toothed comb. There are probably plenty of things that are fine within QUIC's threat model, but questionable for ours. (For example, I could be wrong about this, but there appear to be permissible QUIC token implementations that would leak the responder's current timestamp. That's not a great idea in our protocols; we try to keep everybody's timestamp a bit vague to avoid fingerprinting attacks against time-skew. Thus, we'd need to look hard at what our implementation actually did.) ## Big open security questions Somebody needs to analyze whether QUIC's resilience to packet loss provides any new traffic analysis or traffic tagging opportunities. I don't know if there are any such attacks at present, but we should think hard about the changes properties we would get with QUIC , and identify what they'd do to traffic analysis. Here's one example of what I mean. As it stands today in Tor, messing with a TCP packet will just stall the channel until TCP retransmits occur, and messing with a TLS record will kill off the channel with an error. But with QUIC, if you drop a packet, only a single QUIC stream (corresponding to a Tor circuit) would be disrupted until the loss could be detected and the data transmitted. I don't *think* that's necessarily a problem, but we should probably analyze it. (For all I know, this property might make traffic analysis _weaker_.) And also: under the current Tor design, if a relay has a channel on which it receives a cell for circuit 1 and then a cell for circuit 2, it can't credibly pretend to have gotten the second cell but not the first. But if we use QUIC, then a relay can pretend that circuit traffic has arrived in any order it wants. FWIW, I don't currently see a way to actually make our security worse with ## In conclusion I like Tor-over-QUIC and think it's a neat idea, but there's a lot of investigation to be done. I wonder what some logical next steps would be here? -- Nick
On 10 Oct (09:57:20), Nick Mathewson wrote: [...]
I like Tor-over-QUIC and think it's a neat idea, but there's a lot of investigation to be done. I wonder what some logical next steps would be here?
Many moons ago, Mike spent considerable time evaluating this. You can see a summary here: https://lists.torproject.org/pipermail/tor-dev/2018-March/013026.html Deconstructing the above to see if still holds today could be a good start imo. Cheers! David -- OIA801GlIC38M7YQhAY3ojyedelKPpxaBcjfGrWKhDo=
Moin David, Thanks for sending that over, it's very comprehensive! A lot has changed in QUIC since 2018, but there are some key ideas in there that I missed in my original email - specifically end-to-end flow control. A lot of what Mike raised made its way into MASQUE [1], which really looks a lot like how Tor operates and I think would be a great starting point. Onto Nick's points:
I agree we'll need TLS-over-TCP basically forever.
I think this can be better specified as we need TLS over TCP between the client and the guard forever. We should be able to expect communication between relays to succeed over QUIC. That is if a client can open a QUIC connection to its guard it can use QUIC for the rest of the circuit and won't need to fall back.
I believe that QUIC encrypts its stream IDs.
It does. Everything beyond the connection ID (which MUST be cryptographically random) and the source and destination IP address and UDP port is encrypted.
We should look at the QUIC protocol with a fine-toothed comb. There are probably plenty of things that are fine within QUIC's threat model, but questionable for ours.
The Security Considerations section of RFC9001 [2] provides an excellent start for what assumptions are made about QUIC's threat model.
But with QUIC, if you drop a packet, only a single QUIC stream (corresponding to a Tor circuit) would be disrupted until the loss could be detected and the data transmitted. I don't *think* that's necessarily a problem, but we should probably analyze it. (For all I know, this property might make traffic analysis _weaker_.)
From a brief review of the literature (attached) most QUIC fingerprinting works on the basis of packet length and TLS-SNI (which is irrelevant to Tor). I'm willing to make the conclusion that with appropriate packet padding QUIC will be at least as secure as TLS over TCP.
I think a decent next step would be to write up a rough spec for how Tor over QUIC would work (probably taking a lot of inspiration from MASQUE) so that people can start poking holes in it. Q [1]: https://e.as207960.net/w4bdyj/JpLhlmqAN2ZfKFBL [2]: https://e.as207960.net/w4bdyj/jKGPA8T9m204O1Ch ------------------------------ 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. On Thu, 10 Oct 2024 at 16:04, David Goulet <dgoulet@torproject.org> wrote:
On 10 Oct (09:57:20), Nick Mathewson wrote:
[...]
I like Tor-over-QUIC and think it's a neat idea, but there's a lot of investigation to be done. I wonder what some logical next steps would be here?
Many moons ago, Mike spent considerable time evaluating this. You can see a summary here:
https://e.as207960.net/w4bdyj/TvwSAg6e1HK6wN2n
Deconstructing the above to see if still holds today could be a good start imo.
Cheers! David
-- OIA801GlIC38M7YQhAY3ojyedelKPpxaBcjfGrWKhDo= _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://e.as207960.net/w4bdyj/rayBHPbOu5q2bHLc
Hi Q, MASQUE was designed as a censorship prevention tool. That's not mentioned in the specs themselves, but the design was focused on enabling as much obfuscation as possible. Additionally, existing two-hop MASQUE systems like Apple's iCloud Private Relay and Google's IP Protection were inspired by Tor. Those systems definitely have weaker privacy properties than Tor does, but that's mainly due to what they were optimized to do. I'm pretty sure you can construct a multi-hop MASQUE system that could give you the same privacy properties as Tor if you add the right amount of padding inside the encryption and get a bunch of other details right. If you do end up writing that spec, I'd be happy to help review it. David On Fri, Oct 11, 2024 at 12:48 PM Q Misell via tor-dev < tor-dev@lists.torproject.org> wrote:
Moin David,
Thanks for sending that over, it's very comprehensive! A lot has changed in QUIC since 2018, but there are some key ideas in there that I missed in my original email - specifically end-to-end flow control. A lot of what Mike raised made its way into MASQUE [1], which really looks a lot like how Tor operates and I think would be a great starting point.
Onto Nick's points:
I agree we'll need TLS-over-TCP basically forever.
I think this can be better specified as we need TLS over TCP between the client and the guard forever. We should be able to expect communication between relays to succeed over QUIC. That is if a client can open a QUIC connection to its guard it can use QUIC for the rest of the circuit and won't need to fall back.
I believe that QUIC encrypts its stream IDs.
It does. Everything beyond the connection ID (which MUST be cryptographically random) and the source and destination IP address and UDP port is encrypted.
We should look at the QUIC protocol with a fine-toothed comb. There are probably plenty of things that are fine within QUIC's threat model, but questionable for ours.
The Security Considerations section of RFC9001 [2] provides an excellent start for what assumptions are made about QUIC's threat model.
But with QUIC, if you drop a packet, only a single QUIC stream (corresponding to a Tor circuit) would be disrupted until the loss could be detected and the data transmitted. I don't *think* that's necessarily a problem, but we should probably analyze it. (For all I know, this property might make traffic analysis _weaker_.)
From a brief review of the literature (attached) most QUIC fingerprinting works on the basis of packet length and TLS-SNI (which is irrelevant to Tor). I'm willing to make the conclusion that with appropriate packet padding QUIC will be at least as secure as TLS over TCP.
I think a decent next step would be to write up a rough spec for how Tor over QUIC would work (probably taking a lot of inspiration from MASQUE) so that people can start poking holes in it.
Q
[1]: https://blog.cloudflare.com/unlocking-quic-proxying-potential/ <https://e.as207960.net/w4bdyj/E42T3zk81gHQgjiR> [2]: https://www.rfc-editor.org/rfc/rfc9001.html#name-security-considerations <https://e.as207960.net/w4bdyj/CVNzWFpTBkF7dXoG> ------------------------------
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/Edo16ck15zLcJ3AP>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://e.as207960.net/w4bdyj/vvcaeAXoMxXOHumX>. 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.
On Thu, 10 Oct 2024 at 16:04, David Goulet <dgoulet@torproject.org> wrote:
On 10 Oct (09:57:20), Nick Mathewson wrote:
[...]
I like Tor-over-QUIC and think it's a neat idea, but there's a lot of investigation to be done. I wonder what some logical next steps would be here?
Many moons ago, Mike spent considerable time evaluating this. You can see a summary here:
https://lists.torproject.org/pipermail/tor-dev/2018-March/013026.html <https://e.as207960.net/w4bdyj/0WytgOio1NpuZMSm>
Deconstructing the above to see if still holds today could be a good start imo.
Cheers! David
-- OIA801GlIC38M7YQhAY3ojyedelKPpxaBcjfGrWKhDo= _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev <https://e.as207960.net/w4bdyj/ifjf5KqlLrrz5cCk>
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
participants (6)
-
David Goulet -
David Schinazi -
George Hartley -
Nick Mathewson -
Q Misell -
trinity pointard