Re: KEYS_READY

[Kazuho Oku <[e-mail]>]

2019年2月15日(金) 9:18 David Schinazi <[e-mail]>:
>
>
>
> On Thu, Feb 14, 2019 at 3:45 PM Martin Thomson <[e-mail]> wrote:
>>
>> On Fri, Feb 15, 2019, at 09:47, David Schinazi wrote:
>> > This means that the server sends KEYS_ACTIVE(1-RTT) not when the 1-RTT
>> > keys are active,
>> > but instead when the handshake finishes, which is when the server has
>> > received the client finished.
>> > Those are two different moments in time.
>>
>> Yes, because the keys aren't active when the server starts sending 1-RTT packets.  They are only active when the server starts reading 1-RTT.  The server can't activate its 1-RTT reading keys until the handshake is complete.
>
>
> Ah, thanks. Looking at it this way it makes sense to me - we may want to make the text clearer in case I'm not the only one who was confused.
>
>>
>> That's why I chose to name this KEYS_ACTIVE(this), not RETIRE_KEYS(prev), but I don't really mind what it is called.
>
>
> I don't feel strongly about names either as long as they make sense - and now KEYS_ACTIVE also makes sense to me - so either name is fine by me.
>
>>
>>  > My proposal is to have the client decide when it is done with the
>> > handshake keys by having the client
>> > delay sending RETIRE_KEYS(Handshake) instead of the server delaying
>> > sending KEYS_ACTIVE(1-RTT).
>>
>> This requires that the client send more Handshake packets.  And it adds a lot of delay because the client has to wait until all its packets are acknowledged.  We previously agreed that any such signal from the server is more direct and effective.
>
>
> I don't think it means more handshake packets. And it's still a direct signal between endpoints. The only difference is that the client-to-server RETIRE_KEYS message is delayed by one RTT compared to its KEYS_ACTIVE message so the server will wait one RTT before throwing away handshake keys. But it has the advantage of not requiring any implicit ACKs. So the tradeoff we're facing is between allowing the server to throw away keys sooner at the cost of making implicit decisions. This implicitness means KEYS_ACTIVE does not allow the client to be able to send anything in Handshake after the ClientFinished. I'm worried that might prevent protocol changes down the road.
>
> I'm still in favor of paying the one RTT before key deletion to make the protocol more explicit.

I share the same view.

Admittedly, it means that then the frame would no longer be useful for
dropping the Initial keys, assuming that we want to drop them ASAP as
we do now.

But even with that downside, I think it makes sense to delay when the
handshake and each generation of 1-RTT keys are dropped. After all, we
can argue that the requirement for when to drop the Initial keys is
exceptional due to security concerns.

Hence something like
https://mailarchive.ietf.org/arch/msg/quic/NNOzxNWldmfiUN9avCdiQMNVXMw.

-- 
Kazuho Oku