[secdir] Secdir last call review of draft-ietf-quic-recovery-32

Derrell Piper via Datatracker <noreply@ietf.org> Mon, 02 November 2020 20:20 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E023A11EA; Mon, 2 Nov 2020 12:20:28 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Derrell Piper via Datatracker <noreply@ietf.org>
To: <secdir@ietf.org>
Cc: last-call@ietf.org, draft-ietf-quic-recovery.all@ietf.org, quic@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.21.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <160434842876.26069.16673628080135964837@ietfa.amsl.com>
Reply-To: Derrell Piper <ddp@electric-loft.org>
Date: Mon, 02 Nov 2020 12:20:28 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/RqyG2o24GbkCTXx09optaCq3Lyk>
Subject: [secdir] Secdir last call review of draft-ietf-quic-recovery-32
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Nov 2020 20:20:29 -0000

Reviewer: Derrell Piper
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.

The summary of the review is: Ready, with an optional nit.

This document is QUIC's Loss Detection and Congestion Control and is part of
QUIC Last Call.

Pp. 7, "after the epoch starts is acknowledged" should maybe be singular,
unless the intent is literal and I'm missing what a "starts" is.

There's no explicit security going on here, other than in the larger picture
of QUIC itself, namely that in QUIC-TLS and QUIC-TRANSPORT; this is only its
congestion control.  However, Security Considerations correctly highlights
some of the major traffic analysis concerns with QUIC and congestion control
in general, and there are some, but these are not unique to QUIC, nor would
they likely be addressed inside of congestion control, so this is okay.  It
seems well written and based on a practical understanding of existing TCP
congestion control along with current academic research on this topic.