Re: KEYS_READY

[David Schinazi <[e-mail]>]

Thanks Martin and Nick.

I agree that my proposal needs a lot of work to get the wording right, but
I think the difference between that and MT's is when you send the frame:
- MT's model is to send it when you're not expecting to receive anything
anymore
- my model is to send it when you know you won't be sending anymore

I believe letting the sender decide is easier to reason about and will help
down the road, even if it has the downside of keeping the handshake keys
around for an extra RTT on the server.

David

On Thu, Feb 28, 2019 at 10:15 PM Martin Thomson <[e-mail]> wrote:

> I see.  That's not clear.  It might have helped to explain that in the
> email announcing the proposal, because the PR contains errors that are
> quite confusing.  The PR never really defines what "done with keys" means
> either.
>
> If that is the only difference then we can talk about the implications of
> driving state based on ACK frames, which we've not done in the past.
> Leaving the ugly exception for Initial aside, I suspect that this is much
> harder to implement, because you have to track where data was first sent in
> order to send the frame at the right time.  That's easy enough for CRYPTO
> frames, which are basically all you have during the handshake, but in order
> to implement it for key updates you need visibility into which packets are
> still outstanding.  That requires a new type of access to the loss recovery
> module.
>
> I see quite a few omissions and mistakes in the PR.  For instance, this
> doesn't address the concerns about retransmissions of the frame across key
> updates.  It also shows the server sending the frame in Handshake packets
> before it could have received ACKs.  Hence my confusion.
>
> On Fri, Mar 1, 2019, at 16:21, Nick Harper wrote:
> > There is one difference between the RETIRE_KEYS and KEYS_ACTIVE PRs
> > (besides the name of the new frame):
> >
> > With RETIRE_KEYS, the client doesn't send it until the Client Finished
> > has been ACKed. With KEYS_ACTIVE, the client MUST send it in its first
> > 1-RTT packet, while the server MUST NOT process that 1-RTT packet until
> > it has received the Client Finished.
> >
> > Even though they do basically the same thing, I think it's much easier
> > to understand the logic in the RETIRE_KEYS PR. The logic for
> > RETIRE_KEYS is "I send RETIRE_KEYS when I don't need to send or receive
> > anything more at the previous encryption level." After re-reading the
> > KEYS_ACTIVE PR, I don't see a similar underlying principle for when
> > it's sent, just a set of rules to follow.
> >
> > On Thu, Feb 28, 2019 at 7:37 PM Martin Thomson <[e-mail]>
> wrote:
> > > I don't get it. This is the same proposal. With fewer editorial
> changes, perhaps.
> > >
> > >  On Fri, Mar 1, 2019, at 11:30, David Schinazi wrote:
> > >  > Since this conversation has quieted down for two weeks, I went
> ahead
> > >  > and wrote up the RETIRE_KEYS proposal:
> > >  > https://github.com/quicwg/base-drafts/pull/2492
> > >  >
> > >  > I believe this is simpler to reason about than the KEYS_ACTIVE
> proposal
> > >  > and safer as it makes less assumptions about the handshake protocol.
> > >  >
> > >  > Please let me know what you think, and I believe we should keep the
> > >  > discussion here instead of on the PR.
> > >  >
> > >  > David
> > >  >
> > >  > On Thu, Feb 14, 2019 at 5:51 PM Kazuho Oku <[e-mail]>
> wrote:
> > >  > > 2019年2月15日(金) 9:18 David Schinazi <[e-mail]>:
> > >  > > >
> > >  > > >
> > >  > > >
> > >  > > > On Thu, Feb 14, 2019 at 3:45 PM Martin Thomson <mt@lowentropy..net>
> 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
> > >
>
>