Subject: [quicwg/base-drafts] use a HANDSHAKE_DONE frame to drive the handshake to confirmation (#3145)

From: Marten Seemann <[email-masked]>
Date: Wed, 23 Oct 2019 20:33:35 -0700

Fixes #2863. Fixes #3142.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * use a HANDSHAKE_DONE frame to drive the handshake to confirmation

-- File Changes --

    M draft-ietf-quic-tls.md (24)
    M draft-ietf-quic-transport.md (9)

-- Patch Links --

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

---

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

janaiyengar commented on this pull request.

> @@ -5495,6 +5495,15 @@ Reason Phrase:
   This SHOULD be a UTF-8 encoded string {{!RFC3629}}.

+## HANDSHAKE_DONE frame {#handshake-done-frame}
+
+The server uses the HANDSHAKE_DONE frame (type=0x1e) to signal confirmation of
+the handshake to the client.  The HANDSHAKE_DONE frame contains no additional
+fields.
+
+This frame MUST be retransmitted until it is acknowledged by the client.

Add requirement that in this version of QUIC, the client MUST NOT send this frame, and if a server receives this frame, it MUST close the connection with PROTOCOL_VIOLATION.

-- 
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/3145#pullrequestreview-306315358

---

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

I actually like this better than #3141. It is simpler.

@kazuho and I discussed the point that this solution might cause endpoints to lose some RTT and congestion signals since not all ACKs need to be received, and we believe that is ok. It might be useful to recommend that endpoints bundle ACKs when sending initial and handshake packets to allow the peer to get RTT signals as early and frequently as possible at the start of the connection, but that can be done separately.

-- 
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/3145#issuecomment-545740866

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Oct 2019 22:28:30 -0700

martinthomson commented on this pull request.

This seems workable.

> @@ -760,14 +756,12 @@ 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 application protocols
-will send data after the handshake, resulting in acknowledgements that allow
-both endpoints to 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.
+An endpoint MUST discard its handshake keys when the TLS handshake is confirmed

A "MAY" suffices here, does it not?  Or are you concerned about having to think about Handshake keys after migration?

It could be enough to say that Handshake packets MUST NOT be sent on any path other than the one on which the connection was established.

> @@ -760,14 +756,12 @@ 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 application protocols
-will send data after the handshake, resulting in acknowledgements that allow
-both endpoints to 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.
+An endpoint MUST discard its handshake keys when the TLS handshake is confirmed
+({{handshake-confirmed}}).  The server MUST send a HANDSHAKE_DONE frame when the
+handshake completes.  Most application protocols will send data after the
+handshake.  A server might want to minimize the number of packets sent by
+bundling the HANDSHAKE_DONE frame with other data.  It MAY delay sending of the

I think that you can drop the bundling sentence.

> @@ -760,14 +756,12 @@ 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 application protocols
-will send data after the handshake, resulting in acknowledgements that allow
-both endpoints to 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.
+An endpoint MUST discard its handshake keys when the TLS handshake is confirmed
+({{handshake-confirmed}}).  The server MUST send a HANDSHAKE_DONE frame when the
+handshake completes.  Most application protocols will send data after the
+handshake.  A server might want to minimize the number of packets sent by
+bundling the HANDSHAKE_DONE frame with other data.  It MAY delay sending of the
+HANDSHAKE_DONE frame by no more than one round-trip.

This delay sentence is somewhat in conflict with the preceding requirement, so maybe instead say "MUST send within 1 round-trip time of handshake completion."

You should move this statement to [Section 13.3](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#retransmission-of-information) for consistency reasons.

-- 
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/3145#pullrequestreview-306325523

---

From: Marten Seemann <[email-masked]>
Date: Wed, 23 Oct 2019 22:32:12 -0700

marten-seemann commented on this pull request.

 

There are a few things that could go wrong here, if keys aren't dropped. One is sending Handshake packets after a migration, another one is that a peer could retransmit Handshake packets after the handshake is confirmed, thereby consuming the complete congestion window.
Is there any reason to not make it mandatory?

-- 
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/3145#discussion_r338387419

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 23 Oct 2019 22:44:55 -0700

I am concerned about Handshake packets after migration, but I think @martinthomson's text seems more appropriate as a requirement. How about saying instead that Handshake packets MUST NOT be sent after the TLS handshake is 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/3145#discussion_r338389876

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 23 Oct 2019 23:02:09 -0700

kazuho commented on this pull request.

 

+1 to "MUST NOT be sent". At the same time, I do not think we need to specify when the key is discarded. Maybe "can discard" is fine?

-- 
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/3145#discussion_r338393674

---

From: Marten Seemann <[email-masked]>
Date: Thu, 24 Oct 2019 01:47:16 -0700

I'm not opposed to making this change, but I noticed that in the previous paragraph, we specify the dropping of Initial keys:

> Thus, a client MUST discard Initial keys when it first sends a Handshake packet and a server MUST discard Initial keys when it first successfully processes a Handshake packet.  Endpoints MUST NOT send Initial packets after this point.

Why do we use a MUST there, but not for Handshake keys? To prevent packet injections, it would be sufficient to say "MUST NOT process Initial packets". Should we make it consistent for both encryption levels?

-- 
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/3145#discussion_r338452317

---

From: Marten Seemann <[email-masked]>
Date: Thu, 24 Oct 2019 01:53:17 -0700

@marten-seemann pushed 1 commit.

6eac3287733b93ee8a9cfa48a8f5f8a3443b6042  more concise timing requirement

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3145/files/da1db8acd0e344f54e493c73191211ed88dc2de2..6eac3287733b93ee8a9cfa48a8f5f8a3443b6042

---

From: Marten Seemann <[email-masked]>
Date: Thu, 24 Oct 2019 01:53:18 -0700

Done.

-- 
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/3145#discussion_r338455313

---

From: Marten Seemann <[email-masked]>
Date: Thu, 24 Oct 2019 01:54:53 -0700

93620e7c2be17d722090a3ccaf38dd184bdcad52  move retransmission rule for HANDSHAKE_DONE frames

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3145/files/6eac3287733b93ee8a9cfa48a8f5f8a3443b6042..93620e7c2be17d722090a3ccaf38dd184bdcad52

---

From: Marten Seemann <[email-masked]>
Date: Thu, 24 Oct 2019 01:55:13 -0700

Done.

-- 
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/3145#discussion_r338456094

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Oct 2019 01:56:57 -0700

This isn't about consistency, it is about necessity.

-- 
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/3145#discussion_r338456928

---

From: Marten Seemann <[email-masked]>
Date: Thu, 24 Oct 2019 02:03:52 -0700

@martinthomson I don't understand your comment? What's the difference between dropping Initial keys and not processing them any more?

-- 
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/3145#discussion_r338460448

---

From: Marten Seemann <[email-masked]>
Date: Thu, 24 Oct 2019 02:07:43 -0700

d1a4dcee66481e203df7909d8499dccb330fd2a3  prohibit clients from sending HANDSHAKE_DONE

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3145/files/93620e7c2be17d722090a3ccaf38dd184bdcad52..d1a4dcee66481e203df7909d8499dccb330fd2a3

---

From: Marten Seemann <[email-masked]>
Date: Thu, 24 Oct 2019 03:00:38 -0700

That makes sense. Added it.

-- 
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/3145#discussion_r338486595

---

From: MikkelFJ <[email-masked]>
Date: Thu, 24 Oct 2019 05:23:05 -0700

mikkelfj commented on this pull request.

I like this. The HANDSHAKE_DONE has a clear point in time where it must be transmitted and retransmitted, and the client explicitly has something to send (ACKs) driving the handshake forward in a timely manner. Using the alternative key update proposal might work, but it couples somewhat separate problems tightly - e.g. if one parts will change in future versions. A done signal is a clean way to communicate this.

> @@ -385,13 +385,9 @@ 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
-former, the handshake is confirmed.
+In this document, the TLS handshake is considered confirmed at the server when
+the handshake completes. At the client, the handshake is considered confirmed
+when the HANDSHAKE_DONE frame is received.

Is it clear in which PN space the HANDSHAKE_DONE frame is sent in? To me it seems it could be in either 1-RTT or HS PN. But going forward - since HS keys must be dropped and done must be transmitted, it then follows it must be 1-RTT.

 

By having MUST dropped (or not further processes which to me is the same), there cannot be replayed packet attacks from handshake or injected packets by partially trusted co-processing logic to setup connections. I'm not sure these are valid concerns, but I don't see any benefits in keeping the handshake either. Notably, coalesced packets with a handshake packet can immediately be dropped if MUST discard is true.

Vague memory: there is a situation where a peer might want to send on invalid packet with a valid CID in order for reflection to work with ECN / RESET or something. I just don't recall what it is, only that I'm the only one disliking this "hack". However, if this "hack" relies on handshake keys being available, it won't work when they are not available, obviously.

-- 
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/3145#pullrequestreview-306523149

---

From: Mike Bishop <[email-masked]>
Date: Thu, 24 Oct 2019 08:41:40 -0700

MikeBishop commented on this pull request.

 

Handshake is done at the server upon receipt of the ClientFinished.  Once it's done, the frame is transmitted by the server, and the server is using 1-RTT keys to send.  Therefore, it has to be 1-RTT.

However, I can no longer find the section specifying which frame types are allowed in which encryption level.  This should probably be listed there, and if we've lost that text, we might have bigger problems.

-- 
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/3145#discussion_r338649335

---

From: MikkelFJ <[email-masked]>
Date: Thu, 24 Oct 2019 08:53:07 -0700

Do we need a concept of handshake fully confirmed server side once HSD has been ACK'ed? For example to say that path migration cannot start before handshake is really complete and likewise key updates.

-- 
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/3145#issuecomment-545983334

---

From: Marten Seemann <[email-masked]>
Date: Thu, 24 Oct 2019 16:29:46 -0700

https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#rfc.section.4 says
> All other frame types MUST only be sent in the 0-RTT and 1-RTT levels.

And since the frame can't be sent by the client, this means that the frame can only be sent in 1-RTT packets.

-- 
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/3145#discussion_r338833327

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 24 Oct 2019 18:25:21 -0700

> @@ -760,14 +756,9 @@ and ignoring any outstanding Initial packets.

+({{handshake-confirmed}}).  The server MUST send a HANDSHAKE_DONE frame within
+one round-trip time of handshake completion.

I think "within one round-trip time" is too long. As this happens before both endpoints have good estimation of RTT, it could well be the case that the server's estimated RTT be much greater than the PTO of the client. In such case, it would seem to the client as if the CF had been lost.

I think we should say "SHOULD immediately send", with possibly acknowledging the fact that the server "can bundle the HANDSHAKE_DONE frame with 0.5 RTT data."

-- 
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/3145#pullrequestreview-306942372

---

From: ianswett <[email-masked]>
Date: Thu, 24 Oct 2019 18:49:07 -0700

ianswett commented on this pull request.

Some comments, one to add a backstop in case the server fails to send this in a timely manner.

 

Suggestion: or when an acknowledgement of a 1-RTT packet is received.

I think this provides a stopgap against servers that make stupid or malicious errors.

Also, why aren't you explicitly specifying when the server thinks the handshake is confirmed?

 

I'd vote for SHOULD, because I tend to think dropping them immediately is the best option, but I'm not convinced anything terrible happens if a peer delays dropping them a bit.

 

I tend to agree with @kazuho point.  How about "The server MUST send HANDSHAKE_DONE with the first outgoing 1-RTT packet or within one round-trip time of handshake completion if no 1-RTT packets are sent."

@kazuho If the server is sending HANDSHAKE_DONE, isn't it no longer 0.5RTT data?

-- 
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/3145#pullrequestreview-306928277

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Oct 2019 19:37:22 -0700

> @martinthomson I don't understand your comment? What's the difference between dropping Initial keys and not processing them any more?

I was merely pointing out that the Initial keys transition is different in that continuing to handle Initial packets leaves endpoints exposed to attack longer than is ideal.  An attacker with access to Handshake keys most likely can break the remainder of the connection.

(This isn't completely true, because an attacker might only gain leaf keys and not the secrets from the core of the TLS key schedule, but the point was that access to Handshake keys signifies a much more significant breach.)

-- 
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/3145#discussion_r338864598

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Oct 2019 19:39:17 -0700

I don't think that we should add an "OR" here.  If the server acts badly, then the handshake won't ever be confirmed and that's OK.

-- 
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/3145#discussion_r338864889

---

From: ianswett <[email-masked]>
Date: Thu, 24 Oct 2019 19:53:05 -0700

If we're going to add a new signal, I'd like to enforce that.  And if the rule is that the server must send HANDSHAKE_DONE in a short period of time, then it's reasonable for the client to assume any ACK in 1-RTT prior to receiving the HANDSHAKE_DONE frame is a result of the packet containing HANDSHAKE_DONE being lost.

I don't see a downside of this addition, given it's quite simple.

-- 
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/3145#discussion_r338867201

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 24 Oct 2019 21:29:42 -0700

RyanAtGoogle commented on this pull request.

 

Overall, I quite like this HANDSHAKE_DONE proposal. It seems obviously correct which, given our previous iterations is rather appealing :)

I agree with Ian that allowing the client to drop handshake keys when it receives an ACK of a 1-RTT packet sounds like a great optimization which helps ensure the keys get dropped quickly.

-- 
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/3145#discussion_r338882222

---

From: David Schinazi <[email-masked]>
Date: Thu, 24 Oct 2019 21:47:53 -0700

I like the simplicity of this proposal. The main downside I see is that it's possible for a server to never send HANDSHAKE_DONE. We could solve that however, by saying:
- the server MUST send HANDSHAKE_DONE in all its 1-RTT packets once its handshake is complete and until one of them is ACKed
- if the client receives an ACK for a 1-RTT packet it sent and has not seen HANDSHAKE_DONE, it MUST close the connection with a PROTOCOL_VIOLATION

-- 
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/3145#issuecomment-546198996

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Oct 2019 22:25:24 -0700

I don't think that we need clients to be policing server behaviour.  Especially if it requires creating abnormal sending policies for frames.

-- 
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/3145#issuecomment-546205911

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 24 Oct 2019 22:59:31 -0700

I tend to agree with @martinthomson here. I do not think we should make the protocol complex just for enforcing the correct behavior.

Regarding clients using the receipt of an ACK for a 1-RTT packet as the alternative signal, I agree that that'd work, but I am not sure if we need to write it down. Writing it down (or mandating it) gives less incentive for the server to send HANDSHAKE_DONE.

-- 
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/3145#issuecomment-546213435

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 24 Oct 2019 23:16:06 -0700

PS. The approach proposed in this PR has the following two properties:
* sending one-way signal from to the client, when the server reaches handshake complete
* use a frame as the conveyor of the signal

It's good to see emerging consensus, but it seems to me that some  are concerned about the second point. Specifically, I see suggestions to use a continuous signal (https://github.com/quicwg/base-drafts/pull/3145#issuecomment-546198996), or an ACK as a signal too (see https://github.com/quicwg/base-drafts/pull/3145#discussion_r338882222).

**If** we are in fact unhappy with using a frame, then I might suggest using Key Update as the conveyor of the one-way signal. We can require the server to initiate a Key Update when the handshake is complete and to repeatedly send PINGs until it receives an ACK for one of them.

That'd give us an continuous signal, and also removes the need for an alternative signal. And also the need to have a different frame.

-- 
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/3145#issuecomment-546217403

---

From: MikkelFJ <[email-masked]>
Date: Thu, 24 Oct 2019 23:23:08 -0700

@DavidSchinazi I think that 1-RTT packets could be sent from the server before the handshake is confirmed in which case the HSD frame cannot be sent. Or if that is not the case, then any 1-RTT packet could be used as a HSD signal and we wouldn't need the frame.

But , I think it is a good idea to keep sending HSD frames in every packet until done because if the HDS frame is lost, there could be unnecessary delays.

As to client policing, that wouldn't work due to the above because of loss and reordering.

-- 
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/3145#issuecomment-546219071

---

From: MikkelFJ <[email-masked]>
Date: Thu, 24 Oct 2019 23:26:13 -0700

While I am not too keen on @kazuho's key update because it conflates issues, it is the one benefit that it uses a header bit for a continous signal.

-- 
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/3145#issuecomment-546219803

---

From: ianswett <[email-masked]>
Date: Fri, 25 Oct 2019 07:05:42 -0700

> It's good to see emerging consensus (on the first point), but it seems to me that some are concerned about the second point. Specifically, I see suggestions to use a continuous signal ([#3145 (comment)](https://github.com/quicwg/base-drafts/pull/3145#issuecomment-546198996)), or an ACK as a signal too (see [#3145 (comment)](https://github.com/quicwg/base-drafts/pull/3145#discussion_r338882222)).
> 

I also had this thought, but flipping the key update bit doesn't force something to be sent until it's acknowledged, which this frame does.  We could do both if we thought it was very important for every packet to have the signal, but I'm not convinced it's worthwhile.

-- 
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/3145#issuecomment-546368334

---

From: David Schinazi <[email-masked]>
Date: Fri, 25 Oct 2019 11:33:15 -0700

The part I care about here is that we disallow some protocol features (such as migration) until the handshake is confirmed. So I want to make sure the server cannot prevent the client from confirming the handshake. If we explicitly write that the client receiving an ACK for a 1-RTT packet can treat that like receipt of HANDSHAKE_DONE, then I'm fine with this.

-- 
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/3145#issuecomment-546463921

---

From: martinduke <[email-masked]>
Date: Fri, 25 Oct 2019 13:24:18 -0700

martinduke commented on this pull request.

 

I guess the only danger is that putting in this backstop makes it semi-OK for servers to not bother to send HANDSHAKE_DONE as an optimization, and then all the client data goes in 0RTT packets and we end up in the deadlock.

I would rather noncompliance result in holding keys, rather than good connections timing out.

-- 
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/3145#discussion_r339225360

---

From: martinduke <[email-masked]>
Date: Fri, 25 Oct 2019 13:25:36 -0700

I agree with @ianswett. The handshake isn't complete when we have 0.5RTT data. In fact, if the frame goes out then, we can easily have the client discard the handshake keys before getting ACK of its finished.

-- 
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/3145#discussion_r339225776

---

From: martinduke <[email-masked]>
Date: Fri, 25 Oct 2019 13:26:27 -0700

martinduke approved this pull request.

-- 
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/3145#pullrequestreview-307435259

---

From: ianswett <[email-masked]>
Date: Fri, 25 Oct 2019 13:30:09 -0700

The server could also not send anything in Handshake and force the client to continue using 0RTT packets, which seems equivalent to what you're describing?  If so, then this is nothing new.

Maybe we need more motivating text about why you really need to send HANDSHAKE_DONE, but I think this design is generally quite efficient.

If we REALLY want to ensure the client gets the signal, we can add a key phase flip between 0.5RTT and 1RTT as well, but then do we change keys as well?

-- 
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/3145#discussion_r339227362

---

From: martinduke <[email-masked]>
Date: Fri, 25 Oct 2019 13:39:12 -0700

@ianswett That's definitely not what I was talking about. But I see now that my example is not right.

-- 
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/3145#discussion_r339230308

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 26 Oct 2019 01:42:36 -0700

@ianswett 
> If the server is sending HANDSHAKE_DONE, isn't it no longer 0.5RTT data?

Yes. This is 1 RTT, *not* 0.5 RTT.

Regarding when HANDSHAKE_DONE should be sent, my view is that it HANDSHAKE_DONE is essentially an ACK for the Handshake packet. Based on that view, I do not see a reason why it should be sent at a different timing than other acks for Handshake packets (i.e. send immediately, though an endpoint might wait for a short amount of time to bundle ACK with some other data).

In practice, there is no reason to delay the emission of HANDSHAKE_DONE as much as 1 RTT in HTTP/3. The server should be sending HANDSHAKE_DONE at an early moment for letting the client know that the handshake is done before the client retransmits CF, doing so has a higher probability of having CWND increased at an earlier point. 

-- 
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/3145#discussion_r339292488