Last Call Review of draft-ietf-tsvwg-transport-encrypt-19

Request Review of draft-ietf-tsvwg-transport-encrypt
Requested rev. no specific revision (document currently at 20)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2021-02-19
Requested 2021-02-05
Authors Gorry Fairhurst, Colin Perkins
Draft last updated 2021-02-26
Completed reviews Secdir Early review of -01 by Christopher Wood (diff)
Opsdir Last Call review of -19 by Shwetha Bhandari (diff)
Genart Last Call review of -19 by Joel Halpern (diff)
Secdir Last Call review of -19 by Derek Atkins (diff)
Genart Telechat review of -20 by Joel Halpern
Assignment Reviewer Derek Atkins 
State Completed
Review review-ietf-tsvwg-transport-encrypt-19-secdir-lc-atkins-2021-02-26
Posted at
Reviewed rev. 19 (document currently at 20)
Review result Has Nits
Review completed: 2021-02-26



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