idnits 2.17.1 draft-trammell-optional-security-not-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: ---------------------------------------------------------------------------- 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 (October 17, 2019) is 1652 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 Google 4 Intended status: Informational October 17, 2019 5 Expires: April 19, 2020 7 Optional Security Is Not An Option 8 draft-trammell-optional-security-not-02 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 April 19, 2020. 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 origin 173 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]. 180 There are indications that this caution may be abating. At the RIPE 181 78 meeting in May 2019, Job Snijders reported that networks are 182 beginning to validate route origins, especially on peering sessions 183 [Snijders19]. Concerted effort to improve tooling for RPKI signing 184 and validation have reduced Q. Deployment is acclerating, which 185 Snijders attributes in part to fear of missing out: as individual 186 networks deploy validation and find that the risk to availability is 187 lower than feared, and their operators realize that the added 188 security of rejecting RPKI invalid announcements can be used as a 189 competetive advantage. The actions of smaller networks can drive to 190 decisions by larger ones: Snijders relates a story in which the 191 current "snowball effect" began with a single small operator in the 192 Netherlands announcing that they were rejecting invalids, and that 193 nothing bad had happened. This uptake appears to continue: RIPE NCC 194 reported at the following RIPE 79 meeting in October 2019 195 [Trenaman19] that the RPKI is growing to be a fundamental part of the 196 Internet infrastructure, and that they are increasing budget and 197 investing in technical infrastructure and process improvements to 198 better support RPKI. This investment and attention should have the 199 effect of reducing Q. 201 3.2. DNSSEC 203 The Domain Name System (DNS) [RFC1035] provides a distributed 204 protocol for the mapping of Internet domain names to information 205 about those names. As originally specified, an answer to a DNS query 206 was considered authoritative if it came from an authoritative server, 207 which does not allow for authentication of information in the DNS. 208 DNS Security [RFC4033] remedies this through an extension, allowing 209 DNS resource records to be signed using keys linked to zones, also 210 distributed via DNS. A name can be authenticated if every level of 211 the DNS hierarchy from the root up to the zone containing the name is 212 signed. 214 The root zone of the DNS has been signed since 2010. As of 2016, 89% 215 of TLD zones were also signed. However, the deployment status of 216 DNSSEC for second-level domains (SLDs) varies wildly from region to 217 region and is generally poor: only about 1% of .com, .net. and .org 218 SLDs were properly signed [DNSSEC-DEPLOYMENT]. Chung et al found 219 recently that second-level domain adoption was linked incentives for 220 deployment: TLDs which provided direct financial incentives to SLDs 221 for having correctly signed DNS zones tend to have much higher 222 deployment, though these incentives must be carefully designed to 223 ensure that they measure correct deployment, as opposed to more 224 easily-gamed indirect metrics [Chung17]. 226 However, the base-rate effect tends to reduce the use of DNSSEC 227 validating resolvers, which remains below 15% of Internet clients 228 [DNSSEC-DEPLOYMENT]. 230 DNSSEC deployment is hindered by other obstacles, as well. Since the 231 organic growth of DNS software predates even TCP/IP, even EDNS, the 232 foundational extension upon which DNSSEC is built are not universally 233 deployed, which inflates Q. The recent DNS Flag Day effort (see 234 https://dnsflagday.net) aims to remedy this by purposely breaking 235 backward interoperability with servers that are not EDNS-capable, by 236 coordinating action among DNS software developers and vendors. 238 In addition, for the Web platform at least, DNSSEC is not percieved 239 as having essential utility, given the deployment of TLS and the 240 assurances provided by the Web PKI (on which, see Section 3.3). A 241 connection intercepted due to a poisoned DNS cache would fail to 242 authenticate unless the attacker also obtained a valid certificate 243 from the name, rendering DNS interception less useful, in effect, 244 reducing P. 246 3.3. HTTP over TLS 248 Security was added to the Web via HTTPS, running HTTP over TLS over 249 TCP, in the 1990s [RFC2818]. Deployment of HTTPS crossed 50% of web 250 traffic in 2017. 252 Base-rate effects didn't hinder the deployment of HTTPS per se; 253 however, until recently, warnings about less-safe HTTPS 254 configurations (e.g. self-signed certificates, obsolete versions of 255 SSL/TLS, old ciphersuites, etc.) were less forceful due to the 256 prevalence of these configurations. As with DNS Flag Day, making 257 changes to browser user interfaces that inform the user of low- 258 security configurations is facilitated by coordination among browser 259 developers [ChromeHTTPS]. If one browser moves alone to start 260 displaying warnings or refusing to connect to sites with less-safe or 261 unsafe configurations, then users will tend to percieve the safer 262 browser as more broken, as websites that used to work don't anymore: 263 i.e., non-coordinated action can lead to the false perception that an 264 increase in P is an increase in Q. This coordination continues up 265 the Web stack within the W3C [SecureContexts]. 267 The Automated Certificate Management Environment [ACME] has further 268 accelerated the deployment of HTTPS on the server side, by 269 drastically reducing the effort required to properly manage server 270 certificates, reducing Q by making configuration easier than 271 misconfiguration. Let's Encrypt leverages ACME to make it possible 272 to offer certificates at scale for no cost with automated validation, 273 issuing 90 million active certificates protecting 150 million domain 274 names in December 2018 [LetsEncrypt2019]. 276 Deployment of HTTPS accelerated in the wake of the Snowden 277 revelations. Here, the perception of the utility of HTTPS has 278 changed. Increasing confidentiality of Web traffic for openly- 279 available content was widely seen as not worth the cost and effort 280 prior to these revelations. However, as it became clear that the 281 attacker model laid out in [RFC7624] was a realistic one, content 282 providers and browser vendors put the effort in to increase 283 implementation and deployment. 285 The ubiquitous deployment of HTTPS is not yet complete; however, all 286 indications are that it will represent a rare eventual success story 287 in the ubiquitous deployment of an optional security extention. What 288 can we learn from this success? We note that each endpoint deciding 289 to use HTTPS saw an immediate benefit, which is an indicator of good 290 chances of success for incremental deployment [RFC8170]. However, 291 the acceleration of deployment since 2013 is the result of the 292 coordinated effort of actors throughout the Web application and 293 operations stack, unified around a particular event which acted as a 294 call to arms. While there are downsides to market consolidation, the 295 relative consolidation of the browser market has made coordinated 296 action to change user interfaces possible, as well as making it 297 possible to launch a new certificate authority (by adding its issuer 298 to the trusted roots of a relatively small number of browsers) from 299 nothing in a short period of time. 301 4. Discussion and Recommendations 303 It has been necessary for all new protocol work in the IETF to 304 consider security since 2003 [RFC3552], and the Internet Architecture 305 Board recommended that all new protocol work provide confidentiality 306 by default in 2014 [IAB-CONFIDENTIALITY]; new protocols should 307 therefore already not rely on optional extensions to provide security 308 guarantees for their own operations or for their users. 310 In many cases in the running Internet, the ship has sailed: it is not 311 at this point realistic to replace protocols relying on optional 312 features for security with new, secure protocols. While these full 313 replacements would be less susceptible to base-rate effects, they 314 have the same misaligned incentives to deploy as the extensions the 315 architecture presently relies on. 317 The base rate fallacy is essential to this situation, so the P/Q 318 problem is difficult to sidestep. However, an examination of our 319 case studies does suggest incremental steps toward improving the 320 current situation: 322 o When natural incentives are not enough to overcome base-rate 323 effects, external incentives (such as financial incentives) have 324 been shown to be effective to motivate single deployment 325 decisions. This essentially provides utility in the form of cash, 326 offseting the negative cost of high Q. 328 o While "flag days" are difficult to arrange in the current 329 Internet, coordinated action among multiple actors in a market 330 (e.g. DNS resolvers or web browsers) can reduce the risk that 331 temporary breakage due to the deployment of new security protocols 332 is perceived as an error, at least reducing the false perception 333 of Q. 335 o Efforts to automate configuration of security protocols, and to 336 improve tooling for managing secure operations, can reduce the 337 incidence of misconfiguration Q, and have had a positive impact on 338 deployability. 340 Coordinated action has demonstrated success in the case of HTTPS, so 341 examining the outcome (or failure) of DNS Flag Day will provide more 342 information about the likelihood of future such actions to move 343 deployment of optional security features forward. It is difficult to 344 see how insights on coordinated action in DNS and HTTPS can be 345 applied to routing security, however, given the number of actors who 346 would need to coordinate to make present routing security approaches 347 widely useful. We note, however, that the MANRS effort 348 (https://www.manrs.org) provides an umbrella activity under which any 349 future coordination might take place. 351 We note that the cost of a deployment decision (at least for DNSSEC) 352 could readily be extracted from the literature [Chung17]. 353 Extrapolation from this work of a model for determining the total 354 cost of full deployment of DNSSEC (or, indeed, of comprehensive 355 routing security) is left as future work. 357 5. Acknowledgments 359 Many thanks to Peter Hessler, Geoff Huston, and Roland van Rijswijk- 360 Deij for conversations leading to the problem statement presented in 361 this document. Thanks to Martin Thomson for his feedback on the 362 document itself, which has greatly improved subsequent versions. The 363 title shamelessly riffs off that of Berkeley tech report about IP 364 options written by Rodrigo Fonseca et al., via a paper at IMC 2017 by 365 Brian Goodchild et al. 367 This work is partially supported by the European Commission under 368 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 369 for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat 370 for Education, Research, and Innovation under contract no. 15.0268. 371 This support does not imply endorsement. 373 6. Informative References 375 [ACME] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 376 Kasten, "Automatic Certificate Management Environment 377 (ACME)", draft-ietf-acme-acme-18 (work in progress), 378 December 2018. 380 [Axelsson99] 381 Axelsson, S., "The Base-Rate Fallacy and its Implications 382 for the Difficulty of Intrusion Detection (in ACM CCS 383 1999)", 1999, . 386 [ChromeHTTPS] 387 Schechter, E., "["A milestone for Chrome security - 388 marking HTTP as \"not secure\" (Google blog post)", nil]", 389 July 2018, . 392 [Chung17] Chung, T., van Rijswijk-Deij, R., Choffnes, D., Levin, D., 393 Maggs, B., Mislove, A., and C. Wilson, "Understanding the 394 Role of Registrars in DNSSEC Deployment", November 2017, 395 . 398 [DNSSEC-DEPLOYMENT] 399 Internet Society, ., "State of DNSSEC Deployment 2016", 400 December 2016, 401 . 404 [Gilad17] Gilad, Y., Cohen, A., Herzberg, A., Schapira, M., and H. 405 Schulman, "Are We There Yet? On RPKI's Deployment and 406 Security (in NDSS 2017)", November 2017, 407 . 411 [IAB-CONFIDENTIALITY] 412 Internet Architecture Board, ., "IAB Statement on Internet 413 Confidentiality", November 2014, 414 . 417 [LetsEncrypt2019] 418 Aas, J., "Looking Forward to 2019 (Let's Encrypt blog 419 post)", December 2018, 420 . 423 [Lychev13] 424 Lychev, R., Goldberg, S., and M. Schapira, "BGP Security 425 in Partial Deployment - Is the Squeeze Worth the Juice? 426 (in SIGCOMM 2013)", 2013, 427 . 430 [RFC1035] Mockapetris, P., "Domain names - implementation and 431 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 432 November 1987, . 434 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 435 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 436 1998, . 438 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 439 DOI 10.17487/RFC2818, May 2000, 440 . 442 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 443 Text on Security Considerations", BCP 72, RFC 3552, 444 DOI 10.17487/RFC3552, July 2003, 445 . 447 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 448 Rose, "DNS Security Introduction and Requirements", 449 RFC 4033, DOI 10.17487/RFC4033, March 2005, 450 . 452 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 453 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 454 DOI 10.17487/RFC4271, January 2006, 455 . 457 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 458 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 459 June 2010, . 461 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 462 Infrastructure (RPKI) to Router Protocol", RFC 6810, 463 DOI 10.17487/RFC6810, January 2013, 464 . 466 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 467 Trammell, B., Huitema, C., and D. Borkmann, 468 "Confidentiality in the Face of Pervasive Surveillance: A 469 Threat Model and Problem Statement", RFC 7624, 470 DOI 10.17487/RFC7624, August 2015, 471 . 473 [RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and 474 Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, 475 May 2017, . 477 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 478 Specification", RFC 8205, DOI 10.17487/RFC8205, September 479 2017, . 481 [SecureContexts] 482 van Kesteren, A., "Secure Contexts Everywhere", January 483 2018, . 486 [Snijders19] 487 Snijders, J., "Routing Security Update Q2 2019 (RIPE 78 488 presentation)", May 2019, . 491 [Trenaman19] 492 Trenaman, N., "RPKI Resilience - How Trustworthy is our 493 Trust Anchor?", October 2019, . 496 Author's Address 498 Brian Trammell 499 Google 500 Gustav-Gull-Platz 1 501 8004 Zurich 502 Switzerland 504 Email: ietf@trammell.ch