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

[MikkelFJ <[e-mail]>]

mikkelfj commented on this pull request.

I like this. The HANDSHAKE_DONE has a clear point in time where it must be transmitted and retransmitted, and the client explicitly has something to send (ACKs) driving the handshake forward in a timely manner. Using the alternative key update proposal might work, but it couples somewhat separate problems tightly - e.g. if one parts will change in future versions. A done signal is a clean way to communicate this.

> @@ -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.
 

Is it clear in which PN space the HANDSHAKE_DONE frame is sent in? To me it seems it could be in either 1-RTT or HS PN. But going forward - since HS keys must be dropped and done must be transmitted, it then follows it must be 1-RTT.

> @@ -760,14 +756,12 @@ and ignoring any outstanding Initial packets.
 
 ### Discarding Handshake Keys
 
-An endpoint MUST NOT discard its handshake keys until the TLS handshake is
-confirmed ({{handshake-confirmed}}).  An endpoint SHOULD discard its handshake
-keys as soon as it has confirmed the handshake.  Most application protocols
-will send data after the handshake, resulting in acknowledgements that allow
-both endpoints to discard their handshake keys promptly.  Endpoints that do
-not have reason to send immediately after completing the handshake MAY send
-ack-eliciting frames, such as PING, which will cause the handshake to be
-confirmed when they are acknowledged.
+An endpoint MUST discard its handshake keys when the TLS handshake is confirmed

By having MUST dropped (or not further processes which to me is the same), there cannot be replayed packet attacks from handshake or injected packets by partially trusted co-processing logic to setup connections. I'm not sure these are valid concerns, but I don't see any benefits in keeping the handshake either. Notably, coalesced packets with a handshake packet can immediately be dropped if MUST discard is true.

Vague memory: there is a situation where a peer might want to send on invalid packet with a valid CID in order for reflection to work with ECN / RESET or something. I just don't recall what it is, only that I'm the only one disliking this "hack". However, if this "hack" relies on handshake keys being available, it won't work when they are not available, obviously.

-- 
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#pullrequestreview-306523149