Re: KEYS_READY

[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).