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

[Mikkel Fahnøe Jørgensen <[e-mail]>]

I don’t see a need for HANDSHAKE_DONE in both directions although it won’t
hurt.

An argument for symmetric HANDSHAKE_DONE is that it decouples the handshake
transition from the handshake logic which makes it easier to replace TLS
with something simpler, for example in a QUIC version for constrained
devices.

On 30 October 2019 at 16.46.10, Mike Bishop ([e-mail]) wrote:

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 :)