Roman Danyliw's No Objection on draft-ietf-quic-v2-06: (with COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Mon, 24 October 2022 13:45 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: quic@ietf.org
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 63883C14F612; Mon, 24 Oct 2022 06:45:43 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-quic-v2@ietf.org, quic-chairs@ietf.org, quic@ietf.org, matt.joras@gmail.com, matt.joras@gmail.com
Subject: Roman Danyliw's No Objection on draft-ietf-quic-v2-06: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 8.18.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <166661914340.46274.2974375903407965912@ietfa.amsl.com>
Date: Mon, 24 Oct 2022 06:45:43 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/yc9554DHV5hERxyrR45IXhF04BQ>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Oct 2022 13:45:43 -0000

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.