`picoquic_state_server_false_start` handling

[rsepassi]

I'm trying to understand the behavior of picoquic_state_server_false_start. The short of my question is: what does this state signify and how does it differ from picoquic_state_server_almost_ready?

I came across its handling in picoquic_prepare_segment, and one oddity is the comment at the end of its handling block - Else, just fall through to almost ready behavior. - which is followed by case picoquic_state_client_ready_start: where I would have expected case picoquic_state_server_almost_ready:. Maybe an artifact of a code move, or more likely due to my own misunderstanding. Flagging just in case.

RFC 9001 section 4.1.1. Handshake Complete reads: "This happens when the TLS stack has both sent a Finished message and verified the peer's Finished message." A server isn't fully done until a client has sent something back after the handshake response. This lines up with Noise as well.

In the picoquic code, if client authentication is enabled, it seems to wait for the client Finished message by transitioning into picoquic_state_server_false_start here, but otherwise transitions into picoquic_state_server_almost_ready; how do these relate to waiting for the Finished message? The comment next to picoquic_state_server_false_start makes me think that it is the one that waits for a Finished message, but it's only triggered if client authentication is turned on, so I think I'm misunderstanding something.

In the case where it transitions into picoquic_state_server_false_start, what's the sequence of events that leads it to transition to picoquic_state_server_almost_ready here?

Thanks for helping me understand the code better.

[huitema]

"False Start" is another name of "0.5RTT". The server has done it's share of the Diffie Hellman exchange, but cannot tell whether the connection is e2e or MITM. The connection will only be verified when the client checks the server keys and certs and sends back a final message.

So basically:

Client	Server
Initial state: send client hello
	initial state: receive client hello
	initial state: send server hello
	handshake state: send first flight
	false start: may start sending 1RTT
initial state: receive server hello
handshake state: discard initial key
handshake state: receive server flight
handshake state: validate cert
almost ready: send-receive 1RTT
almost ready: send client final (as handshake packet)
	false start: receives client final (as handshake packet)
	false start: validates final
	ready: send "handshake done" in 1 RTT
	discard initial and handshake key
almost ready: receive handshake done
ready: after that. Discard "handshake" and "0RTT" keys