Re: KEYS_READY

[Ryan Hamilton <[e-mail]>]

On Thu, Feb 14, 2019 at 9:57 AM David Schinazi <[e-mail]>
wrote:

> I don't think the proposed PR matches what we discussed in Tokyo, and it
> seems less robust than what we discussed.
>
> In Tokyo we had discussed a RETIRE_KEYS frame with the following
> properties:
> 1) You send RETIRE_KEYS when both (a) you have sent everything you wanted
> with those keys AND (b) that has been ACKed
>     In particular, the client sends a 1RTT packet with
> RETIRE_KEYS(Handshake) when the server ACKs the packet containing the
> crypto frame with the ClientFinished
> 2) You can discard keys (and congestion control state if applicable) when
> you've both sent and received RETIRE_KEYS
>
> The proposal in PR#2237 does not have these properties, because it focuses
> on the new keys being ready instead of focusing on when an endpoint is done
> sending with previous keys.
> In order to avoid the client infinitely retransmitting ClientFinished
> issue, PR#2237 has the server delay its 1-RTT KEYS_READY until it believes
> the handshake is complete.
> It would be more robust to have the endpoint who is sending decide when it
> is done sending, instead of having the peer assume it knows.
>

I completely agree with this. The usage of RETIRE_KEYS, as outlined here
and in summaries of the discussion in Tokyo that I read, seems simple and
clear.