idnits 2.17.00 (12 Aug 2021)
/tmp/idnits26036/draft-nottingham-transport-metadata-impact-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (August 24, 2015) is 2455 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
-- No information found for draft-sprecher-mobile-tg-exposure-req-arch - is
the name correct?
Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group M. Nottingham
3 Internet-Draft
4 Intended status: Informational J. Hall
5 Expires: February 25, 2016 CDT
6 N. ten Oever
7 Article19
8 W. Seltzer
9 W3C
10 August 24, 2015
12 User Impact of Transport Metadata
13 draft-nottingham-transport-metadata-impact-00
15 Abstract
17 This draft attempts to identify potential impacts associated with
18 new, extensible metadata facilities in Internet protocols, and
19 suggests possible mitigations. Its goal is to have the discussion of
20 these tradeoffs up-front, rather than after the development of such
21 mechanisms.
23 Status of This Memo
25 This Internet-Draft is submitted in full conformance with the
26 provisions of BCP 78 and BCP 79.
28 Internet-Drafts are working documents of the Internet Engineering
29 Task Force (IETF). Note that other groups may also distribute
30 working documents as Internet-Drafts. The list of current Internet-
31 Drafts is at http://datatracker.ietf.org/drafts/current/.
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet-Drafts as reference
36 material or to cite them other than as "work in progress."
38 This Internet-Draft will expire on February 25, 2016.
40 Copyright Notice
42 Copyright (c) 2015 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (http://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
55 Table of Contents
57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
58 2. Potential Impact . . . . . . . . . . . . . . . . . . . . . . 3
59 2.1. Security and Privacy . . . . . . . . . . . . . . . . . . 3
60 2.2. Network Neutrality . . . . . . . . . . . . . . . . . . . 4
61 3. Possible Mitigations . . . . . . . . . . . . . . . . . . . . 4
62 3.1. Constrained Vocabulary . . . . . . . . . . . . . . . . . 4
63 3.2. Transparency . . . . . . . . . . . . . . . . . . . . . . 5
64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
65 5. Informative References . . . . . . . . . . . . . . . . . . . 5
66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
68 1. Introduction
70 Recently, there has been an increasing amount of discussion in the
71 IETF about adorning protocol flows with metadata about the network's
72 state for consumption by applications, as well as that of the
73 application in order to inform decisions in the network. For
74 examples, see [I-D.nottingham-gin],
75 [I-D.sprecher-mobile-tg-exposure-req-arch] and
76 [I-D.hildebrand-spud-prototype].
78 These discussions are being at least partially motivated by the
79 increasing use of encryption, both in deployment (thanks to the
80 Snowden revelations) and standards (thanks in some part to [RFC7258],
81 [IAB-confidentiality], and [TAG-securing-web]); while it's becoming
82 widely accepted that networks don't have legitimate need to access
83 the content of flows in most cases, they still wish to meet certain
84 use cases that require more information.
86 For example, networks may wish to communicate their state to
87 applications, so that link limitations and transient problems can be
88 accounted for in applications, by doing things like degrading (or
89 improving) video streaming quality.
91 Applications also need to give enough information to networks to
92 enable proper function; e.g., packets in UDP flows need to be
93 associated to be able to cleanly transit NAT and firewalls. See
94 [I-D.trammell-stackevo-newtea] and [I-D.hardie-spud-use-cases] for
95 more discussion.
97 At the same time, it has been widely noted that "metadata" in various
98 forms can be profoundly sensitive information, particularly when
99 aggregated into large sets over extensive periods of time.
101 Indeed, much of the effort in combatting pervasive monitoring (as per
102 [RFC7258]) has focused on minimizing metadata in existing, known
103 protocols (such as TLS and HTTP).
105 Any new metadata facility, then - whether it be introduced to an
106 existing protocol, or as part of a new one - needs to be carefully
107 scrutinized and narrowly tailored to conservatively emit metadata.
108 Of particular concern is an observed trend towards arbitrarily
109 extensible metadata.
111 This draft attempts to identify potential impacts associated with new
112 metadata facilities in Internet protocols, and suggest possible
113 mitigations. Its goal is to initiate a discussion of these tradeoffs
114 up-front, rather than waiting until after the development of such
115 mechanisms.
117 Adding metadata to protocols is not an inherent harm - i.e., there
118 are some legitimate uses of metadata, particularly if it eases the
119 adoption of encrypted protocols or aligns well with both the
120 interests of users and service or network operations, e.g., traffic
121 management on mobile networks. However, the balance between the
122 interests of constituents like end users, content providers and
123 network operators needs to be carefully considered.
125 2. Potential Impact
127 2.1. Security and Privacy
129 It's been established [Injection] that many network operators inject
130 HTTP headers into requests, in order to identify their customers
131 using a unique identifier, thereby allowing "third-party advertisers
132 and websites to assemble a deep, permanent profile of visitors' web
133 browsing habits without their consent." [X-UIDH]
135 In doing so, these networks are taking advantage of a relatively
136 unconstrained extension point in the HTTP protocol - header fields.
137 While HTTP header fields do require registration [RFC3864], the
138 requirements are lax, and fields are often used without registration,
139 because there is no technical enforcement of the requirements, due to
140 HTTP's policy of ignoring unrecognized header fields [RFC7230].
142 HTTP header fields can be made a protected end-to-end facility by
143 using HTTPS, avoiding the risk of such injection. A new transport
144 metadata facility that explicitly allows any node on the path to add
145 arbitrary metadata cannot.
147 Well-intentioned metadata can also put the user at substantial risk
148 without careful consideration. For example, if a Web browser
149 "labels" flows based upon what they contain (e.g., "video", "image",
150 "interactive"), an observer on the network path - including pervasive
151 ones - can more effectively perform traffic analysis to determine
152 what the user is doing. Similarly, metadata adornment might reveal
153 sensitive information; for example the Server Name Indicator (SNI) in
154 the TLS handshake would reveal if a web visitor intends to go to
155 "bannedcontent.github.com" versus "kitties.github.com".
157 Standardizing an extensible transport metadata mechanism could also
158 trigger various jurisdictions to define and require insertion of in-
159 band metadata, an extension of current practices [AU-data-retention].
160 While the IETF would not be directly responsible for such an outcome,
161 it is notable that in the past we've explicitly said we won't serve
162 conceptually similar use cases [RFC1984].
164 2.2. Network Neutrality
166 There is obvious potential for network neutrality impact from a
167 mechanism that allows networks to communicate with endpoints about
168 flows.
170 For example, if a network can instruct content servers to throttle
171 back bandwidth available to users for video based upon a commercial
172 arrangement (or lack thereof), the network can achieve their goals
173 without directly throttling traffic, thereby offering the potential
174 to circumvent a regulatory regime that's designed to effect network
175 neutrality.
177 While the IETF has not take as firm a stance on network neutrality as
178 it has for Pervasive Monitoring (for good reasons, since network
179 neutrality problems are at their heart a sign of market failure, not
180 a technical issue), new metadata facilities that enable existing
181 regulatory regimes - thereby upsetting "the tussle" - must be
182 carefully considered.
184 3. Possible Mitigations
186 3.1. Constrained Vocabulary
188 Much of the potential for harm above comes about because a transport-
189 level metadata mechanism effectively becomes a side channel for
190 arbitrary data, for use by any node on the path. The risks of
191 questionable use could be mitigated by constraining the data that's
192 allowed in this side channel.
194 In other words, if the network doesn't have a means of inserting a
195 unique identifier for customers, they won't be able to do so. If
196 notification of constrained network conditions takes place using
197 well-defined terms, regulatory regimes can be adjusted to achieve
198 desired outcomes. And, information about application semantics can
199 be carefully vetted for security considerations before being included
200 in transport metadata.
202 One way to technically enforce such constraints would be to require
203 nodes to silently drop non-standard metadata. Another would be to
204 not make metadata extensible at all.
206 Naturally, this would constrain the ability of networks and
207 applications to add new terms to metadata, thereby requiring more
208 careful thought to go into the metadata that is standardised "up
209 front."
211 3.2. Transparency
213 Many proposals for transport metadata assert that it will be
214 encrypted, to improve security. While well-intentioned, it also
215 creates an opaque side channel with a third party (the first and
216 second being the endpoints).
218 The effect of of such designs should be carefully considered before
219 standardisation; it may be that the community is better served by
220 keeping this metadata "in the clear", albeit possibly with some form
221 of authentication and integrity available (or required).
223 4. Security Considerations
225 This document describes security and privacy aspects of metadata
226 adornment to internet protocols that protocol designers should
227 consider.
229 5. Informative References
231 [AU-data-retention]
232 Keane, B., "Your guide to the data retention debate: what
233 it is and why it's bad", March 2015,
234 .
237 [I-D.hardie-spud-use-cases]
238 Hardie, T., "Use Cases for SPUD", draft-hardie-spud-use-
239 cases-01 (work in progress), February 2015.
241 [I-D.hildebrand-spud-prototype]
242 Hildebrand, J. and B. Trammell, "Substrate Protocol for
243 User Datagrams (SPUD) Prototype", draft-hildebrand-spud-
244 prototype-03 (work in progress), March 2015.
246 [I-D.nottingham-gin]
247 Nottingham, M., "Granular Information about Networks",
248 draft-nottingham-gin-00 (work in progress), July 2014.
250 [I-D.sprecher-mobile-tg-exposure-req-arch]
251 Jain, A., Terzis, A., Sprecher, N., Swaminathan, S.,
252 Smith, K., and G. Klas, "Requirements and reference
253 architecture for Mobile Throughput Guidance Exposure",
254 draft-sprecher-mobile-tg-exposure-req-arch-01 (work in
255 progress), February 2015.
257 [I-D.trammell-stackevo-newtea]
258 Trammell, B., "Thoughts a New Transport Encapsulation
259 Architecture", draft-trammell-stackevo-newtea-01 (work in
260 progress), May 2015.
262 [IAB-confidentiality]
263 Internet Architecture Board, "IAB Statement on Internet
264 Confidentiality", November 2014,
265 .
268 [Injection]
269 Ammari, N., Björksten, G., Micek, P., and D.
270 Olukotun, "The Rise of Mobile Tracking Headers: How Telcos
271 Around the World Are Threatening Your Privacy", August
272 2015, .
276 [RFC1984] IAB and , "IAB and IESG Statement on Cryptographic
277 Technology and the Internet", RFC 1984, DOI 10.17487/
278 RFC1984, August 1996,
279 .
281 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
282 Procedures for Message Header Fields", BCP 90, RFC 3864,
283 DOI 10.17487/RFC3864, September 2004,
284 .
286 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
287 Protocol (HTTP/1.1): Message Syntax and Routing", RFC
288 7230, DOI 10.17487/RFC7230, June 2014,
289 .
291 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
292 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
293 2014, .
295 [TAG-securing-web]
296 W3C Technical Architecture Group, "Securing the Web",
297 January 2015, .
299 [X-UIDH] Hoffman-Andrews, J., "Verizon Injecting Perma-Cookies to
300 Track Mobile Customers, Bypassing Privacy Controls",
301 November 2014, .
304 Authors' Addresses
306 Mark Nottingham
308 Email: mnot@mnot.net
309 URI: https://www.mnot.net/
311 Joseph Lorenzo Hall
312 CDT
314 Email: joe@cdt.org
315 URI: https://cdt.org/
317 Niels ten Oever
318 Article19
320 Email: niels@article19.org
321 URI: https://www.article19.org/
323 Wendy Seltzer
324 W3C
326 Email: wseltzer@w3.org
327 URI: http://wendy.seltzer.org/