Re: [quicwg/base-drafts] Output of the discard keys design team (#2673)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> @@ -655,8 +662,7 @@ alerts at the "warning" level.
 
 After QUIC moves to a new encryption level, packet protection keys for previous
 encryption levels can be discarded.  This occurs several times during the
-handshake, as well as when keys are updated (see {{key-update}}).  Initial
-packet protection keys are treated specially, see {{discard-initial}}.

I see.  That being the case, it might pay to reference all of the relevant sections here.  The statement here doesn't really reference the text that it depends on, except for key update.

> @@ -724,6 +703,35 @@ This results in abandoning loss recovery state for the Initial encryption level
 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 applications protocols
+will send data after the handshake, generating acknowledgements and ensuring
+that both endpoints can 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.
+

There's no real reason to discard those keys, so it's enough to rely on other incentives.

>  1-RTT keys MAY be stored and later decrypted and used once the handshake is
 complete.
 
+The requirement for the server to wait for the client Finished message creates
+a dependency on that message being delivered.  A client can avoid the
+potential for head-of-line blocking that this implies by sending its 1-RTT
+packets coalesced with a handshake packet containing a copy of the CRYPTO frame
+that carries the Finished message, until one of the handshake packets is
+acknowledged.  This enables immediate server processing for those packets.
+

The other suggests PING (or ack-eliciting) to induce an ACK.  This is about sending Handshake packets multiple times in order to ensure that they get through in a timely fashion.  So these aren't really the same.

> @@ -1116,9 +1146,20 @@ TLS KeyUpdate message.  Endpoints MUST treat the receipt of a TLS KeyUpdate
 message as a connection error of type 0x10a, equivalent to a fatal TLS alert of
 unexpected_message (see {{tls-errors}}).
 
-An endpoint MUST NOT initiate more than one key update at a time.  A new key
-cannot be used until the endpoint has received and successfully decrypted a
-packet with a matching KEY_PHASE.
+An endpoint MUST NOT initiate the first key update until the handshake is
+confirmed ({{handshake-confirmed}}). An endpoint MUST NOT initiate a subsequent
+key update until it has received an acknowledgment for a packet sent at the
+current KEY_PHASE.  This can be implemented by tracking the lowest packet
+number sent with each KEY_PHASE, and the highest acknowledged packet number
+in the 1-RTT space: once the latter is higher than the former, another key
+update can be initiated.
+

Yes, it should allow equal.

-- 
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/2673#discussion_r282004124