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/