On 3/19/2025 5:29 AM, Florentin Rochet wrote:
I am thinking, for example, to the behavior
common to all QUIC stacks to silently drop undecryptable packets
(e.g., because
keys are not available yet, or because AEAD decryption fails). This
behavior
may have strong negative effects to low-latency anonymous
communications such
as Tor that could carry HTTP/3 frames in between a Tor client and a
destination
server, and tunneled through Tor. It would be possible for malicious exit
relays to build a perfect signalling mechanism (in terms of FP=0/FN=0)
that can
support a malicious entry node to silently drive a user's circuit to a
compromised exit node before any attempt of a connection to a
destination is
even made, and then link source to destination.
A method to build such a signal is to inject a few packets at the exit
relay
towards the client when the channel is expected to be silent. This is
generally
simple to achieve. In the case of an HTTP/3 connection, these packets
would
then be dropped by the client's QUIC stack, but such a signal would be
observable on the wire by the entry node.
Could you please elaborate, and describe the mechanisms by which the
third parties can observe that the QUIC recipient dropped incoming
packets? I would propose that we treat this issue as a bug in either
QUIC or the application on top of QUIC, and that we work to eliminate
that bug. But the first step would be to understand what the issue
actually is.
-- Christian
