Re: New Draft: Using QUIC Stream Resets with Partial Delivery in HTTP/3

I think the level of risk depends on the use case and topology. WebTransport has very tightly defined factors. HTTP seems looser. 

What is the expectation for RESET_STREAM_AT in HTTP intermediary situations? Imagine, for example, a proxy server that is doing some concentration/fan out. If the origin blows up mid transfer, a reverse proxy today would likely RESET_STREAM. This is one of the advantages of H3 over H2. With RESET_STREAM_AT the proxy might instead try to be helpful to clients to deliver as much response data as it received from an origin using RESET_STREAM_AT. This could be weaponized to force a reverse proxy into a massive state commitment with minimal protocol cost for an attacker.

I suspect the answer is, HTTP proxies already can and do deal with similar concerns and some terse reminder/citation of this is probably sufficient.



On Tue, Jun 30, 2026, at 01:11, Martin Thomson wrote:
> On Tue, Jun 30, 2026, at 02:57, Lucas Pardue wrote:
> > The security considerations should probably highlight the risks of 
> > sharing more information with a malicious peer (that otherwise would 
> > not be sent with regular RESET_STREAM). For example, the specific 
> > details of a rejection in response content might be abused (i.e., 
> > recon) but more concerningly it also creates a new opportunity for an 
> > attacker to trigger more state commitment required to reliably send 
> > that information. That's not a reason to not use RESET_STREAM_AT but is 
> > a new consideration worth highlighting.
> 
> I don't see this as a problem.  The sender makes the decision to send whatever data, so they have complete control.  That the "reset" stream costs more to hold is worth a brief note, at most.
> 
> At least in our implementation, that cost is tiny.  Sending side, we drop everything beyond the committed point, so the total state commitment for something like WebTransport is in the order of 10s of bytes.
> 
>