Re: [secdir] Secdir early review of draft-ietf-tsvwg-transport-encrypt-03

[Gorry Fairhurst <[e-mail]>]

Thanks Christopher for taking the time to do this recview.

The editors will discuss and propose updates for the document,

gorry

On 27/12/2018, 01:02, Christopher Wood wrote:
> 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/