It seems like there is probably some design available that decouples (1) the end-to-end encrypted transport protocol from (2) the optional network assistance, and allows the two protocols to evolve semi-separately without mutual trust (and giving the endpoints the option of whether or not to react to volunteered network assistance).

E.g., just to sketch out a straw person:

Protocol 1: The end-to-end protocol defines a unique "public ID" for each datagram. This could be implicit, e.g. "the SHA256/64 hash of the encrypted UDP datagram," or QUIC could start exposing its Packet Numbers (authenticating them but not encrypting them).
Protocol 2: An intermediary that wants to volunteer assistance (e.g. a Wi-Fi AP) can send its own messages to either endpoint, ideally by appending them to the end-to-end payload for datagrams already in flight, or by generating and sending its own datagrams. These messages would be defined by a separate protocol spec and could evolve separately.
Protocol 2: You could imagine a useful message for protocol #2 might express something like, "I'm a Wi-Fi AP with public key <p>, and I'm ACKing the datagram you sent to destination <d> that had public ID <id>. I promise I will deliver that datagram soon to destination <d>. Do you want me to keep sending these?" (and maybe the endpoint is like, "Sure, keep sending those," or, "Not interested, please stop.")
Protocol 1: The endpoints can now decide what to do with this extra info. For example, they could decide that the endpoint receiver should switch to super delayed ACKs itself (maybe one every N seconds or M megabytes), and the sender will trust the Protocol 2 ACKs for congestion-control and retransmission purposes, while still using the Protocol 1 ACKs for ultimate reliability. (I.e. the sender won't discard outstanding data from a reliable stream until it's been ACKed by the endpoint.)
If the Protocol 2 ACKs seem to be lying about receiving something that never gets to the endpoint, the endpoints can detect this (since they still have occasional end-to-end ACKs) and decide never to trust the intermediary again and go back to previous behavior.

It would be nice not to give up the benefits of end-to-end authenticated ACKs, while allowing intermediaries to provide most of the benefits we get with TCP acceleration, and also without tightly coupling these protocols to prevent them from evolving separately. I think it is probably possible, at least for this kind of use case. But I don't think there's much of a will to do this in practice; it's not something the major traffic sources seem particularly interested in afaik.

-Keith

On Thu, Oct 21, 2021 at 12:18 AM Michael Welzl <michawe@ifi.uio.no> wrote:

Hi again,

A clarification about one point here - I had overlooked “close-by”, now I think I understand the attack: this is a host on the same WiFi network, spoofing packets, and sending NACKs (or DupACKs, for TCP, probably) - right?

See below:

Yet, the QUIC protocol makes ACKs part of the protected payload. Having the ACKs protected by the frame protection allows ensuring that nobody had meddled with the ACKs - and by this to avoid an entire class of attacks that put a close-by endpoint which NACKs segments.

Were such attacks a real problem before QUIC was designed? And besides, aren’t MASQUE proxies visible and authenticated?

So this seems not to be a matching answer for the attack that I now think you have in mind.
Here’s another answer: this is solved by encryption between the host and the MASQUE proxy. That’s okay, I’m not questioning this part of the design. What I say is: the MASQUE proxy itself shouldn’t have to relay e2e-encrypted transport headers (which I *believe* it does, but I really still have some catching-up to do). (and of course I also don’t speak against the e2e encryption of payload!)

Cheers,
Michael