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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
