Re: [Last-Call] Secdir last call review of draft-ietf-quic-version-negotiation-10

[David Schinazi <[e-mail]>]

Hi Joey, and thanks for your review.

I've pushed a commit that addresses some of your comments. More detailed
responses inline.
https://github.com/quicwg/version-negotiation/commit/3fee2873545dcc2cae20f070b86f844dae6a5558

On Wed, Oct 5, 2022 at 10:26 AM Joey Salazar via Datatracker <
[e-mail]> wrote:

> Reviewer: Joey Salazar
> Review result: Has Nits
>
> 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/
>

Fixed

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

I find the current text clearer.

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

Fixed

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

I find the current placement clearer.

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

If anyone performs this analysis, I'll be happy to include it. But I'd
rather not delay
publication waiting for this analysis.