Effect on stateless resets

[martinthomson]

The draft doesn't address the impact of each method of connection ID generation on how servers can use stateless resets.

Most of this is likely bound up in decisions stemming from #8. If you can guess a valid but unused connection ID, then you might be able to induce a stateless reset that could be used to kill an open connection.

As the draft only includes methods that include an explicit server identifier, it is possible that as long as valid values cannot be guessed, the effect is minimal and each server instance can have its own configured stateless reset key (or a shared key from which a per-server key is derived using a KDF).

[martinduke]

I don't understand the attack here. A given CID will deterministically map to a specific server instance. So there is no way for another server to receive a packet with that CID and generate a stateless reset. What am I missing?

There might be something here with the differing treatment of long-header vs. short-header packets, (and the option for servers to send resets on long headers), but I'll have to think about it more.

[martinduke]

As to the last point, nope: even a long header with a DCID that conforms to the server's expectations (i.e. maps to a real server) will get delivered to that server, so I don't think that's an attack.

[martinduke]

@martinthomson Should we talk about this issue more, or are you satisfied enough that I can close it?

[martinthomson]

I don't see any mention of stateless reset in the draft at all. That's probably something worth addressing, even if it is to say what you have already.