idnits 2.17.00 (12 Aug 2021) /tmp/idnits11388/draft-bertola-everything-but-the-user-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (4 January 2022) is 131 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Bertola 3 Internet-Draft Open-Xchange 4 Intended status: Informational 4 January 2022 5 Expires: 8 July 2022 7 Everything But The User Is An Intermediary 8 draft-bertola-everything-but-the-user-00 10 Abstract 12 This document provides the author's perspective on the shortcomings 13 of the Internet threat model defined in RFC 3552 and currently in use 14 at the IETF. It then proposes the basic conceptual framework for an 15 additional model, the "holistic threat model", describing how it 16 could be used to broaden the analysis of non-technical protocol 17 impacts in the design phase. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 8 July 2022. 36 Copyright Notice 38 Copyright (c) 2022 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised BSD License. 50 Table of Contents 52 1. Introduction and Background . . . . . . . . . . . . . . . . . 2 53 1.1. The End-to-End Principle . . . . . . . . . . . . . . . . 2 54 1.2. Intermediaries in Today's Internet . . . . . . . . . . . 2 55 1.3. The Current Internet Threat Model . . . . . . . . . . . . 3 56 2. Shortcomings of the Current Threat Model . . . . . . . . . . 4 57 2.1. Shortcomings in the Scope of Attackers . . . . . . . . . 4 58 2.2. Shortcomings in the Scope of Threats . . . . . . . . . . 6 59 3. The Holistic Threat Model . . . . . . . . . . . . . . . . . . 7 60 3.1. Applicability of the Holistic Threat Model . . . . . . . 8 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 6. Informative References . . . . . . . . . . . . . . . . . . . 9 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 66 1. Introduction and Background 68 1.1. The End-to-End Principle 70 The architecture and design of Internet protocols traditionally stems 71 from the "end-to-end principle" - the choice of concentrating the 72 intelligence and the complexity of the services of a network at its 73 edges, reducing to the minimum possible level the functions and the 74 prerogatives of the inner nodes of the network. When the 75 implementation of a network's functions is built as a set of layers 76 relying on each other, the intelligence and the complexity are pushed 77 upwards, to the layers nearer to the end-user, minimizing the 78 activities of the lower layers [Salzer]. 80 Under this principle, application-level protocols are designed as a 81 communication between two endpoints sitting at the edge of the 82 network, directly interacting with the respective end-users, or, for 83 human-to-server communication, with the physical or juridical entity 84 providing the service at the endpoint. While in some cases 85 communications can be directed to more than one endpoint, in-network 86 intermediaries to these communications simply do not exist; all 87 parties involved in the communication sit at the network's edge. 89 1.2. Intermediaries in Today's Internet 91 Over time, throughout the technical development of the Internet, it 92 has not always been possible to upkeep the end-to-end principle in 93 full. There now are services and functions that involve 94 intermediaries, that is, entities other than the endpoints, sitting 95 on the network path between them and performing higher-level 96 functions. 98 For example, the relative scarcity of IPv4 addresses prompted the 99 introduction of nodes that would encapsulate the end-user's traffic 100 and pretend to be the actual endpoint of the Internet connection, 101 then passing back the packets received in response. Security checks 102 have been implemented by having intermediate network nodes examine 103 all the traffic, sometimes up to content at the highest application 104 level, and determine whether such traffic should be allowed to reach 105 the other endpoint or not. 107 Some functionalities also require the involvement of third parties 108 acting as "side intermediaries", that is, additional parties to the 109 communication that sit elsewhere than on the network path between the 110 endpoints, and are brought into the communication as an endpoint to a 111 separate network connection. An example is the DNS resolution 112 process, as the network stack setting up a connection to the endpoint 113 must establish a separate connection to a separate service, the DNS 114 resolver, to discover the IP address of the endpoint from its name. 116 Given the general recognition of the end-to-end principle, the role 117 of intermediaries in the design of Internet protocols has generally 118 been controversial. As added parties into a communication, 119 intermediaries can be used as a point of surveillance and control 120 over traffic that the end-user did not mean them to see. On the 121 other hand, intermediaries can also be used to provide valuable 122 services, such as enabling the user to identify network destinations 123 by name rather than by IP address, or such as increased security for 124 users that would not be able to identify threats directly (e.g. 125 against phishing websites). 127 1.3. The Current Internet Threat Model 129 The threat model used when evaluating the safety of Internet 130 protocols has generally assumed that endpoint behaviour and risks are 131 out of scope, only focusing on the communication itself. Thus, in 132 the last decade, the increased attention to the privacy and security 133 of the end-user's network activities led to the progressive 134 elimination of intermediaries, especially those that were deployed by 135 network operators halfway on the path of Internet communications. 137 Frequently, the instrument used to this purpose has been the 138 encryption and disguise of communications between the two network 139 endpoints; sometimes, protocol changes, including high-level routing 140 changes and traffic aggregation, have also been conceived to reduce 141 opportunities for discriminating or tracking traffic. 143 In some cases, however, these instruments have been claimed to 144 produce effects that actually endanger the user's privacy and 145 security - among these, the aggregation and centralisation of traffic 146 into the infrastructure of a limited number of operators, and the 147 elimination of any possibility for positive intermediation, such as 148 in-network security checks. 150 As the overall privacy of the end-user's communication is determined 151 both by the privacy during the transport of the information and by 152 the privacy of the processing that happens within the endpoints, an 153 increase in the former could be compensated by a decrease in the 154 latter, with a negative net effect. At the IETF and elsewhere, 155 discussions are ongoing on how Internet protocol design could also 156 take into account this risk. 158 Since many of these threats are related to endpoint behaviour, or to 159 a combination of protocol features and non-technical endpoint 160 decisions such as the model, timeframe and policies for their 161 deployment, they cannot be caught by a threat model that declares 162 endpoints to be out of scope. 164 As a contribution to this discussion, this document proposes a 165 different and more general approach to the assessment of potential 166 risks, considering both in-network and endpoint actors as 167 intermediaries, and extending the analysis to non-technical issues. 168 This model could be used whenever a broader impact analysis is 169 considered useful. 171 2. Shortcomings of the Current Threat Model 173 The current Internet threat model is formalized in RFC 3552 174 [RFC3552]. While the goals described in section 2 of that document 175 are still generally valid, in today's Internet environment the threat 176 model described in section 3 sometimes fails to capture all the 177 relevant threats that could affect the accomplishment of those goals. 179 2.1. Shortcomings in the Scope of Attackers 181 The first shortcoming of the current Internet threat model is that it 182 attempts to evaluate the impact on the properties of a communication 183 between human beings (or between a human and a computer service) by 184 only assessing the properties of the communication between the 185 protocol endpoints, assuming for the purpose of protocol design that 186 no attacks can happen during the processing of communications between 187 the protocol endpoint and the end-user, or that these attacks can be 188 effectively pre-empted and countered by the end-user. 190 Section 3 of RFC 3552 supplies a justification for this assumption; 191 it states that "Protecting against an attack when one of the end- 192 systems has been compromised is extraordinarily difficult." Indeed, 193 under this assumption the protocol designer can conflate two separate 194 communication layers, the protocol one - an exchange of information 195 between two software or hardware elements acting as protocol 196 endpoints at the edges of the network - and the end-user one - an 197 exchange of information between human beings. This assumption is 198 quite helpful for protocol design, as it reduces the quantity and 199 quality of threats that have to be examined. However, it inevitably 200 excludes other relevant threats from the analysis, giving users no 201 protection from them. 203 This assumption could have been justified under a number of external 204 conditions that were mostly true when the original Internet threat 205 model was conceived, such as: 207 1. The end-user has full control over the device that they are 208 using. 210 2. The end-user is freely able to choose the application and the 211 operating system that they are using, picking some that they can 212 trust. 214 3. The end-user is sufficiently competent in technology to be able 215 to assess the risks of misbehaviour by the endpoint elements of 216 their communication, and to judge whether to entrust them with 217 data and information. 219 However, in today's Internet, these conditions are generally false. 220 Internet end-users are in average much less tech-literate than they 221 were in 2003, when RFC 3552 was written; even more so if we consider 222 the Internet of 1984, when the end-to-end principle as we know it 223 today was formalized. 225 Over the last decade, network services based on open, federated 226 protocols - like e-mail or the Web - have increasingly been 227 complemented or replaced by newer services - like instant messaging 228 or social media - based on a single-operator, single-implementation 229 "walled garden" model, thus giving the user much more limited 230 choices, or no choice at all, over which application to use. Most 231 users now access the Internet from smartphones, almost entirely 232 running on one of two dominant operating systems. To account for the 233 more limited technical competence of end-users, newer devices and 234 applications often give them limited configuration choices. The 235 advent of the cloud computing model has brought forth a vast range of 236 home appliances and software applications that only communicate with 237 the servers of their own makers, often with no opportunity for the 238 user to verify or alter their network communications. 240 While useful in technical terms, this assumption in today's scenario 241 - at least in some cases - leaves too many threats out of scope to be 242 still acceptable. 244 2.2. Shortcomings in the Scope of Threats 246 Another shortcoming of the current Internet threat model derives from 247 its limited technical focus. When it was designed, the threat model 248 focused only on the security of the communication; from the end- 249 user's viewpoint, communication security was defined in section 2.1 250 of RFC 3552 as the union of three more specific goals - 251 confidentiality, data integrity and peer entity authentication. 253 In 2013, the IETF deemed it necessary to add a separate, specific 254 focus on potential threats to the user's privacy, releasing RFC 6973 255 [RFC6973]. While building on the original goal of confidentiality, 256 this document moved the analysis to a higher, less technical level, 257 bringing into scope the non-technical consequences of technical 258 communication breaches. To protect the user's privacy effectively, 259 it was deemed necessary to consider the non-technical purposes and 260 motivations that could prompt an attacker to exploit any flaws and 261 weaknesses in communication protocols. Moreover, in section 4 RFC 262 6973 already questioned the validity of RFC 3552's assumption of non- 263 compromised endpoints. 265 In 2017, the scope of the suggested analysis was further broadened by 266 RFC 8280 [RFC8280]. While still being a proposal subject to further 267 research, this document codified an even broader range of non- 268 technical threats to social, economical and political rights, such as 269 freedom of expression, non-discrimination, freedom of assembly and so 270 on; it then suggested how to consider potential adverse effects to 271 these rights when designing protocols. 273 In the last twenty years, the IETF appears to have followed the 274 societal trend that, in parallel with the increased usage and 275 pervasiveness of the Internet in the everyday life of all human 276 beings, brought the non-technical consequences of technical design 277 choices by the Internet's technical community and industry to the 278 attention of the public opinion and of the policymakers. It is now 279 expected that a sense of social and corporate responsibility, and 280 policy objectives defined outside of the technical community, 281 contribute to shaping the choices that will determine the future 282 evolution of the Internet. 284 However, the analysis of non-technical consequences of technical 285 design choices does not just require technical skills, but also 286 competence in fields like business administration, economy, policy, 287 law and social sciences. The efforts of protocol engineers to take 288 into account the dynamics and the effects in these other fields are 289 commendable, but there is the need to bring the appropriate 290 competences into the discussion, while avoiding mission creep for 291 technical standards organizations. Any attempt to address this 292 shortcoming should also consider this issue. 294 3. The Holistic Threat Model 296 As a consequence of the shortcomings that have been identified above, 297 to perform a complete evaluation of the risks to the security and 298 privacy of end-users and to their rights in general, it would be 299 necessary to expand the scope of the threat analysis in two 300 directions. 302 First, it would be necessary to consider all elements that have 303 access to the end-user's information, data, metadata and content, 304 independently from whether they sit within the network or within the 305 endpoint devices; any element located anywhere between the fingers 306 (or other human-machine interface) of the sending end-user and the 307 eyes of the receiving end-user (or the operator of the application- 308 level Internet service) is in scope. In short, "everything but the 309 user is an intermediary"; since both the endpoint devices and any in- 310 network intermediaries have access to user information, all of them 311 should be considered as third parties that could potentially attack 312 the end-user. 314 Secondly, to understand how these elements might realistically 315 behave, it would be necessary to consider not just the technical 316 building blocks, but the physical or juridical entities that operate 317 or control them, and the non-technical motivations that could push 318 them to attack or constrain the user, such as economic advantages, 319 the accumulation and preservation of power, the desire to surveil or 320 stalk another person and many others. 322 Under this extended threat model, no claim should be made over the 323 privacy, security or any other property of Internet communications 324 from the end-user's perspective, unless all parties different from 325 the user(s) that take part in the communication, and all their 326 possible motivations, have been considered: hence the "holistic" 327 threat model. 329 3.1. Applicability of the Holistic Threat Model 331 In theory, the holistic threat model is a necessary response to the 332 shortcomings identified above. The more limited analysis performed 333 under the RFC 3552 threat model could not only lead to incomplete 334 results, failing to identify significant threats, but could even lead 335 to counterproductive results. Architectural choices that are 336 assessed as increasing the user's privacy could, under a broader 337 analysis of likely non-technical dynamics, actually cause new threats 338 to the user's privacy, for example by promoting business models based 339 on data monetization or the centralization of user information into 340 fewer hands. 342 However, the skillsets and research necessary to conduct such a 343 multidisciplinary analysis, and the sheer amount of actors and 344 possible behaviours, could make the effort too heavy and practically 345 unfeasible, or simply excessive for specifications of limited impact. 347 As an initial experiment, the holistic threat model could be applied 348 as a second step for selected documents, after performing a security 349 and privacy analysis under the current threat model, whenever the 350 initial examination of the properties of a new specification raises 351 concerns on potential broader impacts. 353 It is important to note that even the assessment on whether a 354 specification could have impacts on non-technical issues and 355 stakeholders requires in principle the broader skillset necessary to 356 perform the full analysis. In other words, to determine whether a 357 holistic assessment would be necessary, it is necessary to consult 358 the non-technical stakeholders that could be affected by the new 359 specification, letting them do a preliminary analysis and raise any 360 potential concerns before the specification is finalized. 362 In the end, the need identified by this document calls for a stronger 363 and more effective interaction between the IETF and other parts of 364 the Internet's industry, policy and user communities on a global 365 scale. Efforts to establish such an interaction should be made 366 jointly by the IETF and by the other relevant stakeholders; how to do 367 that in practice could be the subject of a separate discussion. 369 4. Security Considerations 371 This document discusses the assumptions under which security 372 considerations should be developed in the future. It is meant to 373 contribute to the ongoing discussion over a possible revision of RFC 374 3552 [RFC3552], which specifies how to write security considerations. 376 5. IANA Considerations 378 This document has no IANA actions. 380 6. Informative References 382 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 383 Text on Security Considerations", BCP 72, RFC 3552, 384 DOI 10.17487/RFC3552, July 2003, 385 . 387 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 388 Morris, J., Hansen, M., and R. Smith, "Privacy 389 Considerations for Internet Protocols", RFC 6973, 390 DOI 10.17487/RFC6973, July 2013, 391 . 393 [RFC8280] ten Oever, N. and C. Cath, "Research into Human Rights 394 Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280, 395 October 2017, . 397 [Salzer] Salzer, J. H., Reed, D. P., and D. D. Clark, "End-to-end 398 arguments in system design", 1 November 1984, 399 . 401 Author's Address 403 Vittorio Bertola 404 Open-Xchange Srl 405 Via Treviso 12 406 10144 Torino 407 Italy 409 Email: vittorio.bertola@open-xchange.com 410 URI: https://www.open-xchange.com/