Subject: [quicwg/base-drafts] Is it OK to send a server cleartext packet after the client has sent a finished message? (#829)

From: Christian Huitema <[email-masked]>
Date: Tue, 03 Oct 2017 16:14:41 -0700

Interesting question. Picoquic and Quickly have an interop issue because Quickly acks the client finished message (client clear text) in a server clear text packet carrying an ACK. Picoquic ignores the server clear text packet because it has already sent the client finished and has moved to encrypted operation. Who is 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/issues/829

---

From: janaiyengar <[email-masked]>
Date: Wed, 04 Oct 2017 16:50:20 +0000 (UTC)

Why did the server (Quicly) not move to 1-RTT and send the server ack in a 1-RTT packet? That's what I would have expected.

-- 
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/issues/829#issuecomment-334219140

---

From: ekr <[email-masked]>
Date: Wed, 04 Oct 2017 17:00:23 +0000 (UTC)

What's the text that leads you to believe that it should do that.

On Wed, Oct 4, 2017 at 9:50 AM, janaiyengar <[email-masked]>
wrote:

> Why did the server (Quicly) not move to 1-RTT and send the server ack in a
> 1-RTT packet? That's what I would have expected.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/829#issuecomment-334219140>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABD1oc2nrZPjsDKnrLCUZH09WgLFJMRdks5so7dLgaJpZM4Ps5pV>
> .
>

-- 
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/issues/829#issuecomment-334221893

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 04 Oct 2017 17:06:48 +0000 (UTC)

@janaiyengar 
> Why did the server (Quicly) not move to 1-RTT and send the server ack in a 1-RTT packet? That's what I would have expected.

ACK for the cleartext packet that carried ClientFinished was sent in a cleartext packet that carried ServerFinished.

-- 
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/issues/829#issuecomment-334223695

---

From: ekr <[email-masked]>
Date: Wed, 04 Oct 2017 10:16:47 -0700

FWIW, this is what I do as well.

On Wed, Oct 4, 2017 at 10:06 AM, Kazuho Oku <[email-masked]>
wrote:

> @janaiyengar <https://github.com/janaiyengar>
>
> ACK for the cleartext packet that carried ClientFinished was sent in a
> cleartext packet that carried ServerFinished.
>
> —
> You are receiving this because you commented.
> <https://github.com/quicwg/base-drafts/issues/829#issuecomment-334223695>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABD1oaqrTZ-eWMafndszw2kuhm8IDHJ7ks5so7sigaJpZM4Ps5pV>
> .
>

-- 
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/issues/829#issuecomment-334226347

---

From: Christian Huitema <[email-masked]>
Date: Wed, 04 Oct 2017 11:01:55 -0700

I am concerned that this creates a big special case. If I have to accept a clear text ACK for the Finished message, I need to keep track of the packet numbers that can be ACKed with that message -- ACKing 1RTT data would be wrong. That's a very big wart in the code.

-- 
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/issues/829#issuecomment-334240106

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 05 Oct 2017 13:27:35 -0700

@huitema 
> I am concerned that this creates a big special case. If I have to accept a clear text ACK for the Finished message, I need to keep track of the packet numbers that can be ACKed with that message --…

We cannot use the timing at which we finish TLS handshake as a moment to switch from ACK over cleartext to ACK over protected packets, considering the fact that 0-RTT packets need to be ACKed using protected packets, and that 0-RTT packets and cleartext packets can be sent in mixed order.

-- 
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/issues/829#issuecomment-334582398

---

From: Christian Huitema <[email-masked]>
Date: Fri, 06 Oct 2017 16:04:11 +0000 (UTC)

> ACK for the cleartext packet that carried ClientFinished was sent in a cleartext packet that carried 

That's not what I see in the logs. I see:

  -> Client initial (carries client hello)
  <- Server Clear Text (several message carry server flight, including server finished. Message embed 
       ACK of Client Initial
  -> Client clear text: carries client finished, and ACK of server clear text messages
  <- Server Clear Text: only carries an ACK Frame for the client clear text.

When the server sends the last server clear text message, it has already received the client clear text, since it acknowledges it. According to Ian's presentation of "ACK rules", ACKing a message means that the message was not just received but also processed -- which logically means processing the TLS state machine. I don't see what advantage there is to sending that last acknowledgement in clear 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/issues/829#issuecomment-334798431