[tsvwg] Secdir last call review of draft-ietf-tsvwg-transport-encrypt-19

Derek Atkins via Datatracker <noreply@ietf.org> Fri, 26 February 2021 14:41 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: tsvwg@ietf.org
Delivered-To: tsvwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C713C3A03EE; Fri, 26 Feb 2021 06:41:39 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Derek Atkins via Datatracker <noreply@ietf.org>
To: <secdir@ietf.org>
Cc: draft-ietf-tsvwg-transport-encrypt.all@ietf.org, last-call@ietf.org, tsvwg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.26.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <161435049976.8163.13266299314342363126@ietfa.amsl.com>
Reply-To: Derek Atkins <derek@ihtfp.com>
Date: Fri, 26 Feb 2021 06:41:39 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/v6KeLSEH4pQ45nuPvcbmrBth-ec>
Subject: [tsvwg] Secdir last call review of draft-ietf-tsvwg-transport-encrypt-19
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Feb 2021 14:41:40 -0000

Reviewer: Derek Atkins
Review result: Has Nits


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 with the intent of improving
security requirements and considerations in IETF drafts.  Comments
not addressed in last call may be included in AD reviews during the
IESG review.  Document editors and WG chairs should treat these
comments just like any other last call comments.


* With Nits


* Section 2:

                    Unencrypted transport headers provide
   information can support network operations and management

I think this is missing a "that" -- "..provide information that can.."

* Section 3.2:

   example, [I-D.ietf-quic-transport] specifies a way for a QUIC
   endpoint to optionally set the spin-bit to reflect to explicitly
   reveal the RTT of an encrypted transport session to the on-path

I think "to reflect to explicitly reveal" is incorrect; it should be
either "to reflect" or "to explicitly reveal"...  Or add a
conjunction: "to reflect AND to explicitly reveal" (emphasis mine).

* In section 4, Greasing:

      A protocol can intentionally vary the value, format, and/or
      presence of observable transport header fields [RFC8701].  This

This suggestion has a negative security impact in that it could leave
room for a hidden communication channel.  A bad actor could
intentionally vary those bits by inserting data they wish to