Re: [quicwg/base-drafts] RESET_STREAM should be allowed in 0-RTT packets (#2344)

[Martin Thomson <[e-mail]>]

Bring the discussion back from #2355.  I'm thinking about @marten-seemann's comment there and I think that it would be easier if we were able to permit any frame type in 0-RTT (except CRYPTO, which has nothing to carry).

In thinking about this, the main concern is whether there is any replay risk associated with any of these frames.  Going through each, I didn't find anything.  Though replay does result in spurious state being created, it's all transient and connection-bound, not application state.  In general, all connection-level control messages affect only connection state, which goes away when the connection goes away.  And replayed 0-RTT always results in the connection being thrown out as the full handshake cannot successfully complete twice.

There might be some application-level significance to resetting streams in addition to carrying stream data, particularly when you consider the potential for selective replay.  An attacker with sufficient knowledge of the contents of packets could replay some packets and not others to effect changes.  But while the signals that a server application might receive are different, they are not outside of the range of possible signals that a client accepts as possible when sending the 0-RTT.  That is, if the server receives a partial stream rather than a complete stream, that is a potential outcome that the client has to accept as a possibility even when there is no attack.

If there are lasting application-layer effects from a RESET_STREAM (or STOP_SENDING), then this might cause problems.  But the application actively chooses to accept those risks by triggering these actions before the handshake is complete.

In addition, RESET_STREAM is a poor carrier for state-changing action because its semantics are better suited to abandoning state-changing effects, not creating them.  It would be a poor choice in protocol design to carry any application-layer signal with RESET_STREAM that implied a need for some action.  HTTP does this with CONNECT in a way, but that is only to match with a TCP RST and comes with no real expectation of it being reliable.

In the end, I conclude that we should permit all frames in 0-RTT and 1-RTT.  While there is some increased risk here, I think that this is best left to the 0-RTT profile for the protocol that uses QUIC.  For HTTP, where the only application-layer effect RESET_STREAM can have is to cancel requests, the result is to reduce exposure to replay.  Other protocols will need to make their own assessment about safety, but I don't anticipate problems.

I'll adjust #2355 to match.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2344#issuecomment-456206965