Roman Danyliw has entered the following ballot position for draft-ietf-quic-v2-06: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-quic-v2/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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.
