idnits 2.17.1 draft-trammell-optional-security-not-01.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 a Security Considerations section. ** 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 (January 14, 2019) is 1922 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Trammell 3 Internet-Draft ETH Zurich 4 Intended status: Informational January 14, 2019 5 Expires: July 18, 2019 7 Optional Security Is Not An Option 8 draft-trammell-optional-security-not-01 10 Abstract 12 This document explores the common properties of optional security 13 protocols and extensions, and notes that due to the base-rate fallacy 14 and general issues with coordinated deployment of protocols under 15 uncertain incentives, optional security protocols have proven 16 difficult to deploy in practice. This document defines the problem, 17 examines efforts to add optional security for routing, naming, and 18 end-to-end transport, and extracts guidelines for future efforts to 19 deploy optional security protocols based on successes and failures to 20 date. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 18, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 2 58 3. Case studies . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Routing security: BGPSEC and RPKI . . . . . . . . . . . . 4 60 3.2. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.3. HTTP over TLS . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Discussion and Recommendations . . . . . . . . . . . . . . . 7 63 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 64 6. Informative References . . . . . . . . . . . . . . . . . . . 8 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 67 1. Introduction 69 Many of the protocols that make up the Internet architecture were 70 designed and first implemented in an envrionment of mutual trust 71 among network engineers, operators, and users, on computers that were 72 incapable of using cryptographic protection of confidentiality, 73 integrity, and authenticity for those protocols, in a legal 74 environment where the distribution of cryptographic technology was 75 largely restricted by licensing and/or prohibited by law. The result 76 has been a protocol stack where security properties have been added 77 to core protocols using those protocols' extension mechanisms. 79 As extension mechanisms are by design optional features of a 80 protocol, this has led to a situation where security is optional up 81 and down the protocol stack. Protocols with optional security have 82 proven to be difficult to deploy. This document describes and 83 examines this problem, and provides guidance for future evolution of 84 the protocol, based on current work in network measurement and usable 85 security research. 87 2. Problem statement 89 Consider an optional security extension with the following 90 properties: 92 1. The extension is optional: a given connection or operation will 93 succeed without the extension, albeit without the security 94 properties the extension guarantees. 96 2. The extension has a true positive probability P: the probability 97 that it will cause any given operation to fail, thereby 98 successfully preventing an attack that would have otherwise 99 succeeded had the extension not been enabled. This probability 100 is a function of the extension's effectiveness as well as the 101 probability that said operation will be an instance of the attack 102 the extension prevents. 104 3. The extension has a false positive probability Q: the probability 105 it will cause any given operation to fail due to some condition 106 other than an attack, e.g. due to a misconfiguration. 108 Moving from no deployment of an optional security extension to full 109 deployment is a protocol transition as described in [RFC8170]. We 110 posit that the implicit transition plans for these protocols have 111 generally suffered from an underestimation of the disincentive (as in 112 section 5.2 of [RFC8170]) linked to the relationship between P and Q 113 for any given protocol. 115 Specifically, if Q is much greater than P, then any user of an 116 optional security extension will face an overwhelming incentive to 117 disable that extension, as the cost of dealing with spuriously 118 failing operations overwhelms the cost of dealing with relatively 119 rare successful attacks. This incentive becomes stronger when the 120 cause of the false positive is someone else's problem; i.e. not a 121 misconfiguration the user can possibly fix. This situation can arise 122 when poor design, documentation, or tool support elevates the 123 incidence of misconfiguration (high Q), in an environment where the 124 attack models addressed by the extension are naturally rare (low P). 126 This is not a novel observation; a similar phenomenon following from 127 the base-rate fallacy has been studied in the literature on 128 operational security, where the false positive and true positive 129 rates for intrusion detection systems have a similar effect on the 130 applicability of these systems. Axelsson showed [Axelsson99] that 131 the false positive rate must be held extremely low, on the order of 1 132 in 100,000, for the probability of an intrusion given an alarm to be 133 worth the effort of further investigation. 135 Indeed, the situation is even worse than this. Experience with 136 operational security monitoring indicates that when Q is high enough, 137 even true positives P may be treated as "in the way". 139 3. Case studies 141 Here we examine four optional security extensions, BGPSEC [RFC8205], 142 RPKI [RFC6810], DNSSEC [RFC4033], and the addition of TLS to HTTP/1.1 144 [RFC2818], to see how the relationship of P and Q has affected their 145 deployment. 147 We choose these examples as all four represent optional security, and 148 that perfect deployment of the associated extensions - securing the 149 routing control plane, the Internet naming system, and end-to-end 150 transport (at least for the Web platform) - would represent 151 completely "securing" the Internet architecture at layers 3 and 4. 153 3.1. Routing security: BGPSEC and RPKI 155 The Border Gateway Protocol [RFC4271] (BGP) is used to propagate 156 interdomain routing information in the Internet. Its original design 157 has no integrity protection at all, either on a hop-by-hop or on an 158 end-to-end basis. In the meantime, the TCP Authentication Option 159 [RFC5925] (and MD5 authentication [RFC2385], which it replaces) have 160 been deployed to add hop-by-hop integrity protection. 162 End-to-end protection of the integrity of BGP announcements is 163 protected by two complementary approaches. Route announcements in 164 BGP updates protected by BGPSEC [RFC8205] have the property that the 165 every Autonomous System (AS) on the path of ASes listed in the UPDATE 166 message has explicitly authorized the advertisement of the route to 167 the subsequent AS in the path. RPKI [RFC6810] protects prefixes, 168 granting the right to advertise a prefix (i.e., be the first AS in 169 the AS path) to a specific AS. RPKI serves as a trust root for 170 BGPSEC, as well. 172 These approaches are not (yet) universally deployed. BGP route 173 origin authentication approaches provide little benefit to individual 174 deployers until it is almost universally deployed [Lychev13]. RPKI 175 route origin validation is similarly deployed in about 15% of the 176 Internet core; two thirds of these networks only assign lower 177 preference to non-validating announcements. This indicates 178 significant caution with respect to RPKI mistakes [Gilad17]. In both 179 cases the lack of incentives for each independent deployment, 180 including the false positive risk, greatly reduces the speed of 181 incremental deployment and the chance of a successful transition 182 [RFC8170]. 184 In addition, the perception of security as a secondary concern for 185 interdomain routing hinders deployment. A preference for secure 186 routes over insecure ones is necessary to drive further deployment of 187 routing security, but an internet service provider is unlikely to 188 prefer a secure route over an insecure route when the secure route 189 violates local preferences or results in a longer AS path [Lychev13]. 191 3.2. DNSSEC 193 The Domain Name System (DNS) [RFC1035] provides a distributed 194 protocol for the mapping of Internet domain names to information 195 about those names. As originally specified, an answer to a DNS query 196 was considered authoritative if it came from an authoritative server, 197 which does not allow for authentication of information in the DNS. 198 DNS Security [RFC4033] remedies this through an extension, allowing 199 DNS resource records to be signed using keys linked to zones, also 200 distributed via DNS. A name can be authenticated if every level of 201 the DNS hierarchy from the root up to the zone containing the name is 202 signed. 204 The root zone of the DNS has been signed since 2010. As of 2016, 89% 205 of TLD zones were also signed. However, the deployment status of 206 DNSSEC for second-level domains (SLDs) varies wildly from region to 207 region and is generally poor: only about 1% of .com, .net. and .org 208 SLDs were properly signed [DNSSEC-DEPLOYMENT]. Chung et al found 209 recently that second-level domain adoption was linked incentives for 210 deployment: TLDs which provided direct financial incentives to SLDs 211 for having correctly signed DNS zones tend to have much higher 212 deployment, though these incentives must be carefully designed to 213 ensure that they measure correct deployment, as opposed to more 214 easily-gamed indirect metrics [Chung17]. 216 However, the base-rate effect tends to reduce the use of DNSSEC 217 validating resolvers, which remains below 15% of Internet clients 218 [DNSSEC-DEPLOYMENT]. 220 DNSSEC deployment is hindered by other obstacles, as well. Since the 221 organic growth of DNS software predates even TCP/IP, even EDNS, the 222 foundational extension upon which DNSSEC is built are not universally 223 deployed, which inflates Q. The current DNS Flag Day effort (see 224 https://dnsflagday.net) aims to remedy this by purposely breaking 225 backward interoperability with servers that are not EDNS-capable, by 226 coordinating action among DNS software developers and vendors. 228 In addition, for the Web platform at least, DNSSEC is not percieved 229 as having essential utility, given the deployment of TLS and the 230 assurances provided by the Web PKI (on which, see Section 3.3). A 231 connection intercepted due to a poisoned DNS cache would fail to 232 authenticate unless the attacker also obtained a valid certificate 233 from the name, rendering DNS interception less useful, in effect, 234 reducing P. 236 3.3. HTTP over TLS 238 Security was added to the Web via HTTPS, running HTTP over TLS over 239 TCP, in the 1990s [RFC2818]. Deployment of HTTPS crossed 50% of web 240 traffic in 2017. 242 Base-rate effects didn't hinder the deployment of HTTPS per se; 243 however, until recently, warnings about less-safe HTTPS 244 configurations (e.g. self-signed certificates, obsolete versions of 245 SSL/TLS, old ciphersuites, etc.) were less forceful due to the 246 prevalence of these configurations. As with DNS Flag Day, making 247 changes to browser user interfaces that inform the user of low- 248 security configurations is facilitated by coordination among browser 249 developers [ChromeHTTPS]. If one browser moves alone to start 250 displaying warnings or refusing to connect to sites with less-safe or 251 unsafe configurations, then users will tend to percieve the safer 252 browser as more broken, as websites that used to work don't anymore: 253 i.e., non-coordinated action can lead to the false perception that an 254 increase in P is an increase in Q. This coordination continues up 255 the Web stack within the W3C [SecureContexts]. 257 The Automated Certificate Management Environment [ACME] has further 258 accelerated the deployment of HTTPS on the server side, by 259 drastically reducing the effort required to properly manage server 260 certificates, reducing Q by making configuration easier than 261 misconfiguration. Let's Encrypt leverages ACME to make it possible 262 to offer certificates at scale for no cost with automated validation, 263 issuing 90 million active certificates protecting 150 million domain 264 names in December 2018 [LetsEncrypt2019]. 266 Deployment of HTTPS accelerated in the wake of the Snowden 267 revelations. Here, the perception of the utility of HTTPS has 268 changed. Increasing confidentiality of Web traffic for openly- 269 available content was widely seen as not worth the cost and effort 270 prior to these revelations. However, as it became clear that the 271 attacker model laid out in [RFC7624] was a realistic one, content 272 providers and browser vendors put the effort in to increase 273 implementation and deployment. 275 The ubiquitous deployment of HTTPS is not yet complete; however, all 276 indications are that it will represent a rare eventual success story 277 in the ubiquitous deployment of an optional security extention. What 278 can we learn from this success? We note that each endpoint deciding 279 to use HTTPS saw an immediate benefit, which is an indicator of good 280 chances of success for incremental deployment [RFC8170]. However, 281 the acceleration of deployment since 2013 is the result of the 282 coordinated effort of actors throughout the Web application and 283 operations stack, unified around a particular event which acted as a 284 call to arms. While there are downsides to market consolidation, the 285 relative consolidation of the browser market has made coordinated 286 action to change user interfaces possible, as well as making it 287 possible to launch a new certificate authority (by adding its issuer 288 to the trusted roots of a relatively small number of browsers) from 289 nothing in a short period of time. 291 4. Discussion and Recommendations 293 It has been necessary for all new protocol work in the IETF to 294 consider security since 2003 [RFC3552], and the Internet Architecture 295 Board recommended that all new protocol work provide confidentiality 296 by default in 2014 [IAB-CONFIDENTIALITY]; new protocols should 297 therefore already not rely on optional extensions to provide security 298 guarantees for their own operations or for their users. 300 In many cases in the running Internet, the ship has sailed: it is not 301 at this point realistic to replace protocols relying on optional 302 features for security with new, secure protocols. While these full 303 replacements would be less susceptible to base-rate effects, they 304 have the same misaligned incentives to deploy as the extensions the 305 architecture presently relies on. 307 The base rate fallacy is essential to this situation, so the P/Q 308 problem is difficult to sidestep. However, an examination of our 309 case studies does suggest incremental steps toward improving the 310 current situation: 312 o When natural incentives are not enough to overcome base-rate 313 effects, external incentives (such as financial incentives) have 314 been shown to be effective to motivate single deployment 315 decisions. This essentially provides utility in the form of cash, 316 offseting the negative cost of high Q. 318 o While "flag days" are difficult to arrange in the current 319 Internet, coordinated action among multiple actors in a market 320 (e.g. DNS resolvers or web browsers) can reduce the risk that 321 temporary breakage due to the deployment of new security protocols 322 is perceived as an error, at least reducing the false perception 323 of Q. 325 o Efforts to automate configuration of security protocols, and 326 thereby reduce the incidence of misconfiguration Q, have had a 327 positive impact on deployability. 329 Coordinated action has demonstrated success in the case of HTTPS, so 330 examining the outcome (or failure) of DNS Flag Day will provide more 331 information about the likelihood of future such actions to move 332 deployment of optional security features forward. It is difficult to 333 see how insights on coordinated action in DNS and HTTPS can be 334 applied to routing security, however, given the number of actors who 335 would need to coordinate to make present routing security approaches 336 widely useful. We note, however, that the MANRS effort 337 (https://www.manrs.org) provides an umbrella activity under which any 338 future coordination might take place. 340 We note that the cost of a deployment decision (at least for DNSSEC) 341 could readily be extracted from the literature [Chung17]. 342 Extrapolation from this work of a model for determining the total 343 cost of full deployment of DNSSEC (or, indeed, of comprehensive 344 routing security) is left as future work. 346 5. Acknowledgments 348 Many thanks to Peter Hessler, Geoff Huston, and Roland van Rijswijk- 349 Deij for conversations leading to the problem statement presented in 350 this document. Thanks to Martin Thomson for his feedback on the 351 document itself, which has greatly improved subsequent versions. The 352 title shamelessly riffs off that of Berkeley tech report about IP 353 options written by Rodrigo Fonseca et al., via a paper at IMC 2017 by 354 Brian Goodchild et al. 356 This work is partially supported by the European Commission under 357 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 358 for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat 359 for Education, Research, and Innovation under contract no. 15.0268. 360 This support does not imply endorsement. 362 6. Informative References 364 [ACME] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 365 Kasten, "Automatic Certificate Management Environment 366 (ACME)", draft-ietf-acme-acme-18 (work in progress), 367 December 2018. 369 [Axelsson99] 370 Axelsson, S., "The Base-Rate Fallacy and its Implications 371 for the Difficulty of Intrusion Detection (in ACM CCS 372 1999)", 1999, . 375 [ChromeHTTPS] 376 Schechter, E., "["A milestone for Chrome security - 377 marking HTTP as \"not secure\" (Google blog post)", nil]", 378 July 2018, . 381 [Chung17] Chung, T., van Rijswijk-Deij, R., Choffnes, D., Levin, D., 382 Maggs, B., Mislove, A., and C. Wilson, "Understanding the 383 Role of Registrars in DNSSEC Deployment", November 2017, 384 . 387 [DNSSEC-DEPLOYMENT] 388 Internet Society, ., "State of DNSSEC Deployment 2016", 389 December 2016, 390 . 393 [Gilad17] Gilad, Y., Cohen, A., Herzberg, A., Schapira, M., and H. 394 Schulman, "Are We There Yet? On RPKI's Deployment and 395 Security (in NDSS 2017)", November 2017, 396 . 400 [IAB-CONFIDENTIALITY] 401 Internet Architecture Board, ., "IAB Statement on Internet 402 Confidentiality", November 2014, 403 . 406 [LetsEncrypt2019] 407 Aas, J., "Looking Forward to 2019 (Let's Encrypt blog 408 post)", December 2018, 409 . 412 [Lychev13] 413 Lychev, R., Goldberg, S., and M. Schapira, "BGP Security 414 in Partial Deployment - Is the Squeeze Worth the Juice? 415 (in SIGCOMM 2013)", 2013, 416 . 419 [RFC1035] Mockapetris, P., "Domain names - implementation and 420 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 421 November 1987, . 423 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 424 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 425 1998, . 427 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 428 DOI 10.17487/RFC2818, May 2000, 429 . 431 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 432 Text on Security Considerations", BCP 72, RFC 3552, 433 DOI 10.17487/RFC3552, July 2003, 434 . 436 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 437 Rose, "DNS Security Introduction and Requirements", 438 RFC 4033, DOI 10.17487/RFC4033, March 2005, 439 . 441 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 442 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 443 DOI 10.17487/RFC4271, January 2006, 444 . 446 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 447 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 448 June 2010, . 450 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 451 Infrastructure (RPKI) to Router Protocol", RFC 6810, 452 DOI 10.17487/RFC6810, January 2013, 453 . 455 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 456 Trammell, B., Huitema, C., and D. Borkmann, 457 "Confidentiality in the Face of Pervasive Surveillance: A 458 Threat Model and Problem Statement", RFC 7624, 459 DOI 10.17487/RFC7624, August 2015, 460 . 462 [RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and 463 Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, 464 May 2017, . 466 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 467 Specification", RFC 8205, DOI 10.17487/RFC8205, September 468 2017, . 470 [SecureContexts] 471 van Kesteren, A., "Secure Contexts Everywhere", January 472 2018, . 475 Author's Address 477 Brian Trammell 478 ETH Zurich 479 Universitatstrasse 6 480 8092 Zurich 481 Switzerland 483 Email: ietf@trammell.ch