Skip to main content

Last Call Review of draft-ietf-tsvwg-transport-encrypt-19
review-ietf-tsvwg-transport-encrypt-19-secdir-lc-atkins-2021-02-26-00

Request Review of draft-ietf-tsvwg-transport-encrypt
Requested revision No specific revision (document currently at 21)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2021-02-19
Requested 2021-02-05
Authors Gorry Fairhurst , Colin Perkins
I-D last updated 2021-02-26
Completed reviews Secdir Early review of -01 by Christopher A. Wood (diff)
Opsdir Last Call review of -19 by Shwetha Bhandari (diff)
Genart Last Call review of -19 by Joel M. Halpern (diff)
Secdir Last Call review of -19 by Derek Atkins (diff)
Genart Telechat review of -20 by Joel M. Halpern (diff)
Assignment Reviewer Derek Atkins
State Completed
Request Last Call review on draft-ietf-tsvwg-transport-encrypt by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/RRLEDXS2hBWBgHyvue17scdbip0
Reviewed revision 19 (document currently at 21)
Result Has nits
Completed 2021-02-26
review-ietf-tsvwg-transport-encrypt-19-secdir-lc-atkins-2021-02-26-00
Hi,

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.

Summary:

* With Nits

Details:

* 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:

                            For
   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
exfiltrate.

-derek