Re: [quicwg/base-drafts] Remove handshake confirmed test for KeyUpdate (#3212)

[Martin Thomson <[e-mail]>]

@ekr, I took another look at this and reviewed [the minutes](https://github.com/quicwg/wg-materials/blob/master/ietf106/minutes.md#3212-remove-requirement-for-handshake-to-complete-before-keyupdate).  I think that the outcome is no change.

> An endpoint MUST NOT initiate a key update prior to having confirmed
the handshake (Section 4.1.2). An endpoint MUST NOT initiate a
subsequent key update prior unless it has received an acknowledgment
for a packet that was sent protected with keys from the current key
phase.

The first sentence talks about the first key update.  While we all agree that this is a stricter restriction than absolutely necessary, the definition we agreed for "confirmed" (with `HANDSHAKE_DONE`) is now distinct enough to warrant the special text in that case.  As long as we are OK with that outcome, I don't think that this needs to change (@kazuho certainly argued for some way to hold the first key update back, which I think was derived from not wanting too many keys active at the same time).

If we wanted to allow more aggressive updates, then I would propose the most aggressive option:

> An endpoint MAY initiate the first key update immediately after 1-RTT keys are available.  For the first key update, as a receiver has no difficulty distinguishing between the first two sets of 1-RTT packet protection keys, endpoints can trigger a key update with the first 1-RTT packets they send.

The second sentence uses the word "subsequent" and so applies to all other key updates.  That doesn't need to change.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3212#issuecomment-559304265