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

[ianswett <[e-mail]>]

ianswett approved this pull request.

Thank you so much for defining "Handshake Complete"!

> +
+### 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.
+
+0-RTT and 1-RTT packets share the same packet number space, and 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.

```suggestion
packets, which can be done by keeping track of missing packet numbers.
```

The easiest proxy for this is whether there are multiple ACK ranges in the ACK frame, which a receiver is already tracking, FWIW.

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

+1

> -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 client state:
+
+- 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.
+- Any received 0-RTT data that the server responds to might be due to a replay
+attack.
+
+Therefore, the server's use of 1-RTT keys is limited before the handshake is
+complete.  A server MUST NOT process data from incoming 1-RTT
+protected packets before the TLS handshake is complete.  Because
+sending acknowledgments indicates that all frames in a packet have been
+processed, this means that a server cannot send acknowledgments for 1-RTT

```suggestion
processed, a server cannot send acknowledgments for 1-RTT
```

> @@ -1116,9 +1145,21 @@ 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 or equal to the former,
+another key update can be initiated.
+
+Endpoints MAY limit the number of sets of keys they retain to two sets for
+removing packet protection and one set for protecting packets.  Older keys
+can be discarded.  Updating keys multiple times rapidly can cause
+packets to be effectively lost if packets are significantly delayed.

```suggestion
packets to be effectively lost if packets are significantly reordered.
```

-- 
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-235686326