[quicwg/base-drafts] Handling of connection ID in handshake creates corner cases (#843)

[Christian Huitema <[e-mail]>]

I just finished writing a test case to replicate a failure mode that I observed during interop testing. The test case goes as follow:

1) start connection #1 from client to server;

2) nuke connection #1 at the client side because something went wrong, as it often does during interop tests;

3) start connection #2 from client to server, using the same 5-tuple as connection #1.

The good news is that in most case I can make it work, the connection #2 succeeds and the test passes. The bad news is that there is one corner case that creates random failures. After the client sends the Client Initial packet it is waiting for a "server clear text" message, and it can receive either:

* the "server clear text" message generated by the server in response to the client initial packet of connection #2;

* or, a retransmission of the "server clear text" message of connection #1, because it was not yet acknowledged when connection #1 was nuked.

If the client accepts the message from connection #1, it will set the connection ID to the connection #1 value, and the TLS handshake will fail because #1 and #2 used different key shares. So the client really wants to pick the "right" server clear text message. But as far as QUIC is concerned, there is no easy way to tell, since both messages carry a connection ID that is unrelated to the client-chosen initial connection ID.

Do we want to handle that corner case?

-- 
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/843