Re: KEYS_READY

[Kazuho Oku <[e-mail]>]

2019年2月14日(木) 3:20 Christian Huitema <[e-mail]>:
>
>
>
> On Feb 13, 2019, at 5:55 AM, Mikkel Fahnøe Jørgensen <[e-mail]> wrote:
>
> The point is that under the rules set by the PR, it is not possible to update keys before a KEYS_ACTIVE / KEYS_READY frame has been received. If such a frame is sent, but lost, there is not path to update keys again. This goes wrong after a (long) while, when the current key is exchausted.
> It does not matter that updates are rare.
>
>
> The more I look at it, the more I think that key update / key ready should be treated in much the same way as path challenge / path response.

I am not sure if I like that alternative, primary because it does not
seem right as a way to drop Initial, 0-RTT, Handshake keys. We are
trying to address two issues at once; how to drop those keys in lower
epochs, and how to do key update correctly.

The proposed approach of using a frame (or a header bit) to let each
side unilaterally declare that it's done with the keys gives us a
consistent pattern for switching between the keys.

> Something like: I just updated my key, can you receive it (challenge); yes, you can see I am using your new key (response). This resolves the debate with ack-or-not (not), and also whether the mechanism can be used to delay update ad infinitum (cannot).
>
> If we use the existing path challenge mechanism, we need to add a restriction that responses must be sent in the same epoch. Or we can invent a new one.
>
> -- Christian Huitema



-- 
Kazuho Oku