[Last-Call] Secdir last call review of draft-ietf-quic-v2-05

Kyle Rose via Datatracker <noreply@ietf.org> Tue, 04 October 2022 15:18 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: last-call@ietf.org
Delivered-To: last-call@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC4FC1524A8; Tue, 4 Oct 2022 08:18:56 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Kyle Rose via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-quic-v2.all@ietf.org, last-call@ietf.org, quic@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.17.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <166489673663.46010.13599556145012423275@ietfa.amsl.com>
Reply-To: Kyle Rose <krose@krose.org>
Date: Tue, 04 Oct 2022 08:18:56 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/NVpdk5NX1GatqNMrJtUjCQgvsUI>
Subject: [Last-Call] Secdir last call review of draft-ietf-quic-v2-05
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Oct 2022 15:18:56 -0000

Reviewer: Kyle Rose
Review result: Ready

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.

This document is Ready.

As the document itself clearly states in the security considerations section,
this revision introduces no changes to the security or privacy properties of
QUIC.

I have only three additional questions/comments:

- What are the implications of the server not encoding the version in its Retry
message and subsequently checking that the client didn't change versions upon
retrying?

- Is there any optimization possible if the server keeps the Initial receive
keys slightly longer than the first instance of processing a packet using keys
generated for the negotiated version? I'm guessing not, but I just wanted to
confirm.

- In "Endpoints have no need to generate the keying material that would allow
them to decrypt or authenticate these packets", I would s/these/such/.