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

[Kazuho Oku <[e-mail]>]

> So there is no functional reason not to allow updates as soon as 1-RTT keys are available. I think that we should just loosen this entirely. It might not be a good idea to waste a key phase like that, but it certainly doesn't break anything.

If we are to loosing the requirement, I would prefer also adding the 3 PTO recommendation regarding the transition from 1-RTT key (phase 0) to 1-RTT key (phase 1).

Because there is a concern regarding performance and complexity.

When 0-RTT is used, the client's send key transitions from 0-RTT key -> 1-RTT key (phase 0) -> 1-RTT key (phase 1) -> ...

Implementation-wise, it would be best to recommend every transition between these keys to be no earlier than 3 PTO, because then, the server can have a consistent rule on when it would be creating new key, replacing the old one.

At the moment, we are near to that, by saying that the 1-RTT key cannot be updated until an ACK for an 1-RTT packet is being received. *Just* loosening this rule would require server developers to have different timing on how it drops 0.5-RTT key vs. 1-RTT keys - it would be a complication.

-- 
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-552258309