[tcpm] Secdir last call review of draft-ietf-tcpm-rfc793bis-24

[Kyle Rose via Datatracker <[e-mail]>]

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 Almost Ready for publication.

The Security and Privacy Considerations section briefly outlines the
implications of TCP's long legacy, stretching back to the halcyon days of a
friendlier internet. The paragraphs outlining layered security (e.g., IPsec,
TLS) and TCP option-based security (e.g., TCP-AO, tcpcrypt) provide a good
summary of the mechanisms since developed to add security to a protocol that
has otherwise met the challenges of an internet that is many orders of
magnitude larger than it was 40 years ago.

The one item I see missing from this section is a mention of lessons learned
and subsequently applied to the design of QUIC. I think it is worth mentioning,
for instance, that TCP's large surface area of cleartext metadata exposes more
information to the path than required to successfully route packets to their
destination, including to on-path adversaries that may be able to use this
metadata to bolster targeted or pervasive surveillance.

There is one more omission, adjacent to (but not explicitly about) security,
that I think warrants some text in this document: that is around ossification.
Given the lengthy back-and-forth I witnessed as chair of the TCPINC WG
regarding the (in)feasibility of protecting segmentation and header values on
the public internet, it is probably worth adding to a 793bis document a section
that briefly outlines the ossification impact of voluminous cleartext and
unprotected/un-GREASEd metadata, maybe with a reference to the wire image as
defined by RFC 8546. The reason I think this is worthwhile is that it would be
good to have the practical limits of TCP extensibility (i.e., in a world with
middleboxes and other deeply TCP-aware network elements) documented where folks
might look for it when thinking about new options or other new functionality. I
would be happy to help flesh out some text here.