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

[Mike Bishop <[e-mail]>]

MikeBishop commented on this pull request.



> +previous handshake messages have not been modified.  Note that the handshake
+does not complete on both endpoints simultaneously, therefore any requirements
+placed on endpoints based on the completion of the handshake are specific to
+the handshake being complete from the perspective of the endpoint in question.
+
+
+### Handshake Confirmed {#handshake-confirmed}
+
+In this document, the TLS handshake is considered confirmed when both of 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 tracking 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 the former, the
+handshake is confirmed.
+

Also I believe we've been using "greater than" instead of "higher than" when talking about numbers.

> +### Discarding 0-RTT Keys
+
+Clients SHOULD discard 0-RTT keys as soon as they install 1-RTT keys, since
+they have no use after that moment.
+
+Clients do not send 0-RTT packets after sending a 1-RTT
+packet ({{using-early-data}}).  Therefore a server MAY discard 0-RTT keys as
+soon as it receives a 1-RTT packet.  However, due to packet reordering, a
+0-RTT packet could arrive after a 1-RTT packet.  Servers MAY temporarily retain
+0-RTT keys to allow decrypting reordered packets without requiring their
+contents to be retransmitted with 1-RTT keys.  Servers MUST discard 0-RTT keys
+within three times the Probe Timeout (PTO, see {{QUIC-RECOVERY}}) after
+receiving a 1-RTT packet.  A server MAY discard 0-RTT keys earlier if it
+determines that it has received all 0-RTT packets, which can be done by
+keeping track of packet numbers.
+

Maybe be even more explicit and say how?  "...if it has received all packets with packet numbers less than the packet number of the lowest 1-RTT packet received" or something less wordy but similar.

> @@ -1086,25 +1097,44 @@ before the final TLS handshake messages are received.  A client will be unable
 to decrypt 1-RTT packets from the server, whereas a server will be able to
 decrypt 1-RTT packets from the client.
 
-However, a server MUST NOT process data from incoming 1-RTT protected packets
-before verifying either the client Finished message or - in the case that the
-server has chosen to use a pre-shared key - the pre-shared key binder (see
-Section 4.2.11 of {{!TLS13}}).  Verifying these values provides the server with
-an assurance that the ClientHello has not been modified.  Packets protected with
+Even though 1-RTT keys are available to a server after receiving the first
+handshake messages from a client, it is missing assurances on the state of the
+client:
+
+- The client is not authenticated, unless the server has chosen to use a
+pre-shared key and validated the client's pre-shared key binder; see
+Section 4.2.11 of {{!TLS13}}.
+- The client has not demonstrated liveness.

...unless the server did a Retry.  I'd follow the example of the last bullet and make all of these "might not be authenticated, unless..." and "might not have demonstrated liveness...."

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