Reviewer: Christopher Wood Review result: Has issues Review of draft-ietf-tsvwg-transport-encrypt-03 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. The summary of my review is: Has issues This document lays out a comprehensive assessment of the impact of transport (header) encryption on network users and operators. Motivation for and dependencies on cleartext transport information is clear. Yet, while this information is all useful, I observe a couple issues with the document in its current state that might be worth addressing. For brevity, I’ve enumerated them below. 1. While the document states that discouraging encryption is not a goal, several sections seem to encourage or otherwise promote various workarounds for transport encryption that seem in conflict with the goal of encryption. For example, in Section 3.1.3, encouraged use of IPv6 Network Flow Labels as a way of marking transport flows seems in conflict with QUIC’s use of rotating connection identifiers (as a means of helping unlinkability). Security and privacy motivated QUIC’s aggressive use of encryption, and it seems that this privacy perspective is not given enough attention. Are any transport protocol implementations setting this information at the network layer? As another example, consider Section 6.1, wherein the document discusses privacy implications of sharing data. It states that protocols which “expose the state information used by the transport protocol in their header information ... provide an incentive for the sending endpoint to provide correct information.” I’m not sure this is accurate given the outcome of the QUIC Privacy Design Team and follow up work from the spin bit folks. Recall that one aspect studied by the Design Team was whether or not knowledge of RTT information was sufficient to geolocate a client. The analysis from Brian and Mirja [1] shows that this is a difficult, though possibly feasible, task, which seems contrary to the point that endpoints would have incentives to make it available. Moreover, several entities showed interest in greasing the spin bit to prevent ossification and, as a result, promote endpoint privacy. Regardless of the motives, it seems that clients do not have incentives to send accurate signaling information in all cases. 2. Parts of the document seem seemingly suggest that changes in network operator tooling is prohibitively costly and could possibly be considered a blocking factor when deciding which transport headers (if any) to encrypt. In particular, the Conclusion states that if the “currently deployed tools and methods are no longer relevant, then it may no longer be possible to correctly measure performance.” Perhaps the document should also state that an alternative outcome is that mechanisms, policies, and tooling change to adapt to transport encryption. While the needs of network operators may be real, they do not seem to trump security and privacy concerns of endpoints. Relatedly, is it worth encouraging research and development into techniques that allow endpoints to voluntarily share this information? As an extreme example, it could be possible to apply differential privacy techniques to diagnostic traceroute packet traces as a way of helping operators debug network issues. (The proposed IRTF PEARG indicated some interest in this direction.) 3. A seemingly large missed opportunity in this document is the discussion of TLS 1.3 deployment obstacles [2] and their impact on QUIC’s design decisions [3, Section 3.3]. There are many places where discussion of the TLS ossification problems would be appropriate, e.g., in Section 2 fourth paragraph describing shortcomings of integrity-only protections, Section 2 seventh paragraph describing greasing, and Section 4, first bullet. Increased encryption should help prevent invariant violation, which caused great pain when deploying TLS 1.3. Perhaps a clear statement of protocol invariants would have mitigated the deployment problems, though it happened nevertheless. That said, as stated in the document, encryption as a mitigation may not prevent ossification entirely, as network operators may come to rely on traffic patterns or other heuristics. (Related to TLS 1.3, it might be worth including TLS over TCP as a first class citizen in the document given its increase in use.) 4. The document focuses on transport header encryption and its impact on network operators. Perhaps it might be worth generalizing this to focus the impact of exposing explicit signals to the network, with encryption as one way of hiding such explicit signals. Implicit signals include those one can glean from connection metadata, e.g., traffic patterns, size, and timing information. 5. There’s a lot of redundant content spread across the document. A significant amount of information could be removed without loss of material, clarity, or continuity, and doing so would likely benefit the reader. Specifically, Sections 3.2.2, 3.2.3, 3.3, parts of 3.2.4 (first couple paragraphs), 5 (first two paragraphs), 6.3 (second paragraph), and 6.4 (most content) all contain redundant text that's worth trimming or removing altogether. I also have the following more specific comments about the document: - Section 2, eighth paragraph: encryption does not always prevent on-path devices from gaining knowledge of the header field. In particular, since QUIC Initial keys are public, it is possible for an on-path device to decrypt them for inspection. - Section 2, Network Operations and Research bullet: Perhaps state that observable headers permit *reliable* measurements, since methods based on implicit traffic signals exist and can be used for measurements. Also, regarding the statement that “concealing the transport protocol header information ... leads to the deployment of alternative methods to collect or infer that data,” is it possible to cite relevant examples? In the following paragraph, it states that payload confidentiality and header integrity can provide the “majority” of privacy and security benefits. What is this majority? I think being specific with concrete examples is important here. - Section 2: Network Troubleshooting and Diagnostics bullet: Should the document recent work on QUIC trace collections [4]? This tool was developed as a way to help Google debug (encrypted) QUIC connections in production, and seems relevant to this specific bullet. - Section 3.1.2: Is the itemized list supposed to capture metrics that can be derived from header information without encryption? If so, stating this explicitly would be useful. - Section 3.1.2, Variation bullet: This paragraph does not indicate why measuring delay variation is important for operators. Is it not true that only endpoints and applications are concerned with this metric? If not, perhaps describing why operators benefit from this information is useful. - Section 3.3, fourth paragraph: Is traffic injection possible with encrypted flows like TLS and QUIC? - Section 3.3, fifth paragraph: Might it be worth discussing the QUIC over satellite results from the IETF 103 MAPRG meeting [5]? Since encryption prevents traffic splitting, performance-enhancing proxies aimed at helping connections with such link diversity seem inapplicable. Nits: There are various spelling and grammatical errors in the document, though I’m sure they will be fixed in the final version. [1] https://link.springer.com/chapter/10.1007/978-3-319-76481-8_6 [2] https://tools.ietf.org/html/rfc8446#appendix-D.4 [3] https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/46403.pdf [4] https://github.com/google/quic-trace [5] https://datatracker.ietf.org/doc/slides-103-maprg-quic-and-satcom-nicolas-kuhn/