Re: [quicwg/base-drafts] Most the Retry-related fixes (#1788)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> @@ -593,37 +593,40 @@ The server populates the Destination Connection ID with the connection ID that
 the client included in the Source Connection ID of the Initial packet.
 
 The server includes a connection ID of its choice in the Source Connection ID
-field.  The client MUST use this connection ID in the Destination Connection ID
-of subsequent packets that it sends.
+field.  This value MUST not be equal to the Destination Connection ID field of

Yes, this isn't obvious until you read #1784.  In that case, the reuse of a connection ID causes the client to be confused about what belongs to what.

The problem @tatsuhiro-t identified is that the client can respond to a Retry, then receive a valid Initial in response to a packet sent before that Retry, but it is one that is incompatible with its current TLS state.  This assumes that the client has changed its ClientHello somehow in response to the Retry, which we encourage, but don't mandate.

Forcing the change of connection ID means that a client that receives a Retry will drop anything sent by the server in response to any Initial packets sent before receiving the Retry.  So, if a retransmission of the first round of Initial packets gets a real response, that will just be dropped.

-- 
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/pull/1788#discussion_r219703682