Hi Kyle,
Thanks for the review! There's a PR with the resulting changes:
replies inline
On Tue, Oct 4, 2022 at 8:18 AM Kyle Rose via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Kyle Rose
Review result: Ready
I have only three additional questions/comments:
- What are the implications of the server not encoding the version in its Retry
message and subsequently checking that the client didn't change versions upon
retrying?
AFAICT there are no security implications here. The spec is restrictive to reduce the
complexity of the code, and gives the server the option of enforcing the rule in order
complexity of the code, and gives the server the option of enforcing the rule in order
to discourage clients from violating it.
- Is there any optimization possible if the server keeps the Initial receive
keys slightly longer than the first instance of processing a packet using keys
generated for the negotiated version? I'm guessing not, but I just wanted to
confirm.
No. It might want to keep around the 0-RTT keys from the original version, but once it
receives the negotiated version there are no outstanding client Initial packets with the
old version.
- In "Endpoints have no need to generate the keying material that would allow
them to decrypt or authenticate these packets", I would s/these/such/.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
