Skip to main content

Last Call Review of draft-ietf-quic-v2-05

Request Review of draft-ietf-quic-v2
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2022-10-11
Requested 2022-09-27
Authors Martin Duke
I-D last updated 2022-10-04
Completed reviews Genart Last Call review of -05 by Joel M. Halpern (diff)
Secdir Last Call review of -05 by Kyle Rose (diff)
Artart Last Call review of -05 by James Gruessing (diff)
Opsdir Last Call review of -05 by Bo Wu (diff)
Dnsdir Last Call review of -05 by Vladimír Čunát (diff)
Assignment Reviewer Kyle Rose
State Completed
Request Last Call review on draft-ietf-quic-v2 by Security Area Directorate Assigned
Posted at
Reviewed revision 05 (document currently at 10)
Result Ready
Completed 2022-10-04
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

This document is Ready.

As the document itself clearly states in the security considerations section,
this revision introduces no changes to the security or privacy properties of

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

- 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

- 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/.