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
