Re: [quicwg/base-drafts] use a HANDSHAKE_DONE frame to drive the handshake to confirmation (#3145)

[ianswett <[e-mail]>]

ianswett commented on this pull request.



> @@ -385,13 +385,9 @@ perspective of the endpoint in question.
 
 ### Handshake Confirmed {#handshake-confirmed}
 
-In this document, the TLS handshake is considered confirmed at an endpoint when
-the following two conditions are met: the handshake is complete, and the
-endpoint has received an acknowledgment for a packet sent with 1-RTT keys.
-This second condition can be implemented by recording the lowest packet number
-sent with 1-RTT keys, and the highest value of the Largest Acknowledged field
-in any received 1-RTT ACK frame: once the latter is higher than or equal to the
-former, the handshake is confirmed.
+In this document, the TLS handshake is considered confirmed at the server when
+the handshake completes. At the client, the handshake is considered confirmed
+when the HANDSHAKE_DONE frame is received.

The server could also not send anything in Handshake and force the client to continue using 0RTT packets, which seems equivalent to what you're describing?  If so, then this is nothing new.

Maybe we need more motivating text about why you really need to send HANDSHAKE_DONE, but I think this design is generally quite efficient.

If we REALLY want to ensure the client gets the signal, we can add a key phase flip between 0.5RTT and 1RTT as well, but then do we change keys as well?

-- 
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/3145#discussion_r339227362