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

[Martin Thomson <[e-mail]>]

martinthomson approved this pull request.

Lots of editorial suggestions, but nothing technical.  This looks good.

> +
+In this document, the TLS handshake is considered complete when the TLS stack
+has reported that the handshake is complete.  This happens when the TLS stack
+has both sent a Finished message and verified the peer's Finished message.
+Verifying the peer's Finished provides endpoints with an assurance that
+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 ACK for a packet sent with 1-RTT keys.  This second condition

```suggestion
has received an acknowledgment for a packet sent with 1-RTT keys.  This second condition
```

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

Right now, this removed statement is still true, so I think we should retain it.

> @@ -724,6 +703,36 @@ 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, ensuring the peer can discard their
+handshake keys promptly.  Applications protocols that do not MAY send
+ACK-eliciting frames encrypted with 1-RTT keys as soon as they have installed
+those send keys and until they receive an acknowledgment for one of them,

```suggestion
those send keys and until they receive an acknowledgment,
```

> @@ -724,6 +703,36 @@ 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, ensuring the peer can discard their
+handshake keys promptly.  Applications protocols that do not MAY send
+ACK-eliciting frames encrypted with 1-RTT keys as soon as they have installed
+those send keys and until they receive an acknowledgment for one of them,
+ensuring the peer can discard their handshake keys.

Sending data is a prerequisite for getting an ACK, which is a selfish thing.  You send (ACK-eliciting) data so that you get an ACK and so that you can discard handshake keys.

So this statement is incorrect as formulated.  Maybe instead:

> Endpoints that do not have reason to send immediately after completing the handshake can send ack-eliciting frames, such as PING, which will cause the handshake to be confirmed when they are acknowledged.


> +will send data after the handshake, ensuring the peer can discard their
+handshake keys promptly.  Applications protocols that do not MAY send
+ACK-eliciting frames encrypted with 1-RTT keys as soon as they have installed
+those send keys and until they receive an acknowledgment for one of them,
+ensuring the peer can discard their handshake keys.
+
+
+### 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
+client's valid 0-RTT packet could arrive after a 1-RTT packet.  Servers MAY

```suggestion
0-RTT packet could arrive after a 1-RTT packet.  Servers MAY
```

"client's" and "valid" are implied.  Fix the a/an thing separately.

> +those send keys and until they receive an acknowledgment for one of them,
+ensuring the peer can discard their handshake keys.
+
+
+### 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
+client's valid 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.  There is a bound
+on how long these keys can be temporarily retained: servers MUST have discarded

Drop the lead-in.  "Servers MUST discard 0-RTT within three times the Probe Timeout (...) of receiving a 1-RTT packet."

> +### 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
+client's valid 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.  There is a bound
+on how long these keys can be temporarily retained: servers MUST have discarded
+0-RTT keys once three times the Probe Timeout (PTO, see {{QUIC-RECOVERY}}) has
+elapsed after receiving a 1-RTT packet.  Servers MAY also keep track of
+received 0-RTT packet numbers as an indication that all of them have been
+received which allows them to discard 0-RTT keys earlier.

It might be easier to say "A server can drop 0-RTT keys earlier if it determines that it has received all 0-RTT packets, which can be done by tracking packet numbers."

> @@ -1086,25 +1098,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

Two open parentheses, one close in this point.  I think that you can replace the first with a comma.

> @@ -1086,25 +1098,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]).

```suggestion
Section 4.2.11 of {{!TLS13}}.
```

> @@ -1086,25 +1098,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

```suggestion
pre-shared key and validated the client's 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.
+- 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.  Note that, since

```suggestion
protected packets before the TLS handshake is complete.  Because
```

> @@ -1116,9 +1147,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 ACK for a packet sent at the previous

```suggestion
key update until it has received an acknowledgment for a packet sent at the current
```

> @@ -1116,9 +1147,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 ACK for a packet sent at the previous
+KEY_PHASE.  This can be implemented by tracking the lowest packet number sent
+with the previous KEY_PHASE, and the highest value of the Largest Acknowledged

```suggestion
with each KEY_PHASE, and the highest value of the Largest Acknowledged
```

> @@ -1116,9 +1147,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 ACK for a packet sent at the previous
+KEY_PHASE.  This can be implemented by tracking the lowest packet number sent
+with the previous KEY_PHASE, and the highest value of the Largest Acknowledged
+field in any received 1-RTT ACK frame: once the latter is higher than the

```suggestion
packet for the packet number space: once the latter is higher than the
```

> @@ -1116,9 +1147,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 ACK for a packet sent at the previous
+KEY_PHASE.  This can be implemented by tracking the lowest packet number sent
+with the previous KEY_PHASE, and the highest value of the Largest Acknowledged
+field in any received 1-RTT ACK frame: once the latter is higher than the
+former, another key update can be initiated.
+
+Endpoints only need to maintain the two latest sets of packet protection keys

```suggestion
Endpoints are required to maintain at most two latest sets of packet protection keys
for removing packet protection and one set of keys for protecting packets.  Older
keys MAY be discarded.  Updating keys multiple times rapidly can cause
```

> @@ -1116,9 +1147,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 ACK for a packet sent at the previous
+KEY_PHASE.  This can be implemented by tracking the lowest packet number sent
+with the previous KEY_PHASE, and the highest value of the Largest Acknowledged
+field in any received 1-RTT ACK frame: once the latter is higher than the
+former, another key update can be initiated.
+
+Endpoints only need to maintain the two latest sets of packet protection keys
+and MAY discard older keys.  Updating keys multiple times rapidly can cause

I really want multi-line suggestions...
```suggestion
```

> -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 ACK for a packet sent at the previous
+KEY_PHASE.  This can be implemented by tracking the lowest packet number sent
+with the previous KEY_PHASE, and the highest value of the Largest Acknowledged
+field in any received 1-RTT ACK frame: once the latter is higher than the
+former, another key update can be initiated.
+
+Endpoints only need to maintain the two latest sets of packet protection keys
+and MAY discard older keys.  Updating keys multiple times rapidly can cause
+packets to be effectively lost if packets are significantly delayed.
+Therefore, an endpoint SHOULD NOT initiate a key update until three times the
+PTO after it has last updated keys. This avoids valid reordered packets being
+dropped by the peer because the peer could have discarded older keys.

```suggestion
dropped by the peer as a result of the peer discarding older keys.
```

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