Re: [New Issue] CID based attacks

[Dmitri Tikhonov <[e-mail]>]

Hello Kashyap,

Thank you for this research.

I will think about the security implications of your research and so I
make no claims about it, but in the meantime, I want quickly to point out
something that you may have missed:

On Thu, Nov 12, 2020 at 05:34:03PM +0100, Kashyap Thimmaraju wrote:
> Hence, I posit the following: If the server (implementation) does not permit
> the use of the same destination CID across successive connections (for a
> specific timeout),

--- 8< --- snip --- 8< ---

> Finally, to obtain the results of the test, I searched the debug log of the
> client or the packet trace to confirm whether the second QUIC connection
> obtained a successful handshake or not. The absence of a successful
> handshake indicates a vulnerable implementation.

After a connection is closed, it may enter the Draining State [1], during
which it will ignore incoming packets with that connection's CIDs for a
period of time.

I can't speak for ATS, Chromium, and ngtcp2, but the failure to handshake
with an already-used DCID with a LiteSpeed server is most likely due to
the Draining State: it simply does not have any other rules precluding
CID reuse.  If you hit up any of the LiteSpeed public interop endpoints
[2] and give me the CID(s) you used, I will look up relevant sections
of the log file and provide them to you.

My question would be:  Why aren't connections in the other 11 implementations
enter the Draining State?

  - Dmitri.

1. https://tools.ietf.org/html/draft-ietf-quic-transport-32#section-10.2.2
2. https://github.com/quicwg/base-drafts/wiki/Implementations#lsquic