idnits 2.17.00 (12 Aug 2021) /tmp/idnits59001/draft-hardie-privsec-metadata-insertion-02.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7624]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 17 has weird spacing: '...able to desig...' == Line 285 has weird spacing: '...done on the...' -- The document date (March 20, 2016) is 2252 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 294, but no explicit reference was found in the text == Unused Reference: 'RFC2015' is defined on line 324, but no explicit reference was found in the text == Unused Reference: 'RFC4301' is defined on line 327, but no explicit reference was found in the text == Unused Reference: 'RFC4306' is defined on line 330, but no explicit reference was found in the text == Unused Reference: 'RFC5246' is defined on line 333, but no explicit reference was found in the text == Unused Reference: 'RFC5750' is defined on line 341, but no explicit reference was found in the text == Unused Reference: 'RFC6698' is defined on line 345, but no explicit reference was found in the text == Unused Reference: 'RFC6962' is defined on line 349, but no explicit reference was found in the text == Unused Reference: 'STRINT' is defined on line 360, but no explicit reference was found in the text == Outdated reference: draft-ietf-dnsop-edns-client-subnet has been published as RFC 7871 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5750 (Obsoleted by RFC 8550) -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Hardie, Ed. 3 Internet-Draft March 20, 2016 4 Intended status: Informational 5 Expires: September 19, 2016 7 Design considerations for Metadata Insertion 8 draft-hardie-privsec-metadata-insertion-02 10 Abstract 12 The IAB has published [RFC7624] in response to several revelations of 13 pervasive attack on Internet communications. In this document we 14 consider the implications of protocol designs which associate 15 metadata with encrypted flows. 16 In particular, we assert that designs which do so by explicit actions 17 of the end system are preferable to designs in which middleboxes 18 insert them. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 19, 2016. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Design patterns . . . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Forward-for in Forwarded HTTP Extension . . . . . . . . . 4 57 3.2. IP Address Propagation in DNS Requests . . . . . . . . . . 4 58 4. Advice . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5. Deployment considerations . . . . . . . . . . . . . . . . . . 5 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 8. Contributors {Contributors} . . . . . . . . . . . . . . . . . 6 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 65 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 To ensure that the Internet can be trusted by users, it is necessary 71 for the Internet technical community to address the vulnerabilities 72 exploited in the attacks document in [RFC7258] and the threats 73 described in [RFC7624]. The goal of this document is to address a 74 common design pattern which emerges from the increase in encryption: 75 explicit association of metadata which would previously have been 76 inferred from the plaintext protocol. 78 2. Terminology 80 This document makes extensive use of standard security and privacy 81 terminology; see [RFC4949] and [RFC6973]. Terms used from [RFC6973] 82 include Eavesdropper, Observer, Initiator, Intermediary, Recipient, 83 Attack (in a privacy context), Correlation, Fingerprint, Traffic 84 Analysis, and Identifiability (and related terms). In addition, we 85 use a few terms that are specific to the attacks discussed in this 86 document. Note especially that "passive" and "active" below do not 87 refer to the effort used to mount the attack; a "passive attack" is 88 any attack that accesses a flow but does not modify it, while an 89 "active attack" is any attack that modifies a flow. Some passive 90 attacks involve active interception and modifications of devices, 91 rather than simple access to the medium. The introduced terms are: 93 Pervasive Attack: An attack on Internet communications that makes use 94 of access at a large number of points in the network, or otherwise 95 provides the attacker with access to a large amount of Internet 96 traffic; see [RFC7258]. 98 Passive Pervasive Attack: An eavesdropping attack undertaken by a 99 pervasive attacker, in which the packets in a traffic stream 100 between two endpoints are intercepted, but in which the attacker 101 does not modify the packets in the traffic stream between two 102 endpoints, modify the treatment of packets in the traffic stream 103 (e.g. delay, routing), or add or remove packets in the traffic 104 stream. Passive pervasive attacks are undetectable from the 105 endpoints. Equivalent to passive wiretapping as defined in 106 [RFC4949]; we use an alternate term here since the methods 107 employed are wider than those implied by the word "wiretapping", 108 including the active compromise of intermediate systems. 110 Active Pervasive Attack: An attack undertaken by a pervasive 111 attacker, which in addition to the elements of a passive pervasive 112 attack, also includes modification, addition, or removal of 113 packets in a traffic stream, or modification of treatment of 114 packets in the traffic stream. Active pervasive attacks provide 115 more capabilities to the attacker at the risk of possible 116 detection at the endpoints. Equivalent to active wiretapping as 117 defined in [RFC4949]. 119 Observation: Information collected directly from communications by an 120 eavesdropper or observer. For example, the knowledge that 121 sent a message to via SMTP 122 taken from the headers of an observed SMTP message would be an 123 observation. 125 Inference: Information derived from analysis of information collected 126 directly from communications by an eavesdropper or observer. For 127 example, the knowledge that a given web page was accessed by a 128 given IP address, by comparing the size in octets of measured 129 network flow records to fingerprints derived from known sizes of 130 linked resources on the web servers involved, would be an 131 inference. 133 Collaborator: An entity that is a legitimate participant in a 134 communication, and provides information about that communication 135 to an attacker. Collaborators may either deliberately or 136 unwittingly cooperate with the attacker, in the latter case 137 because the attacker has subverted the collaborator through 138 technical, social, or other means. 140 Key Exfiltration: The transmission of cryptographic keying material 141 for an encrypted communication from a collaborator, deliberately 142 or unwittingly, to an attacker. 144 Content Exfiltration: The transmission of the content of a 145 communication from a collaborator, deliberately or unwittingly, to 146 an attacker. 148 Data Minimization: With respect to protocol design, refers to the 149 practice of only exposing the minimum amount of data or metadata 150 necessary for the task supported by that protocol to the other 151 endpoint(s) and/or devices along the path. 153 3. Design patterns 154 One of the core mitigations for the loss of confidentiality in the 155 presence of pervasive surveillance is data minimization, which limits 156 the amount of data disclosed to those elements absolutely required to 157 complete the relevant protocol exchange. When data minimization is 158 in effect, some information which was previously available may be 159 removed from specific protocol exchanges. The information may be 160 removed explicitly (by a browser suppressing cookies during private 161 modes, as an example) or by other means. As noted in [RFC7624], some 162 topologies which aggregate or alter the network path also act to 163 reduce the ease with which metadata is available to eavesdroppers. 165 In some cases, other actors within a protocol context will continue 166 to have access to the information which has been thus withdrawn from 167 specific protocol exchanges. If those actors attach the information 168 as metadata to those protocol exchange, the confidentiality effect of 169 data minimization is lost. 171 The restoration of information is particularly tempting for systems 172 whose primary function is not to provide confidentiality. A proxy 173 providing compression, for example, may wish to restore the identity 174 of the requesting party; similarly a VPN system used to provide 175 channel security may believe that origin IP should be restored. 176 Actors considering restoring metadata may believe that they 177 understand the relevant privacy considerations or believe that, 178 because the primary purpose of the service was not privacy-related, 179 none exist. Examples of this design pattern include "Forward-for" 180 described in [RFC7239] and anointing DNS queries with originating 181 network information as described in [I-D.ietf-dnsop-edns-client- 182 subnet]. 184 3.1. Forward-for in Forwarded HTTP Extension 186 [RFC7239] defines an HTTP header extension that seeks to add back 187 certain network metadata that can be lost in the process of proxying 188 a connection. The Forwarded-for extension allows a proxy to include 189 the originating IP address as part of the HTTP request. While there 190 are many types of HTTP proxies, some proxies seek to specifically 191 disassociate the origin IP address from the request, and adding back 192 this metadata without some explicit action of the user may 193 unwittingly expose metadata that users are specifically seeking to 194 protect through the use of such a proxy. 196 3.2. IP Address Propagation in DNS Requests 198 [I-D.ietf-dnsop-edns-client-subnet] describes and EDNS0 extension 199 that can propagate the IP address of the originating DNS query 200 through the DNS hierarchy of Recursive Resolvers to Authoritative 201 Nameservers. Many Authoritative Nameservers will tailor their 202 responses based on the IP address of the query, to provide a response 203 that is network-topologically more "close" to the query IP address. 204 Increasingly, Recursive Resolvers that clients use may not be close 205 to the originating IP address, so by carrying the originating query 206 IP address through to the Authoritative Nameserver, that server can 207 provide a more topologically-relevant response to the user. DNS 208 privacy is a significant challenge [RFC7626] which would only be 209 exacerbated by recursive resolvers no longer serving as aggregation 210 points for DNS queries and instead propagating those addresses up 211 through to the Authoritative Nameservers which would then be in a 212 position to profile the DNS traffic they receive based on originating 213 IP address. 215 4. Advice 217 Avoid this design pattern. It contributes to the overall loss of 218 confidentiality for the Internet and trust in the Internet as a 219 medium. Do not add metadata to flows at intermediary devices unless 220 a positive affirmation of approval for restoration has been received 221 from the actor whose data will be added. Instead, design the 222 protocol so that the actor can add such metadata themselves so that 223 it flows end-to-end, rather than requiring the action of other 224 parties. In addition to improving privacy, this approach ensures 225 consistent availability between the communicating parties, no matter 226 what path is taken. 228 5. Deployment considerations 230 There are two common tensions associated with the deployment of 231 systems which restore metadata. The first is the trade-off in speed 232 of deployment for different actors. The "Forward-for" method cited 233 above provides an example of this. When used with a proxy, 234 Forwarded-for restores the original identity of the requesting party, 235 thus allowing a responding server to tailor responses according to 236 the original party's region, network, or other characteristics 237 associated with the identity. It would, of course, be possible for 238 the originating client to add this data itself, using STUN [RFC5389] 239 or a similar mechanism to first determine the identity to declare. 240 This would require, however, full specification and adoption of this 241 mechanism by the end systems. It would not be available at all 242 during this period, and would thereafter be limited to those systems 243 which have been upgraded to include it. The long tail of browser 244 deployments indicates that many systems might go without upgrades for 245 a significant period of time. The proxy infrastructure, in contrast, 246 is commonly under more active management and represents a much 247 smaller number of elements; this impacts both the general deployment 248 difficulty and the number of systems which the origin server must 249 trust. 251 The second common tension is between the metadata minimization and 252 the desire to tailor content responses. For origin servers whose 253 content is common across users, the loss of metadata may have limited 254 impact on the system's functioning. For other systems, which 255 commonly tailor content by region or network, the loss of metadata 256 may imply a loss of functionality. Where the user desires this 257 functionality, restoration can commonly be achieved by the use of 258 other identifiers or login procedures. Where the user does not 259 desire this functionality, but it is a preference of the server or a 260 third party, adjustment is more difficult. At the extreme, content 261 blocking by network origin may be a regulatory requirement. Trusting 262 a network intermediary to provide accurate data is, of course, 263 fragile in this case, but it may be a part of the regulatory 264 framework. 266 These tensions do not change the basic recommendation, but they 267 suggest that the parties who are introducing encryption and data 268 minimization for existing protocols consider carefully whether the 269 work also implies introducing mechanisms for the end-to-end 270 provisioning of metadata when a user has actively consented to 271 provide it. 273 6. IANA Considerations 275 This memo makes no request of IANA. 277 7. Security Considerations 279 This memorandum describes a design pattern related emerging from 280 responses to the attacks described in [RFC7258]. Continued use of 281 this design pattern lowers the impact of mitigations to that attack. 283 8. Contributors {Contributors} 285 This document is derived in part from the work initially done on the 286 Perpass mailing list and at the STRINT workshop. It has been 287 discussed with the IAB's Privacy and Security program, whose review 288 is gratefully acknowledged. 290 9. References 292 9.1. Normative References 294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 295 Requirement Levels", BCP 14, RFC 2119, March 1997. 297 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 298 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . 301 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 302 Morris, J., Hansen, M. and R. Smith, "Privacy 303 Considerations for Internet Protocols", RFC 6973, DOI 304 10.17487/RFC6973, July 2013, . 307 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 308 Attack", BCP 188, RFC 7258, May 2014. 310 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 311 Trammell, B., Huitema, C. and D. Borkmann, 312 "Confidentiality in the Face of Pervasive Surveillance: A 313 Threat Model and Problem Statement", RFC 7624, DOI 314 10.17487/RFC7624, August 2015, . 317 9.2. Informative References 319 [I-D.ietf-dnsop-edns-client-subnet] 320 Contavalli, C., Gaast, W., tale, t. and W. Kumari, 321 "Client Subnet in DNS Queries", Internet-Draft draft-ietf- 322 dnsop-edns-client-subnet-06, December 2015. 324 [RFC2015] Elkins, M., "MIME Security with Pretty Good Privacy 325 (PGP)", RFC 2015, October 1996. 327 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 328 Internet Protocol", RFC 4301, December 2005. 330 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 331 4306, December 2005. 333 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 334 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 336 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P. and D. Wing, 337 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 338 DOI 10.17487/RFC5389, October 2008, . 341 [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 342 Mail Extensions (S/MIME) Version 3.2 Certificate 343 Handling", RFC 5750, January 2010. 345 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 346 of Named Entities (DANE) Transport Layer Security (TLS) 347 Protocol: TLSA", RFC 6698, August 2012. 349 [RFC6962] Laurie, B., Langley, A. and E. Kasper, "Certificate 350 Transparency", RFC 6962, June 2013. 352 [RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 353 RFC 7239, DOI 10.17487/RFC7239, June 2014, . 356 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 357 DOI 10.17487/RFC7626, August 2015, . 360 [STRINT] S Farrell, ., "Strint Workshop Report", April 2014, 361 . 364 Author's Address 366 Ted Hardie, editor 368 Email: ted.ietf@gmail.com