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

From: David Schinazi <[email-masked]>
Date: Tue, 07 May 2019 14:20:43 -0700

This PR is the output of the discard keys design team, and has reached consensus amongst design team members (modulo wordsmithing). It describes methods for discarding QUIC packet protection keys, and adds normative text to ensure that this mechanism is not vulnerable to deadlocks. This PR also formalizes the concept of handshake complete and handshake confirmed. Finally, this PR also moved some text around to avoid repetitions.

We believe that this PR prevents the potential deadlocks discussed in issues #2214 and #2267.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2673

-- Commit Summary --

  * First draft of the output of the discard keys design team
  * Incorporated feedback from Martin Thomson and Marten Seeman
  * Make discarding handshake keys a SHOULD
  * Further review comments from Martin Thomson
  * Comments from EKR
  * More changes from MT and EKR
  * Merge branch 'master' into design_team_discard_keys

-- File Changes --

    M draft-ietf-quic-tls.md (170)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2673.patch
https://github.com/quicwg/base-drafts/pull/2673.diff

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

---

From: David Schinazi <[email-masked]>
Date: Tue, 07 May 2019 21:24:27 +0000 (UTC)

@DavidSchinazi pushed 1 commit.

1897ccb6b766c814f9fa632bfae031777b79e402  Fix markdown typo

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2673/files/7e8b38695bba4fa0d83a6ccf10083cd02f8bb12a..1897ccb6b766c814f9fa632bfae031777b79e402

---

From: Martin Thomson <[email-masked]>
Date: Tue, 07 May 2019 16:45:19 -0700

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

---

From: David Schinazi <[email-masked]>
Date: Tue, 07 May 2019 16:54:35 -0700

DavidSchinazi commented on this pull request.

This statement existed because previously there was an "all the keys except initial" section and an "initial keys" section. Now each flavor of keys has its own section so pointing out initial specifically here seems odd.

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

---

From: David Schinazi <[email-masked]>
Date: Tue, 07 May 2019 17:10:02 -0700

I'm not sure this is correct. An endpoint can maintain more than 2 sets of keys if it so chooses.

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

---

From: David Schinazi <[email-masked]>
Date: Tue, 07 May 2019 17:13:07 -0700

850f1b10d0438cce42e61de81af4423bb028ed7e  Editorial pass from MT

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2673/files/1897ccb6b766c814f9fa632bfae031777b79e402..850f1b10d0438cce42e61de81af4423bb028ed7e

---

From: David Schinazi <[email-masked]>
Date: Tue, 07 May 2019 17:13:15 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Tue, 07 May 2019 17:13:23 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Tue, 07 May 2019 17:13:30 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Tue, 07 May 2019 17:13:34 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Wed, 08 May 2019 00:13:41 +0000 (UTC)

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Tue, 07 May 2019 17:13:47 -0700

+

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Tue, 07 May 2019 17:13:53 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Tue, 07 May 2019 17:13:58 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Tue, 07 May 2019 17:14:04 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Tue, 07 May 2019 17:14:11 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Tue, 07 May 2019 17:14:18 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Tue, 07 May 2019 17:14:23 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Tue, 07 May 2019 17:14:38 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Tue, 07 May 2019 17:14:48 -0700

Fixed

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 07 May 2019 17:26:03 -0700

martinthomson commented on this pull request.

Ahh, my bad.  I added the wrong implication.

```suggestion
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
```

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

---

From: MikkelFJ <[email-masked]>
Date: Wed, 08 May 2019 00:35:56 -0700

mikkelfj commented on this pull request.

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

Why is this not "Once the largest acknowledged is higher than or **equal** to the smallest 1-RTT packet number sent?

> @@ -724,6 +703,35 @@ This results in abandoning loss recovery state for the Initial encryption level

+### 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.
+

Why not make this a MUST, or at least SHOULD, such that a hanshake timeout can close much earlier than Idle timeout?

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

This is a bit hard to understand if you are not aware that 1-RTT and 0-RTT have the same packet number space, so perhaps make a note of that.

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

This text is a bit overlapping with previous section recommending sending a PING frame.

> @@ -1116,9 +1146,20 @@ TLS KeyUpdate message.  Endpoints MUST treat the receipt of a TLS KeyUpdate
 
-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.
+

why not higher than or **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#pullrequestreview-234899612

---

From: Martin Thomson <[email-masked]>
Date: Wed, 08 May 2019 03:19:52 -0700

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.

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

 complete.

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.

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

---

From: MikkelFJ <[email-masked]>
Date: Wed, 08 May 2019 04:16:59 -0700

So, there is the byzantine generals problem (messengers get shot, so you never really know until you do), but relying on ACK for handshake complete could lead to long delays if the ACK packet is lost. For crypto there is an aggressive retransmission timer, but I'm not sure that applies to the handshake complete transition.

-- 
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#issuecomment-490447135

---

From: Christopher Wood <[email-masked]>
Date: Wed, 08 May 2019 07:15:29 -0700

chris-wood commented on this pull request.

```suggestion
keys as soon as it has confirmed the handshake.  Most application protocols
```

nit: should "do not" be "MUST NOT" to mirror the text below which reads, "Once a client has installed 1-RTT keys, it MUST NOT send any more 0-RTT packets."?

> @@ -1086,25 +1097,44 @@ before the final TLS handshake messages are received.  A client will be unable

```suggestion

```

> @@ -1086,25 +1097,44 @@ before the final TLS handshake messages are received.  A client will be unable

```suggestion
handshake messages from a client, it is missing assurances on the client state:
```

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

---

From: David Schinazi <[email-masked]>
Date: Wed, 08 May 2019 13:57:07 -0700

This text is in section 4.9, and the relevant sections are 4.9.1, 4.9.2 and 4.9.3 so the reader can see them coming over the horizon. Or do you mean other sections?

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

---

From: David Schinazi <[email-masked]>
Date: Wed, 08 May 2019 14:01:34 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Wed, 08 May 2019 14:01:43 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Wed, 08 May 2019 14:02:31 -0700

Good catch, fixed

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

---

From: David Schinazi <[email-masked]>
Date: Wed, 08 May 2019 14:04:16 -0700

I agree with @martinthomson, discarding handshake keys is not a security requirement. And in practice if an application protocol never sends ACK-soliciting frames it's probably not very useful...

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

---

From: David Schinazi <[email-masked]>
Date: Wed, 08 May 2019 14:05:59 -0700

+

Good point, added that.

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

---

From: David Schinazi <[email-masked]>
Date: Wed, 08 May 2019 14:06:52 -0700

complete.

Agree with @martinthomson, this is about leveraging coalesced packets to avoid head of line blocking, not about trying to elicit ACKs at 1-RTT

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

---

From: David Schinazi <[email-masked]>
Date: Wed, 08 May 2019 14:06:58 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Wed, 08 May 2019 14:08:42 -0700

> So, there is the byzantine generals problem

@mikkelfj these ACKs uses the next level of keys, and that's the property that solves the two-general problem. The signal comes out of band so we don't need to rely on a given level reaching consensus

-- 
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#issuecomment-490651579

---

From: David Schinazi <[email-masked]>
Date: Wed, 08 May 2019 14:09:25 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Wed, 08 May 2019 14:10:21 -0700

The idea here was to state a fact, with a reference to the normative text. I thought that was preferable to repeating the normative text.

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

---

From: David Schinazi <[email-masked]>
Date: Wed, 08 May 2019 14:10:54 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Wed, 08 May 2019 14:11:02 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Wed, 08 May 2019 14:11:41 -0700

ea39e6b7c0ff79f43d1bfc64174431dbf356e144  More review comments from MT mikkelfj and CAW

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2673/files/850f1b10d0438cce42e61de81af4423bb028ed7e..ea39e6b7c0ff79f43d1bfc64174431dbf356e144

---

From: Mike Bishop <[email-masked]>
Date: Wed, 08 May 2019 16:14:01 -0700

MikeBishop commented on this pull request.

Also I believe we've been using "greater than" instead of "higher than" when talking about 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.

-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

---

From: ianswett <[email-masked]>
Date: Thu, 09 May 2019 09:12:48 -0700

ianswett commented on this pull request.

+### 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.
```

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

---

From: ianswett <[email-masked]>
Date: Thu, 09 May 2019 09:17:20 -0700

ianswett approved this pull request.

Thank you so much for defining "Handshake Complete"!

```suggestion

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

+1

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

---

From: David Schinazi <[email-masked]>
Date: Thu, 09 May 2019 13:44:53 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Thu, 09 May 2019 13:45:14 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Thu, 09 May 2019 13:46:12 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Thu, 09 May 2019 20:46:44 +0000 (UTC)

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Thu, 09 May 2019 13:50:50 -0700

@DavidSchinazi pushed 2 commits.

964950879b7196308d23f615b5a8594244b3b743  Review comments from Ian Swett and Mike Bishop
869d1d30f690f20afa04cb7c465bc28ebb3448e8  Merge branch 'master' into design_team_discard_keys

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2673/files/ea39e6b7c0ff79f43d1bfc64174431dbf356e144..869d1d30f690f20afa04cb7c465bc28ebb3448e8

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 10 May 2019 20:22:25 -0700

janaiyengar commented on this pull request.

Great work, @DavidSchinazi ! A bunch of comments, but only minor editorial.

> @@ -369,6 +369,29 @@ primary functions:
 Additional functions might be needed to configure TLS.

+### Handshake Complete {#handshake-complete}
+

```suggestion
Verifying the peer's Finished provides the endpoint with an assurance that
```

> @@ -369,6 +369,29 @@ primary functions:
 Additional functions might be needed to configure TLS.

+### Handshake Complete {#handshake-complete}
+

```suggestion
does not complete at both endpoints simultaneously.  Consequently, any requirement
```

> @@ -369,6 +369,29 @@ primary functions:
 Additional functions might be needed to configure TLS.

+### Handshake Complete {#handshake-complete}
+

```suggestion
that is based on the completion of the handshake is based on the perspective of the endpoint in question.
```

> @@ -369,6 +369,29 @@ primary functions:
 Additional functions might be needed to configure TLS.

+### Handshake Complete {#handshake-complete}
+

```suggestion
In this document, the TLS handshake is considered confirmed at an endpoint when the
```

> +### Handshake Complete {#handshake-complete}
+

```suggestion
following two conditions are met: the handshake is complete, and the endpoint
```

+received 1-RTT ACK frame: once the latter is higher than or equal to the
+former, the handshake is confirmed.

Suggested rephrase:
"An endpoint can implement this second predicate by recording the lowest packet number sent with 1-RTT keys.  When the largest acknowledged packet number in any received 1-RTT ACK frame matches or exceeds the recorded packet number, the handshake is confirmed."

+keys as soon as it has confirmed the handshake.  Most application protocols

```suggestion
will send data after the handshake, resulting in acknowledgements that allow
```
The application is not ensuring anything about acks or handshake keys

+keys as soon as it has confirmed the handshake.  Most application protocols

```suggestion
both endpoints to discard their handshake keys promptly.  Endpoints that
```

+keys as soon as it has confirmed the handshake.  Most application protocols

```suggestion
do not have reason to send immediately after completing the handshake might cause
```
Application does not send PINGs, it causes PING to be sent. MAY suggests permission, which isn't required here, you only need a statement of what might happen.

+keys as soon as it has confirmed the handshake.  Most application protocols

```suggestion
ack-eliciting frames, such as PING, to be sent, resulting in the handshake getting
```

+keys as soon as it has confirmed the handshake.  Most application protocols

```suggestion
A client SHOULD discard 0-RTT keys as soon as it installs 1-RTT keys, since
```

+
+keys as soon as it has confirmed the handshake.  Most application protocols

```suggestion
the client does not send 0-RTT encrypted packets thereafter (see {{using-early-data}}).
```

```suggestion
1-RTT keys.  After receiving a 1-RTT packet, servers MUST discard 0-RTT keys within a short time; the RECOMMENDED time period is three times the Probe
```

+
+

```suggestion
Timeout (PTO, see {{QUIC-RECOVERY}}).  A server
```

> @@ -1116,9 +1144,21 @@ TLS KeyUpdate message.  Endpoints MUST treat the receipt of a TLS KeyUpdate

Suggest similar rewording to earlier

> @@ -1116,9 +1144,21 @@ TLS KeyUpdate message.  Endpoints MUST treat the receipt of a TLS KeyUpdate

```suggestion
Endpoints MAY limit the number of keys they retain to two sets for
```

+packets to be effectively lost if packets are significantly reordered.

```suggestion
Therefore, an endpoint SHOULD NOT initiate a key update for some time after it has last updated keys; the RECOMMENDED time period is three times the PTO value.
```

+packets to be effectively lost if packets are significantly reordered.

```suggestion
This avoids valid reordered packets being
```

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

---

From: MikkelFJ <[email-masked]>
Date: Fri, 10 May 2019 23:38:51 -0700

> @mikkelfj these ACKs uses the next level of keys, and that's the property that solves the two-general problem. The signal comes out of band so we don't need to rely on a given level reaching consen…

Right - so the lost ACK is solved because of regular 1-RTT retransmission logic which kicks in after Handshake Complete but before Handshake Confirmed.

-- 
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#issuecomment-491484759

---

From: David Schinazi <[email-masked]>
Date: Sat, 11 May 2019 12:20:35 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Sat, 11 May 2019 12:24:24 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Sat, 11 May 2019 12:24:31 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Sat, 11 May 2019 12:25:51 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Sat, 11 May 2019 12:26:08 -0700

+

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Sat, 11 May 2019 12:29:03 -0700

I think I prefer the current wording. I'm afraid the suggestion could be confusing a reader that starts searching for the definition of a "recorded packet number".

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

---

From: David Schinazi <[email-masked]>
Date: Sat, 11 May 2019 12:30:12 -0700

Good point, fixed.

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

---

From: David Schinazi <[email-masked]>
Date: Sat, 11 May 2019 12:30:27 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Sat, 11 May 2019 12:33:48 -0700

The subject of this sentence is endpoints, not applications. Also, MAY is a RFC 2119 keyword, which does not suggest permission. I think the current text gives implementations an option.

> MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

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

---

From: David Schinazi <[email-masked]>
Date: Sat, 11 May 2019 12:35:18 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Sat, 11 May 2019 12:39:45 -0700

+

Fixed by reordering statements in this section

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

---

From: David Schinazi <[email-masked]>
Date: Sat, 11 May 2019 12:42:03 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Sat, 11 May 2019 12:42:10 -0700

+
+

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Sat, 11 May 2019 12:43:48 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Sat, 11 May 2019 12:45:24 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Sat, 11 May 2019 12:45:34 -0700

Fixed

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

---

From: David Schinazi <[email-masked]>
Date: Sat, 11 May 2019 12:46:41 -0700

fcca9015fbe7fd77e5e3cd4f0c98c5d57e90a924  Editorial pass from Jana

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2673/files/869d1d30f690f20afa04cb7c465bc28ebb3448e8..fcca9015fbe7fd77e5e3cd4f0c98c5d57e90a924

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 14 May 2019 15:35:29 -0700

janaiyengar approved this pull request.

Just a couple of tiny nits, but LGTM. Thanks for working through this patiently!

I would at least suggest using "recording" instead of "tracking". It's a single event, not a continuous tracking.

> @@ -1116,9 +1146,22 @@ TLS KeyUpdate message.  Endpoints MUST treat the receipt of a TLS KeyUpdate

```suggestion
current KEY_PHASE.  This can be implemented by recording the lowest packet
```

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

---

From: David Schinazi <[email-masked]>
Date: Wed, 15 May 2019 15:38:36 -0700

Makes sense, fixed

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

---

From: David Schinazi <[email-masked]>
Date: Wed, 15 May 2019 15:39:20 -0700

d84e75e543997ecb8b1fb5e1cc1c68c61b5b5e13  minor change from Jana

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2673/files/fcca9015fbe7fd77e5e3cd4f0c98c5d57e90a924..d84e75e543997ecb8b1fb5e1cc1c68c61b5b5e13

---

From: David Schinazi <[email-masked]>
Date: Wed, 15 May 2019 15:39:42 -0700

Fixed

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

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 15 May 2019 17:05:01 -0700

A little bit of editorializing, with one important change.

+has both sent a Finished message and verified the peer's Finished message.
+Verifying the peer's Finished provides the endpoints with an assurance that
+previous handshake messages have not been modified.  Note that the handshake
+does not complete at both endpoints simultaneously.  Consequently, any
+requirement that is based on the completion of the handshake depends on the
+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

```suggestion
sent with 1-RTT keys, and comparing it to the Largest Acknowledged field
```

> +has both sent a Finished message and verified the peer's Finished message.
+Verifying the peer's Finished provides the endpoints with an assurance that
+previous handshake messages have not been modified.  Note that the handshake
+does not complete at both endpoints simultaneously.  Consequently, any
+requirement that is based on the completion of the handshake depends on the
+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

```suggestion
in subsequently received 1-RTT ACK frames; once the latter is higher than or equal to the
```

Not showing up in this diff yet, did you push your changes?

```suggestion
number sent with each KEY_PHASE, and comparing it to the Largest Acknowledged packet number
```

```suggestion
in subsequently received ACK frames in the current KEY_PHASE; once the latter is higher than or equal to the former,
```

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

---

From: David Schinazi <[email-masked]>
Date: Wed, 15 May 2019 17:32:29 -0700

Hi @janaiyengar, your latest editorializing suggestions are backing out what I had changed in response to previous comments from other editors. I'm going to declare that this PR "good enough to land" from an editorial standpoint, meaning that I'd rather stop making editorial changes now. Once we confirm WG consensus and this PR lands, the editors will be free to make editorial changes.

Regarding the addition of "in the current key phase" at line 1154, that is not necessary because you cannot go back to previous key phases with increasing packet numbers. And you can't receive an ACK for a packet for a subsequent key phase because this MUST prevents you from getting there in the first place.

-- 
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#issuecomment-492872027

---

From: David Schinazi <[email-masked]>
Date: Wed, 15 May 2019 17:33:19 -0700

Resolving as editorial, this change can be made by the editors after this PR lands.

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

---

From: David Schinazi <[email-masked]>
Date: Wed, 15 May 2019 17:33:24 -0700

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

---

From: David Schinazi <[email-masked]>
Date: Wed, 15 May 2019 17:33:34 -0700

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

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 15 May 2019 17:49:10 -0700

@DavidSchinazi : Fair enough, I'm fine with the PR as it is, and I'm happy to do more editorializing work later. Thanks for clarifying the point about 1RTT packets, that makes sense.

-- 
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#issuecomment-492874768