RE: Consensus Calls for Transport/TLS issues, post-Cupertino

[Mike Bishop <[e-mail]>]

And this is the piece I'm not getting, I think.

The minimum requirement for the server to know the client got the whole handshake is to receive the Client Finished; receipt of any 1-RTT traffic from the client demonstrates they derived the correct keys.  The server can drop Handshake keys at that point.  However, the server can no longer retransmit the ACK or even know if it was delivered, so the client needs a reliable sync point based on 1-RTT traffic to know that the server received the Client Finished.

Since the server can send 1-RTT packets before the handshake completes, receipt of 1-RTT packets isn't sufficient.  Since the 0-RTT and 1-RTT packets share a space, receiving an ACK in a 1-RTT packet isn't sufficient.  The client knows that the server has seen the whole handshake once it receives an ACK of a 1-RTT packet.  As soon as any packet sent in 1-RTT is ACK'd, the client can drop handshake keys.

As you explain in the other fork, organic traffic isn't sufficient, so we have to force something into 1-RTT to ensure these signals happen.  If the client sends HANDSHAKE_DONE in 1-RTT, probably coalesced with Client Finished, that's an ack-eliciting 1-RTT packet.  The server will ACK it; if the ACK gets lost, the client will PTO its 1-RTT packet and the server will ack *that*, and so on.  Eventually the client gets an ACK of a 1-RTT packet, which is what it needs.  It drops keys.

If the server sends HANDSHAKE_DONE upon receipt of the Finished, that is a more direct signal, and the client can drop keys upon receipt of that frame.  If the ACK of the server's HANDSHAKE_DONE gets lost, the server will PTO it, and the client will ACK, and so on. But those things aren't really necessary -- the client and server have both already gotten their signal.  I can see the appeal of having the server send it, so that we're not driving off of ACKs of particular packets.

The only reason I see for both sides to send it is distaste for implicit acknowledgements, trying to avoid letting the Client Finished be what tells the server that all its Handshake data clearly made it.  Is this just preference for one solution over another, or is there a technical reason I'm missing?

-----Original Message-----
From: QUIC <[e-mail]> On Behalf Of Martin Thomson
Sent: Tuesday, October 29, 2019 7:46 PM
To: [e-mail]
Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino

On Wed, Oct 30, 2019, at 05:26, Mike Bishop wrote:
> Therefore, ACK works iff we *know* that the client sent something 
> ack-eliciting in 1-RTT.

I think that you have to make it symmetric, not just "client sends".  Because we don't have implicit acknowledgement for Handshake packets from the server, the server can enter the same state that the client does in Marten's deadlock scenario.  In other words, both need to send something ack-eliciting.  And it's not just anything at any time, it has to be anything within some bounded time.  The upper bound is probably high, but it is at least before the Handshake packets consume all the available congestion window (which might be a long time, but I haven't worked out how long that could take).

> So one solution is to require clients to send

....and servers :)