Re: KEYS_READY

[Kazuho Oku <[e-mail]>]

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.

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

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