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/