It seems to me that disabling the QUIC client's "packet injection robustness" would be straightforward and safe for the use case considered here. The client would simply terminate the connection if it received any unexpected or invalid packets on the QUIC connection's 5-tuple, reproducing the behavior of TLS over TCP. This does not create any obvious compatibility issue (although some care would be required in relation to duplicate packets).
Personally, I don't find the motivating threat model especially convincing. An active attacker who controls multiple colluding proxies can mount many powerful deanonymization attacks against a low-latency mixnet. "Random delay" attacks are especially difficult to foreclose on long-lived connections, regardless of protocol. --Ben Schwartz [1] https://datatracker.ietf.org/doc/html/rfc9000#section-5.2-6 ________________________________ From: Florentin Rochet <florentin.roc...@unamur.be> Sent: Sunday, March 30, 2025 5:24 AM To: Christian Huitema <huit...@huitema.net>; quic@ietf.org <quic@ietf.org> Cc: mas...@ietf.org <mas...@ietf.org> Subject: [Masque] Re: Support for QUIC on Stream > Thanks for the explanation. I am focusing on your 3 example to check > whether I correctly understood. > > The goal of the adversary is to anonymize the communication, e.g. > matching client and destination. It does so by "volunteering" a number > of guards and exits. If a communication is routed through a Guard and > an Exit controlled by the attacker (E_a and G_a) r, the two will > collaborate. > > They could obviously collaborate and try to match timings of packets, > but it much easier to alter the end-to-end exchange between client and > destination, somehow inserting a mark at one end that can be recovered > at the other end. I assume that we have an onion setup, and that this > setup prevents G_a and M from actually seeing the packets send and > received by the client -- but of course E_a can see them. E_a and G_a > have to find a signal that will alter the volume and timing of packets > between client and server. > > With QUIC, you believe that this can be achieved by inserting a bogus > packet, which will be relayed to the other end but will be discarded > because it does not pass decryption. Intermediaries like M cannot > detect this. That packet is inserted by E_a as if it came from the > destination, at a time when the destination would normally be silent. > The "absence of the expected silence" is the signal. Indeed, this is a faithful summary. > >> 3) malicious guard and exit >> >> Client-----G_a-----M-----E_a-----Destination >> >> In that scenario, the adversary can abuse QUIC's robustness to derive >> a perfect >> traffic confirmation technique, as discussed above. >> >> My current guess is that we cannot have a QUIC connection over a >> whole circuit, >> or over a set of MASQUE proxies that resists such an adversary >> without impractical changes >> in the QUIC protocol. Some research would be needed to know what >> combination of >> layers and protocols (and extensions; e.g., datagrams) would be safe >> to use. I *think* QUIC >> on stream would be, as long as it behaves like the TLS1.3 record layer. > > The key issue there is that anybody can inject a packet and that QUIC > will drop it. With TCP, packet injection is likely to break the > connection. Breaking the connection matches one of the goals of the > adversary, as they know which connection was broken by the injection. > But breaking the connection can be observed. > > The timing attack relies on the adversaries guessing that the > communication should remain silent for a particular time interval. The > first defense may be to break that guess. Either end of the QUIC > connection could also inject their own set of bogus QUIC packets at > random times. Would that be efficient? > This is a great question; some researchers are looking at machine padding designs (i.e., probabilistic process sending padding cells from client/relay) [1,2] to thwart website fingerprinting [3] (not to confuse with browser fingerprinting), and for raising FP in passive traffic analysis. This can be efficient to raise a passive attacker's uncertainty. Regarding bandwidth overheads, the Tor project is planning to modify [4] the set of equations that currently drive clients' path selection logic to account for padding bandwidth. Under surplus of bandwidth in between client-to-middle, the padding impact can be negligible if the path selection logic is well designed. But in our case we are up against an active attacker abusing QUIC's robustness to bias the client's choice of set of nodes to compromised entry and exit. To the best of my current understanding of this problem, covering periods of silence cannot be efficient, nor a security guarantee can easily be formulated at low-latency. Covering periods of silence with padding would amount to a quantity of traffic that would likely render any Tor-like network unusable. In a recent research publication [5], we've been looking at an alternative software architecture for Tor to build Robustness by deploying new protocol features and code (as eBPF patches) during circuit handshake. With this technique, it was for example possible to design forward-compatible intolerant protocols where, e.g., a middle node would never send anything towards the client before the client explicitly gives it a go. This may sound a bit uncanny; but essentially protocols messages propagate with the code to handle them, so we can adjust in the future if necessary. With this technique, we were able to protect the client from naturally occurring periods of silence within the Tor protocol at low padding overhead cost (~3.6% of the total network application traffic), and with the middle node sending traffic towards the client using a padding machine sending padding and swapping padding for real messages if real messages were received from the exit during these potential periods of silence. Needless to say, this is complicated design over an unorthodox software architecture, and it only protects _known_ silences in the Tor routing protocol (and in fact, not all of them [6]). The TL;DR and current conjecture is: we can't pick up a fight against an active adversary and hope to obtain security guarantees at usable low latency against active traffic correlation. But, we can prevent path bias with guarantees. I'd love to be proven wrong on the first sentence, but I am afraid going this direction and trying to accommodate with QUIC's protocol weaknesses for MASQUE is likely to produce a design much weaker than Tor on both performance and security, and kill MASQUE's potential to be a future globally deployed privacy-preserving layer in H3 with good security properties. Best, Florentin [1] https://urldefense.com/v3/__https://spec.torproject.org/padding-spec/circuit-level-padding.html*circuit-level-padding__;Iw!!Bt8RZUm9aw!8Oycw1q7Wutde3IxqGXMPxD9xzf9qU4OKcJD13DxFvo-zyVz44lwJyMLMrGgIR3enyNhxj78S7qLXNuX2VoU1SI3lA$ [2] https://github.com/pylls/padding-machines-for-tor [3] https://urldefense.com/v3/__https://cosicdatabase.esat.kuleuven.be/backend/publications/files/conferencepaper/2456__;!!Bt8RZUm9aw!8Oycw1q7Wutde3IxqGXMPxD9xzf9qU4OKcJD13DxFvo-zyVz44lwJyMLMrGgIR3enyNhxj78S7qLXNuX2Vpouh1TEA$ [4] https://urldefense.com/v3/__https://spec.torproject.org/proposals/265-load-balancing-with-overhead.html__;!!Bt8RZUm9aw!8Oycw1q7Wutde3IxqGXMPxD9xzf9qU4OKcJD13DxFvo-zyVz44lwJyMLMrGgIR3enyNhxj78S7qLXNuX2Vptje90YQ$ [5] https://urldefense.com/v3/__https://researchportal.unamur.be/en/publications/towards-flexible-anonymous-networks__;!!Bt8RZUm9aw!8Oycw1q7Wutde3IxqGXMPxD9xzf9qU4OKcJD13DxFvo-zyVz44lwJyMLMrGgIR3enyNhxj78S7qLXNuX2Vqh0JGRKw$ [6] https://urldefense.com/v3/__https://gitlab.torproject.org/tpo/core/torspec/-/issues/220__;!!Bt8RZUm9aw!8Oycw1q7Wutde3IxqGXMPxD9xzf9qU4OKcJD13DxFvo-zyVz44lwJyMLMrGgIR3enyNhxj78S7qLXNuX2VpSauXb-Q$ -- Masque mailing list -- mas...@ietf.org To unsubscribe send an email to masque-le...@ietf.org
