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

[Kazuho Oku <[e-mail]>]

@martinthomson 
> 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.

The problem with 0-RTT in QUIC is that, unlike TLS 1.3 (that has max_early_data_size), there is no limit in the amount of data that the client can send using the 0-RTT key. IIUC, currently, it's entirely up to the client to decide when it switches from 0-RTT to 1-RTT keys.

As we know, Initial and 0-RTT packets can be replayed against different servers within a server cluster that does not (cannot) implement the use-only-once rule for the session tickets. I am concerned that widening how 0-RTT packets can be used might lead to additional exposure to the attack surface.

An attack would go like this:
1. an attacker creates a legitimate connection and obtains a session ticket
2. the attacker reconnects using the session ticket, and exchanges lots of information with the server (involving MAX_DATA, MAX_STREAMS, etc.). However, the attacker sticks to using 0-RTT for packets it emits, even after the handshake is complete.
3. simultaneously, the attacker creates many QUIC connections using the same Initial packet as that of step 2, and then sends the copied 0-RTT packets. The server will handle those and commit state. Because the client never responds with an 1-RTT ACK, the connection will eventually die. However, a client can create a connection with huge PTO (by delaying Initial packets) to have enough time to let the server accept many packets.

IMO it is preferable to allow less frames in 0-RTT packets, because it narrows the attack vector.

-- 
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-456233537