QUIC Version 2
draft-ietf-quic-v2-10

# Internet AD comments for draft-ietf-quic-v2-06
CC @ekline

## Nits

### S3.3.2

* Hopefully the RFC Editor can help adjust things to make sure that these
  key strings don't get line-split on internal whitespace, vis.:

  "quic
  hp"

  versus "quic hp"

Thank you to Kyle Rose for the SECDIR review.

** Section 3.3.2.  In the spirit of this document being an example of the “the minimum set of changes necessary to specify a new QUIC version”, is the naming convention of the HKDF labels here what should be used in the future?  Specifically “quicv {version number} key”, “quicv{version number} iv”, etc.

** Section 5.
(a) Clients SHOULD NOT use
   a session ticket or token from a QUIC version 1 connection to
   initiate a QUIC version 2 connection, or vice versa.

(b) Servers MUST validate the originating version of any session ticket
   or token and not accept one issued from a different version.

My reading of this text is that (a) is specifying the client behavior and (b) is the server behavior.  (a) appears to be more flexible and allowing for the possibility of mixing version numbers between session tickets (i.e. it says SHOULD NOT, not MUST NOT), but (b) is then instructed to reject this flexibility. Why doesn’t (a) just say MUST NOT?

** Section 6.

   Clients interested in combating firewall ossification  can initiate a
   connection using version 2 if they are either reasonably certain the
   server supports it, or are willing to suffer a round-trip penalty if
   they are incorrect.  

Consider s/firewall/middle-box/ to generalize the applicability.

** Section 8.  Observing support for different version of QUIC, especially in early days of deployment, could be another data point in fingerprinting end-point devices.

Quoting Rob Wilton:
"Thank you.  Another well written, easy to read, draft from the QUIC WG." - Thank you for this, and also thanks to Bo Wu for the OpsDir review.

I'd note that the start of the Abstract ("This document specifies QUIC version 2, which is identical to QUIC version 1 except for some trivial details.") made me schnort, and got me some odd looks from seat-mate on a plane...


A few (very much non-blocking) comments:
Section 3.  Differences with QUIC Version 1
"QUIC version 2 endpoints MUST implement the QUIC version 1 specification as described in [QUIC], [QUIC-TLS], and [QUIC-RECOVERY].  However, the following differences apply in version 2."
This feels like a fragment / truncated paragraph - perhaps there is a better way to word this (like "The remainder of this section lists the differences", or perhaps just changing the final period to a colon would help. 


Section 3.1:
"The Version field of long headers is 0x709a50c4." and "initial_salt = 0xa707.... ", "secret = 0x3425c20cf..."  -- it seems like it would be friendly to the reader to point at how this was derived (otherwise someone is going to assume something like that there have already been 1889161411 prior versions :-)). "It's to prevent ossification / grease" describes *why*, but not *how*.
I'd thought I'd seen some useful text in some other draft/document that could be stolen, but perhaps it was just in a presentation... Especially when there are things like salts and magic security parameters, providing some sort of explanation helps avoid the "that was chosen by TLA to make <insert hand-wavy attack> easier" conspiracy...

# Éric Vyncke, INT AD, comments for draft-ietf-quic-v2-06
CC @evyncke

Thank you for the work put into this document. 

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Matt Joras for the shepherd's detailed write-up including the WG consensus *even* if the justification of the intended status is rather weak.

Please note that Vladimír Čunát is the DNS directorate reviewer (at the chairs' request) and you may want to consider his review as well:
https://datatracker.ietf.org/doc/review-ietf-quic-v2-05-dnsdir-lc-cunat-2022-10-12/

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### Section 3.1

Just curious: why not used 0x0000002 as the version number... For curious readers (including some ADs), some explanations will be welcome.

### Section 6

While I still wonder about the justification of this document (i.e., is it based on some measurements of some middleboxes ?), I dislike ossification, hence supporting this document.

*BUT*, if an ossified firewall forces the negotiation to use version 1, then how would this ossification be known outside of the client ? Will there be a back channel from the client to do some instrumentation ?

### Section 9

RFC 8126 section 3.1 recommends to specify the URL of the modified registry, i.e., https://www.iana.org/assignments/quic/quic.xhtml#quic-versions .

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. 

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

From §4:

   For example, an origin advertising support for "h3" in Alt-Svc 
   SHOULD support QUIC version 1 as it was the original QUIC version 
   used by HTTP/3 and therefore some clients will only support that 
   version.


If an example, normative language shouldn't be used.  s/SHOULD/should

Reviewed - no issues that I saw - thanks for the document!

# GEN AD review of draft-ietf-quic-v2-06

CC @larseggert

Thanks to Joel Halpern for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/FongVrUNe4XJy0AYoz8ptcl2ZVs).

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Grammar/style

#### Section 1, paragraph 2
```
ey derivation and packet formats. Finally [QUIC-VN] provides two mechanisms
                                  ^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Finally".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

Hi,

Thank you.  Another well written, easy to read, draft from the QUIC WG.

Minor level comments:                                                                                                                                                                                                                                                                                                                                                                        
                                                                                                                                                                                                                                                                                                                                                                                             
(1) p 2, sec 1.  Introduction                                                                                                                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                                                                                                                                             
   QUIC version 2 is meant to mitigate ossification concerns and
   exercise the version negotiation mechanisms.  The changes provide an
   example of the minimum set of changes necessary to specify a new QUIC
   version.

As a minor comment, I would suggest adding some text to the first sentence to cite that choosing a value other than 2 for the version number, and changing the type field assignment of the long header packet format, are examples of mitigating ossification concerns.  Specifically, I presume it isn't the case that all new QUIC versions need to renumber the type fields or choose a fixed random number for the version number?  I.e., strictly speaking I assume that these are not the minimal set of changes for any new QUIC version?

Regards,
Rob

// Thanks to Bo for the OPS DIR review.