[tor-dev] Tor over QUIC

[Q Misell]

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 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://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 at lists.torproject.org
> https://e.as207960.net/w4bdyj/rayBHPbOu5q2bHLc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20241011/7f2cb80d/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2310.10676v1.pdf
Type: application/pdf
Size: 693467 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20241011/7f2cb80d/attachment-0002.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1-s2.0-S2352340923000069-main.pdf
Type: application/pdf
Size: 1283265 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20241011/7f2cb80d/attachment-0003.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4640 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20241011/7f2cb80d/attachment-0001.bin>