Re: KEYS_READY

["Martin Thomson" <[e-mail]>]

Unfortunately, I don't see this as accelerating discussion.  I appreciate having the proposal, but I suspect we're going to need to decide this in Prague.

On Fri, Mar 8, 2019, at 14:29, Kazuho Oku wrote:
> Hoping to accelerate the discussion, I have created yet another PR
> that tries to solve the problem.
> 
> https://github.com/quicwg/base-drafts/pull/2504
> 
> I've tried to take a very conservative approach in the PR, partly
> because I think it's good to do so at a late stage of standardization
> process, and also because it helps us figure out the range of the
> choices we have in addressing the issue.
> 
> The PR, in short, introduces a MAX_KEY_UPDATES frame, that let's
> endpoints communicate the cumulative number of key updates that are
> permitted, just like MAX_STREAMS permit the cumulative number of
> streams that can be opened. It concentrates on dropping the 0-RTT,
> Handshake and previous generations of 1-RTT keys, without touching how
> the Initial keys are dropped.
> 
> Please let me know what you think. Thank you in advance.
> 
> 2019年3月2日(土) 8:50 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
> >> > >
> >>
> 
> 
> -- 
> Kazuho Oku
> 
>