[tor-dev] Tor over QUIC

[David Schinazi]

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 at 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 at 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 at 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 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/20241011/38b476f7/attachment.htm>