Skip to main content

Last Call Review of draft-ietf-quic-version-negotiation-10
review-ietf-quic-version-negotiation-10-secdir-lc-salazar-2022-10-05-00

Request Review of draft-ietf-quic-version-negotiation
Requested revision No specific revision (document currently at 14)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2022-10-11
Requested 2022-09-27
Authors David Schinazi , Eric Rescorla
I-D last updated 2022-10-05
Completed reviews Opsdir Last Call review of -10 by Qin Wu (diff)
Genart Last Call review of -10 by Robert Sparks (diff)
Secdir Last Call review of -10 by Joey Salazar (diff)
Artart Last Call review of -10 by Tim Bray (diff)
Dnsdir Last Call review of -10 by Petr Špaček (diff)
Assignment Reviewer Joey Salazar
State Completed
Request Last Call review on draft-ietf-quic-version-negotiation by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/KQqU--whzf1Elnw-7LQkDgoRnHQ
Reviewed revision 10 (document currently at 14)
Result Has nits
Completed 2022-10-05
review-ietf-quic-version-negotiation-10-secdir-lc-salazar-2022-10-05-00
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.

Document: draft-ietf-quic-version-negotiation-10
Reviewer: Joey Salazar
The summary of the review is: Ready with nits

Major Concerns: None

Minor Concerns: None

Nits:

Section 2.1: "it SHALL select a mutually supported version and sends[…]"
s/sends/send/

Section 2.4: This section states "the connection attempt prior to receiving the
Version Negotiation packet is distinct from the connection with the
incompatible version that follows". According to text in Section 2.1 "it SHALL
select a mutually supported version and sends a new first flight with that
version - this version is now the negotiated version", Section 2.4 could say
"from the connection with the negotiated version that follows" instead.

Section 7: s/Since at the time of writing QUIC version 1/Since, at the time of
writing, QUIC version 1/

Section 8: For clarity of reading, this section could be placed after Section
4. Version Downgrade Prevention

Section 9: The security of the mechanism relying on the security of the weakest
common version seems clear, yet a bit more description on "but more analysis is
still needed here" would be good, perhaps pointing to what other
vulnerabilities could be expected/analyzed, or whether cross-protocol attacks
could still take place.