Re: KEYS_READY

[David Schinazi <[e-mail]>]

I think RETIRE_KEYS solves both problems. I don't think KEYS_READY does.

On Thu, Feb 14, 2019 at 12:38 PM Mike Bishop <[e-mail]> wrote:

> The question is whether the same mechanism can/should be used for
> post-handshake key updates or if two separate mechanisms are needed.
> They’re very similar problems, but it seems as if the requirements are
> slightly different.
>
>
>
> *From:* QUIC <[e-mail]> *On Behalf Of * Ryan Hamilton
> *Sent:* Thursday, February 14, 2019 12:34 PM
> *To:* David Schinazi <[e-mail]>
> *Cc:* Marten Seemann <[e-mail]>; Jana Iyengar <
> [e-mail]>; Mikkel Fahnøe Jørgensen <[e-mail]>; QUIC
> WG <[e-mail]>; Martin Thomson <[e-mail]>
> *Subject:* Re: KEYS_READY
>
>
>
> 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.
>