Subject: Implicit ACK and Client Finished

From: Christian Huitema <[email-masked]>
Date: Tue, 5 Jun 2018 23:39:47 -0700

During the QUIC interop yesterday, there was a discussion of the
proposed implicit ACK of the "client finished" message, during the
transition from handshake to 1rtt protection. The sequence that we
envisage goes like that:

<--- Server sends last message in server flight (server finished),
protected with Handshake key, sequence number A

<--- Server sends first 1-RTT protected message (really, 0.5RTT),
protected with 1 RTT key, sequence number B

---> Client sends last message in client second flight (client
finished), protected with Handshake Key, sequence number C

---> Client sends 1-RTT protected message, carrying ACK(C), sequence
number D

<---Server sends 1-RTT protected message, carrying ACK(D), sequence
number E.

---> Client sends ACK(E) in 1RTT protected packet.

The implicit ACK proposal would state the following:

1) When the server receives ACK(B), the ack of its first 1RTT message,
it knows that the whole server first flight had been received.

2) When the client receives ACK(D), the ack of its first 1RTT message,
it knows that the whole client flight has been received, and that the
server will not send any more "handshake" packet.

3) When the server receives ACK(E), it knows that the client knows that
all handshake packets have been received, and the clientwill not send
any more handshake packets.

I believe that the 1st assertion is correct, because if the server
flight up to server finished was not properly received, the client would
not have been able to validate the session, compute the 1RTT key, and
receive a packet encrypted.with 1RTT key. But I believe that the 2nd and
possibly the 3rd assumptions are not correct.

The problem with the second assumption is that the server does not
really need to receive the TLS client finished message before
acknowledging 1RTT protected packets. Even if we wrote in the spec that
the server MUST wait for the final validation of the TLS handshake
before acking any 1RTT protected packet, since there is no actual
mechanism to enforce that, we know it will be one of those "MUST (BUT WE
KNOW YOU WILL NOT)" recommendations.

Personally, I would rather see some kind of explicit acknowledgement of
the client finished message. But we need an open discussion.

-- Christian Huitema

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 6 Jun 2018 02:50:55 -0400

Haven’t read/understood all, but to avoid confusion did you mean ACK(B)
here?

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 6 Jun 2018 03:01:40 -0400

I had the same thought while reading through the assertions, before
arriving at your concerns.

This question also needs some motivation for the implicit ACK - what is
gained by doing so?
I guess it could avoid a packet when one part has nothing else to send, but
I’d like to see that detailed.

I also prefer an explicit client finished signal. Especially because
implicit ACK’s ties the handshake close to TLS and especially with the new
stream 0 proposal TLS is fairly decoupled, opening for protocol variants
with other handshakes (e.g. IoT devices).

Thus, even if it could be assumed that the assertion 2 and 3 holds, they
might not hold in other variants, so there should be a good reason to rely
on them.

On 6 June 2018 at 08.40.29, Christian Huitema ([email-masked]) wrote:

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Wed, 6 Jun 2018 00:15:52 -0700

Yes. Sorry.

On 6/5/2018 11:50 PM, Mikkel Fahnøe Jørgensen wrote:
> Haven’t read/understood all, but to avoid confusion did you mean
> ACK(B) here?
>