Re: KEYS_READY

[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.