Subject: [quicwg/base-drafts] use key update for confirming the handshake (#3141)

From: Kazuho Oku <[email-masked]>
Date: Wed, 23 Oct 2019 19:18:31 -0700

wip
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * use Key Update to signal that the transmission of handshake data is done

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3141.patch
https://github.com/quicwg/base-drafts/pull/3141.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/3141

---

From: Nick Banks <[email-masked]>
Date: Wed, 23 Oct 2019 20:31:39 -0700

I like the idea. I'm a big fan of the explicit signal, and I do like the added bonus of exercising key updates. I took a quick look at the text and it looks fine to me. I have to think about it more before I sign off on it completely though.

-- 
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/3141#issuecomment-545727318

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Oct 2019 20:38:09 -0700

martinthomson requested changes on this pull request.

This lacks motivating force.  You have to not only initiate a key update, but keep sending packets in order to drive this to completion.  When responding to a key update in this case, you also need to keep sending packets.

Having the initiator of the key update send an ack-eliciting packet might suffice to ensure that this process drives to completion.  But we still don't require a packet on PTO, so it would need to be even stronger than that.  If the initiator keeps sending ack-eliciting packets, it's peer will be forced to acknowledge them and this will eventually resolve itself, but without that this could hang like before.

-- 
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/3141#pullrequestreview-306304093

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 23 Oct 2019 20:45:57 -0700

@martinthomson I agree with the observation. However, I do not think that's a problem.

Current spec does not mandate endpoints to reach handshake confirmation. It is something an endpoint might do. Quoting from [section 4.10.2](https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#rfc.section.4.10.2): _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._

This PR retains that property. We can change the property, but I do not think that there is a need to.

-- 
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/3141#issuecomment-545730336

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 23 Oct 2019 21:02:33 -0700

janaiyengar commented on this pull request.

A few suggestions, but I like this approach.

> @@ -383,15 +383,26 @@ requirement that is based on the completion of the handshake depends on the
 perspective of the endpoint in question.

+### Handshake Acknowledged {#handshake-acknowledged}
+
+In this document, the TLS handshake is considered acknowledged at an endpoint
+when the handshake is complete and either of the following two conditions is
+met:
+
+- all the data sent using Handshake packets have been acknowledged
+- the peer initiates a key update ({{key-update}})

```suggestion
- a key update is received from the peer ({{key-update}})
```

>  ### 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
-former, the handshake is confirmed.
+it receives a packet initiating a key update.  The transition from handshake
+acknowledged to handshake confirmed happens immediately when the endpoint
+receives a key update.

I think it may be worth noting that the endpoint reaches this state before it sends a key update response.

> @@ -383,15 +383,26 @@ requirement that is based on the completion of the handshake depends on the
 perspective of the endpoint in question.

+### Handshake Acknowledged {#handshake-acknowledged}
+
+In this document, the TLS handshake is considered acknowledged at an endpoint
+when the handshake is complete and either of the following two conditions is
+met:
+
+- all the data sent using Handshake packets have been acknowledged
+- the peer initiates a key update ({{key-update}})
+
+When the handshake is acknowledged, the next 1-RTT packet that the endpoint
+sends MUST respond to the key update had it received a key update from peer as
+defined in {{key-update}}, else initiate a key update.
+

Suggestion: "When the handshake is acknowledged, an endpoint MUST immediately do one of the following: initiate a key update if it has not received one from the peer, or respond to the key update that the peer has initiated."

> @@ -1214,13 +1225,15 @@ 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 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.
+An endpoint MUST NOT initiate a key update until the handshake is acknowledged
+({{handshake-acknowledged}}).  Once the handshake is acknowledged, an endpoint

```suggestion
({{handshake-acknowledged}}).

Once the handshake is acknowledged, an endpoint
```

-- 
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/3141#pullrequestreview-306304630

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Oct 2019 21:10:39 -0700

@kazuho, the problem I'm concerned about is asymmetry around this new proposed condition.

This doesn't work because you establish a discard point that is reliably "synchronized" between endpoints.  You require that the key update is initiated, but don't require that the endpoint keeps sending packets until they are acknowledged.  Without that, you can end up in a state where an endpoint can reach the point of key discard too far ahead of its peer.

-- 
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/3141#issuecomment-545734983