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

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Fri, 28 December 2018 15:19 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F2F12F1AC; Fri, 28 Dec 2018 07:19:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHENnIg4Hchk; Fri, 28 Dec 2018 07:19:46 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7499212E043; Fri, 28 Dec 2018 07:19:46 -0800 (PST)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id D20A61B0012D; Fri, 28 Dec 2018 15:19:37 +0000 (GMT)
Message-ID: <5C263F08.5010501@erg.abdn.ac.uk>
Date: Fri, 28 Dec 2018 15:19:36 +0000
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Christopher Wood <christopherwood07@gmail.com>
CC: secdir@ietf.org, tsvwg@ietf.org, draft-ietf-tsvwg-transport-encrypt.all@ietf.org, The IESG <iesg@ietf.org>
References: <CAO8oSXk5cZmKiqSGbURj3QZ-wGRpsg10HthREioaRrZtZmP8DQ@mail.gmail.com>
In-Reply-To: <CAO8oSXk5cZmKiqSGbURj3QZ-wGRpsg10HthREioaRrZtZmP8DQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/B0nRzJoLfCQSr0NOQ0XPJCk266E>
Subject: Re: [secdir] Secdir early review of draft-ietf-tsvwg-transport-encrypt-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Dec 2018 15:19:50 -0000

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/