Subject: Re: KEYS_READY

From: David Schinazi <[email-masked]>
Date: Fri, 1 Mar 2019 15:49:22 -0800

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 <[email-masked]> 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 <[email-masked]>
> 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 <[email-masked]>
> wrote:
> > >  > > 2019年2月15日(金) 9:18 David Schinazi <[email-masked]>:
> > >  > > >
> > >  > > >
> > >  > > >
> > >  > > > 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
> > >
>
>

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 8 Mar 2019 12:29:32 +0900

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 <[email-masked]>:
>
> 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
> 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
>
>> 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 Thu, Feb 28, 2019 at 7:37 PM Martin Thomson <[email-masked]> wrote:
>> > > I don't get it. This is the same proposal. With fewer editorial changes, perhaps.
>> > >
>> > >  > Since this conversation has quieted down for two weeks, I went ahead
>> > >  > I believe this is simpler to reason about than the KEYS_ACTIVE proposal
>> > >  > On Thu, Feb 14, 2019 at 5:51 PM Kazuho Oku <[email-masked]> wrote:
>> > >  > > > On Thu, Feb 14, 2019 at 3:45 PM Martin Thomson <mt@lowentropy..net> 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
>> > >  > > >> 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
>> > >  > > >> > delay sending RETIRE_KEYS(Handshake) instead of the server delaying
>> > >  > > >> 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

-- 
Kazuho Oku

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 07 Mar 2019 22:38:44 -0500

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:
> 2019年3月2日(土) 8:50 David Schinazi <[email-masked]>:
> >
> > Thanks Martin and Nick.
> >
> >> 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..
> >>
> >> > >  > > > On Thu, Feb 14, 2019 at 3:45 PM Martin Thomson <mt@lowentropy...net> wrote:
> >> > >  > > >>

---

From: David Schinazi <[email-masked]>
Date: Fri, 8 Mar 2019 13:29:13 -0800

Thanks for writing this up, Kazuho.
I'm getting a sense that we have a growing set of similar solutions to
multiple problems that we need to disentangle to make sure we all
understand the pros and cons.
I think it might be worth it to discuss this in person in Prague, either in
the WG or in a side meeting.

David

On Thu, Mar 7, 2019 at 7:38 PM Martin Thomson <[email-masked]> wrote:

> 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.
>
> > > 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:
> > > 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
> > >
> > >> 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
> 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.
> > >>
> > >> > >  > > 2019年2月15日(金) 9:18 David Schinazi <[email-masked]
> >:
> > >> > >  > > >
> > >> > >  > > >
> > >> > >  > > >
> > >> > >  > > >> 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.
> > >> > >  > > >
> > >> > >  > > >>
> > >> > >  > > > 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.
> > >> > >  > > >
> > >> > >  > > >>
> > >> > >  > > >> 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
> > >> > >  > > > I'm still in favor of paying the one RTT before key
> deletion to make the protocol more explicit.
> > >> > >  > >
> > >> > >  > > I share the same view.
> > >> > >  > >