Re: KEYS_READY

[Kazuho Oku <[e-mail]>]

2019年2月14日(木) 13:30 Jana Iyengar <[e-mail]>:
>
>
>
> On Wed, Feb 13, 2019 at 8:23 PM Kazuho Oku <[e-mail]> wrote:
>>
>> TL;DR I think that the issue with the PR is that it not only tries to
>> address issue but it changes existing mechanism. It might make sense
>> to consider just fixing the issues. Proposal below.
>>
>> I think there are two concerns regarding the PR.
>>
>> The PR changes how Initial keys are retired. Instead of relying on the
>> delivery of Handshake packets, it relies on the delivery of
>> KEYS_ACTIVE frames. However, we do not require KEY_ACTIVE frames to be
>> included in every Handshake packet being sent. There is a risk that
>> Initial keys might not get dropped as early as they are now. The other
>> issue is that an endpoint might never receive a Handshake packet that
>> carries a KEY_ACTIVE frame. This happens packet loss occurs. To
>> accommodate that, the PR states that the delivery of KEY_ACTIVE frame
>> in either a Handshake or a 1-RTT packet signals the disposal of the
>> Initial packet. That's workable, but I think it shows the problem with
>> the approach.
>>
>> KEY_ACTIVE frame does not name the key that is activated. That is
>> causing the strange retransmission rules for the frame. The right
>> approach seems to suggest endpoints to incorporate the frame in every
>> ACK-eliciting packet it sends. This is a logic we have not had so far,
>> and it could be difficult for certain implementations that do not know
>> what it is sending when it starts to build a packet.
>>
>> Considering these two issues, I think it might be worth discussing the
>> following straw-man:
>>
>> * Do not touch how Initial keys are dropped. Use the new frame just to
>> indicate the completion of the handshake and the retirement of the
>> previous generation of 1-RTT keys.
>> * Include the 1-RTT key generation number in the frame, so that
>> ordinary retransmission logic can be used. Note also that the
>> retransmission rule does not need to be aggressive, because we do not
>> use the frame for dropping Initial keys.
>>
>> When the handshake is complete, both endpoints send
>> KEYS_ACTIVE(generation=0). That indicates the peer that the peer can
>> drop the Handshake keys, and also that the endpoint is ready to
>> receive a key update.
>>
>> Completion of key update works exactly the same way. When key update
>> is complete, both endpoints send
>> KEY_ACTIVE(generation=previous_generation), indicating that the peer
>> can drop the 1-RTT keys, and that the endpoint is ready to receive
>> another key update.
>
>
> This is a good simplification, I think.  I'll note that you still cannot update keys again until you've received an ACK for the previous KEYS_ACTIVE.

We can require that, however it might be simpler to state that
receiving a KEY_ACTIVE frame from the peer allows an endpoint to
execute a key update.

>
>>
>> Regarding the validation of the generation number, I think we can call it a MAY.
>
>
> What validation?

In the straw-man, KEY_ACTIVE frame carries the generation number of
the 1-RTT key.

The value can be anything equal to or less than the current generation
number, because the delivery of the frame can be severely delayed
(this is the norm for QUIC frames used to communicate a monotonously
increasing number; e.g., MAX_STREAMS).

However, an endpoint should never receive a KEY_ACTIVE frame
containing a generation number that is greater than the generation it
has ever used. Endpoints might want to police that. That's the
validation I'm referring to.

>
> - jana
>
>>
>> 2019年2月14日(木) 11:33 Martin Thomson <[e-mail]>:
>> >
>> > A few different responses...
>> >
>> > On Wed, Feb 13, 2019, at 23:59, Marten Seemann wrote:
>> > > I agree with Kazuho that using a bit in the first byte seems to capture the
>> > > update logic we're looking for better. There's no need to retransmit any
>> > > information, since the bit is set on every subsequent packet.
>> >
>> > I was OK with that PR, and while we might go back and forth on the merits of using a bit vs. a frame, the consensus in Tokyo was that the frame was superior.  Also, this solves more problems.
>> >
>> > On Thu, Feb 14, 2019, at 02:48, Kazuho Oku wrote:
>> > > IIUC key updates are rare, and therefore the frame can be non-ack-
>> > > eliciting. FWIW, the current design does not elicit an ACK in response
>> > > to key update.
>> >
>> > I used the opposite logic.  Key updates are rare and therefore eliciting an acknowledgment does not cost much.  It's one packet per update.  The interesting thing there is that you guarantee that KEYS_ACTIVE frame is sent, so maybe the text about not sending it until you have something to send is not needed.
>> >
>> > On Thu, Feb 14, 2019, at 09:09, Kazuho Oku wrote:
>> > > 2019年2月14日(木) 3:20 Christian Huitema <[e-mail]>:
>> > > > The more I look at it, the more I think that key update / key ready should be treated in much the same way as path challenge / path response.
>> > >
>> > > I am not sure if I like that alternative, primary because it does not
>> > > seem right as a way to drop Initial, 0-RTT, Handshake keys. We are
>> > > trying to address two issues at once; how to drop those keys in lower
>> > > epochs, and how to do key update correctly.
>> >
>> > The test we are looking for is whether a peer can read packets with a particular key.  You can test easily if they can write packets with a key because you receive a packet protected with that key.
>> >
>> > PATH_CHALLENGE/PATH_RESPONSE have baggage, so I don't want to use those.  A new challenge/response could work, but it doesn't offer much over a simple assertion (which is what the proposed frame is).  If the assertion is wrong, then the consequence is a broken connection, so there isn't much incentive to get this wrong.  PATH_CHALLENGE/PATH_RESPONSE contain a field that protects against lying, because there are scenarios in which lying provides advantage (that is, the "DoS this IP please" case).
>> >
>>
>>
>> --
>> Kazuho Oku
>>


-- 
Kazuho Oku