Re: KEYS_READY

[Kazuho Oku <[e-mail]>]

Hi, Martin

Thank you for writing the PR. My comments inline.

2019年2月13日(水) 10:46 Martin Thomson <[e-mail]>:
>
> https://github.com/quicwg/base-drafts/pull/2237 has been updated to include the discussed new frame.
>
> This allows us to remove the implicit-ish acknowledgment of Initial packets, fix the problem Marten identified with discarding Handshake keys, and the problem Kazuho found with multiple and simultaneous key updates.
>
> There were two designs that were valid here, and I want to ensure that people think about the choice:
>
> The one I chose to write up uses a design like ACK.  The keys used to protect the packet determine how the frame is interpreted.  That is, KEYS_READY in a packet implies that the corresponding keys are in use.  The cost here is that you have to purge any potential retransmissions of KEYS_READY when you update keys or you risk creating a false signal.
>
> The alternative involves more explicit signaling, and requires us to label each set of keys unambiguously.

My weak preference goes to burning a bit in the first byte (we have
reserved bits in all the necessary packet types) due to the
exceptional retransmission rule that we would have for the frame, but
I'm not sure how much I care.

> For that we could borrow the DTLS epoch convention, though that is inconveniently out of phase with the Key Phase we use; not a major issue, but a little hard to reason about.  This doesn't have a retransmission problem, but in addition to the need to document the counting system, we would need to decide whether a mismatch between frame and packet is OK, or something that can produce a connection error.
>
> Obviously, I have a preference for the former, but if people feel differently, this is a good place to register your reasons.
>
> Editorial concerns should be directed toward the pull request.
>


-- 
Kazuho Oku