Implicit ACK and Client Finished

[Christian Huitema <[e-mail]>]

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