CFIN only recoverable with timeout

[siyengar]

If we're sending CFIN and 1-RTT data in the same flight, and only the CFIN is lost, the client can only use the handshake timeout to recover the FIN and not any threshold based recovery.

We don't allow the server to use the 1-RTT keys until it receives the CFIN. This makes it so that even if the server has received 1-RTT data it cannot ack it which would have triggered threshold loss recovery. So the client has to rely on the handshake timeout to send the data.

Are we fine with saying that the client should have a way more aggressive loss timeout for handshake packets than the server should?

[marten-seemann]

This is a specific property of the TLS 1.3 handshake. I'd be more comfortable to keep our loss recovery independent of the specifics of the crypto handshake.
Don't we have the same problem if the last packet of the server flight containing the certificate is lost?

[siyengar]

I don't think the problem exists with the server specifically because CFIN is dependent on the SFIN, so the client would not send any data without receiving the SFIN. If the SFIN is lost then the client can't even send ACKs. I think finished messages are tails and should be treated as such

[martinthomson]

This is another form of the problem in #1190, or related to an extent that it might not be worth having another issue. See that issue for an idea...

[siyengar]

Ya i filed this as a new issue because when I spoke to @marten-seemann and @janaiyengar about this issue, they were also as surprised by this as I was and it has different design implications to the transport regarding packet number spaces of handshake and 1-rtt data