Dear QUIC enthusiasts,
@cc [email protected]
I am reaching out to express my support for the proposal QUIC on stream,
which
I believe is being discussed at the moment.
The motivations of the proposal essentially highlights performance issues of
QUIC due to UDP, which was a common observation and motivation for our
QUIC-like
protocol atop TCPs that we designed at UCLouvain [0].
However, I believe there are also security motivations to use another
substrate
than UDP. QUIC is supposed to be a general purpose transport protocol, but
there exists use-cases for which QUIC's properties linked to UDP make the
system less secure than TLS/TCP. 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. We initially designed attacks
on the
Tor routing protocols, called dropmarks [1] that exploited Tor's
tolerance to
unexpected messages, also coined as the Robustness principle. These problems
are currently partially resolved in Tor, but using HTTP/3 with QUIC would
enable them again. You can read more about Tor's analysis of this issue
within
Tor proposal 344, section 1.1.3 [2].
Because of such problems, the planned support of UDP and HTTP/3 in Tor
browser
and Tor (regarding UDP) has been halted (source: informal discussions
with the
Tor devs on IRC).
I believe similar concerns may arise to MASQUE if a support of a
Tor-like chain
of proxies is eventually discussed. For this kind of future usage, I
believe we
need a HTTP/3 layer that uses a substrate behaving as TLS/TCP. I *think*
there
are several possibilities to achieve this:
- Modifying QUIC streams such that the protocol gets closer to TLS/TCP
while keeping
most of QUIC's advantages over TLS/TCP. I *think* it could be possible by
adding information into the short header, and using it for reordering
stream
data before AEAD decryption rather than after decryption. But such a
change
would run deep inside QUIC's design, and would lead to many
side-effects to
deal with (e.g., control-flow). Probably a no-go.
- Supporting a QUIC-like design atop TCP. QUIC on stream is an interesting
starting point.
I am in favor of the second option, and I believe it may further be
developed
in the future to reach similar capabilities than QUIC, if there is
motivation
for it.
Best,
Florentin Rochet
[0] https://orbi.uliege.be/bitstream/2268/264667/1/paper.pdf
[1] https://www.freehaven.net/anonbib/cache/dropping-pets2018.pdf
[2] https://spec.torproject.org/proposals/344-protocol-info-leaks.txt
