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/
[2]: https://www.rfc-editor.org/rfc/rfc9001.html#name-security-considerations

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.



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

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

_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev