idnits 2.17.1 draft-trammell-optional-security-not-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 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 (March 18, 2018) is 2231 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-acme-acme-10 -- 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 (~~), 2 warnings (==), 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 March 18, 2018 5 Expires: September 19, 2018 7 Optional Security Is Not An Option 8 draft-trammell-optional-security-not-00 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. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 19, 2018. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Case studies . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Routing security: BGPSEC and RPKI . . . . . . . . . . . . 4 56 3.2. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.3. HTTP over TLS . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Discussion and guidelines . . . . . . . . . . . . . . . . . . 5 59 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 60 6. Informative References . . . . . . . . . . . . . . . . . . . 6 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 63 1. Introduction 65 Many of the protocols that make up the Internet architecture were 66 designed and first implemented in an envrionment of mutual trust 67 among network engineers, operators, and users, on computers that were 68 incapable of using cryptographic protocols to provide 69 confidentiality, integrity, and authenticity for those protocols, in 70 a legal environment where cryptographic technology was largely 71 protected by restricted licensing and/or prohibited by law. The 72 result has been a protocol stack where security properties have been 73 added to core protocols using those protocol's extension mechanisms. 75 As extension mechanisms are by design optional features of a 76 protocol, this has led to a situation where security is optional up 77 and down the protocol stack. Protocols with optional security have 78 proven to be difficult to deploy. This document describes and 79 examines this problem, and provides guidance for future evolution of 80 the protocol, based on current work in network measurement and usable 81 security research. 83 2. Problem statement 85 Consider an optional security extension with the following 86 properties: 88 1. The extension is optional: a given connection or operation will 89 succeed without the extension, albeit without the security 90 properties the extension guarantees. 92 2. The extension has a true positive probability P: the probability 93 that it will cause any given operation to fail, thereby 94 successfully preventing an attack that would have otherwise 95 succeeded had the extension not been enabled. This probability 96 is a function of the extension's effectiveness as well as the 97 probability that said operation will be an instance of the attack 98 the extension prevents. 100 3. The extension has a false positive probability Q: the probability 101 it will cause any given operation to fail due to some condition 102 other than an attack, e.g. due to a misconfiguration. 104 Moving from no deployment of an optional security extension to full 105 deployment is a protocol transition as described in [RFC8170]. We 106 posit that the implicit transition plans for these protocols have 107 generally suffered from an underestimation of a disincentive (section 108 5.2) linked to the relationship between P and Q for any given 109 protocol. 111 Specifically, if Q is much greater than P, then any user of an 112 optional security extension will face an overwhelming incentive to 113 disable that extension, as the cost of dealing with spuriously 114 failing operations becomes greater than the cost of dealing with 115 relatively rare successful attacks. This incentive becomes stronger 116 when the cause of the false positive is someone else's problem; i.e. 117 not a misconfiguration the user can possibly fix. This situation can 118 arise when poor design, documentation, or tool support elevates the 119 incidence of misconfiguration (high Q), in an environment where the 120 attack models addressed by the extension are naturally rare (low P). 122 This is not a novel observation; a similar phenomenon following from 123 the base-rate fallacy has been studied in the literature on 124 operational security, where the false positive and true positive 125 rates for intrusion detection systems have a similar effect on the 126 applicability of these systems. Axelsson showed [Axelsson99] that 127 the false positive rate must be held extremely low, on the order of 1 128 in 100,000, for the probability of an intrusion given an alarm to be 129 worth the effort of further investigation. 131 Indeed, the situation is even worse than this. Experience with 132 operational security monitoring indicates that when Q is high enough, 133 even true positives P may be treated as "in the way". 135 3. Case studies 137 Here we examine four optional security extensions, BGPSEC [RFC8205], 138 RPKI [RFC6810], DNSSEC [RFC4033], and the addition of TLS to HTTP/1.1 139 [RFC2818], to see how the relationship of P and Q has affected their 140 deployment. 142 3.1. Routing security: BGPSEC and RPKI 144 The Border Gateway Protocol [RFC4271] (BGP) is used to propagate 145 interdomain routing information in the Internet. Its original design 146 has no integrity protection at all, either on a hop-by-hop or on an 147 end-to-end basis. In the meantime, the TCP Authentication Option 148 [RFC5925] (and MD5 authentication [RFC2385], which it replaces) have 149 been deployed to add hop-by-hop integrity protection. 151 End-to-end protection of the integrity of BGP announcements is 152 protected by two complementary approaches. Route announcements in 153 BGP updates protected by BGPSEC [RFC8205] have the property that the 154 every Autonomous System (AS) on the path of ASes listed in the UPDATE 155 message has explicitly authorized the advertisement of the route to 156 the subsequent AS in the path. RPKI [RFC6810] protects prefixes, 157 granting the right to advertise a prefix (i.e., be the first AS in 158 the AS path) to a specific AS. RPKI serves as a trust root for 159 BGPSEC, as well. 161 These approaches are not yet universally deployed. BGP route origin 162 authentication approaches provide little benefit to individual 163 deployers until it is almost universally deployed [Lychev13]. RPKI 164 route origin validation is similarly deployed in about 15% of the 165 Internet core; two thirds of these networks only assign lower 166 preference to non-validating announcements. This indicates 167 significant caution with respect to RPKI mistakes [Gilad17]. In both 168 cases the lack of incentives for each independent deployment, 169 including the false positive risk, greatly reduces the speed of 170 incremental deployment and the chance of a successful transition 171 [RFC8170]. 173 3.2. DNSSEC 175 The Domain Name System (DNS) [RFC1035] provides a distributed 176 protocol for the mapping of Internet domain names to information 177 about those names. As originally specified, an answer to a DNS query 178 was considered authoritative if it came from an authoritative server, 179 which does not allow for authentication of information in the DNS. 180 DNS Security [RFC4033] remedies this through an extension, allowing 181 DNS resource records to be signed using keys linked to zones, also 182 distributed via DNS. A name can be authenticated if every level of 183 the DNS hierarchy from the root up to the zone containing the name is 184 signed. 186 The root zone of the DNS has been signed since 2010. As of 2016, 89% 187 of TLD zones were also signed. However, the deployment status of 188 DNSSEC for second-level domains (SLDs) varies wildly from region to 189 region and is generally poor: only about 1% of .com, .net. and .org 190 SLDs are properly signed [DNSSEC-DEPLOYMENT]. Chung et al found 191 recently that second-level domain adoption was linked incentives for 192 deployment: TLDs which provided direct financial incentives to SLDs 193 for having correctly signed DNS zones tend to have much higher 194 deployment [Chung17]. 196 However, the base-rate effect tends to reduce the use of DNSSEC 197 validating resolvers, which remains below 15% of Internet clients 198 [DNSSEC-DEPLOYMENT]. 200 3.3. HTTP over TLS 202 Security was added to the Web via HTTPS, running HTTP over TLS over 203 TCP, in the 1990s [RFC2818]. Deployment of HTTPS crossed 50% of web 204 traffic in 2017, due to accelerated deployment in the wake of the 205 Snowden revelations in 2013, and increased confidentiality of Web 206 content delivery was considered useful to address the attacker model 207 laid out in [RFC7624]. 209 Base-rate effects didn't hinder the deployment of HTTPS per se; 210 however, until recently, warnings about less-safe HTTPS 211 configurations (e.g. self-signed certificates) were less forceful due 212 to the prevalence of these configurations. The reduction of 213 misconfigurations and the cost of obtaining certificates with basic 214 authentication checks through automation [I-D.ietf-acme-acme] has 215 been a major force in improving Web security. 217 The ubiquitous deployment of HTTPS is a rare, eventual success story 218 in the deployment of an optional security mechanism. We note that 219 each endpoint deciding to use HTTPS saw an immediate benefit, which 220 indicates good chances of success for incremental deployment. 221 However, the acceleration of deployment since 2013 is the result of 222 the coordinated effort of actors throughout the Web application and 223 operations stack, unified around a particular event (the Snowden 224 relevations) which provided a "call to arms". 226 4. Discussion and guidelines 228 It has been necessary for all new protocol work in the IETF to 229 consider security since 2003 [RFC3552], and the Internet Architecture 230 Board recommended that all new protocol work provide confidentiality 231 by default in 2014 [IAB-CONFIDENTIALITY]; new protocols should 232 therefore already not rely on optional extensions to provide security 233 guarantees for their own operations or for their users. 235 In many cases in the running Internet, the ship has sailed: it is not 236 at this point realistic to replace protocols relying on optional 237 features for security with new, secure protocols: while these full 238 replacements are less susceptible to base-rate effects, they have the 239 same misaligned incentives to deploy. In these cases, we note that 240 there are, however, some small reasons for hope: 242 o When natural incentives are not enough to overcome base-rate 243 effects, external incentives (such as financial incentives) have 244 been shown to be effective to motivate single deployment 245 decisions. 247 o Efforts to automate configuration of security protocols, and 248 thereby reduce the incidence of misconfiguration Q, also has a 249 positive impact on deployability. 251 5. Acknowledgments 253 Many thanks to Peter Hessler, Geoff Huston, and Roland van Rijswijk- 254 Deij for conversations leading to the problem statement presented in 255 this document. The title shamelessly riffs off that of Berkeley tech 256 report about IP options written by Rodrigo Fonseca et al., via a 257 paper at IMC 2017 by Brian Goodchild et al. 259 This work is partially supported by the European Commission under 260 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 261 for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat 262 for Education, Research, and Innovation under contract no. 15.0268. 263 This support does not imply endorsement. 265 6. Informative References 267 [Axelsson99] 268 Axelsson, S., "The Base-Rate Fallacy and its Implications 269 for the Difficulty of Intrusion Detection (in ACM CCS 270 1999)", 1999, . 273 [Chung17] Chung, T., van Rijswijk-Deij, R., Choffnes, D., Levin, D., 274 Maggs, B., Mislove, A., and C. Wilson, "Understanding the 275 Role of Registrars in DNSSEC Deployment", November 2017, 276 . 279 [DNSSEC-DEPLOYMENT] 280 Internet Society, ., "State of DNSSEC Deployment 2016", 281 December 2016, 282 . 285 [Gilad17] Gilad, Y., Cohen, A., Herzberg, A., Schapira, M., and H. 286 Schulman, "Are We There Yet? On RPKI's Deployment and 287 Security (in NDSS 2017)", November 2017, 288 . 292 [I-D.ietf-acme-acme] 293 Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 294 Kasten, "Automatic Certificate Management Environment 295 (ACME)", draft-ietf-acme-acme-10 (work in progress), March 296 2018. 298 [IAB-CONFIDENTIALITY] 299 Internet Architecture Board, ., "IAB Statement on Internet 300 Confidentiality", November 2014, 301 . 304 [Lychev13] 305 Lychev, R., Goldberg, S., and M. Schapira, "BGP Security 306 in Partial Deployment - Is the Squeeze Worth the Juice? 307 (in SIGCOMM 2013)", 2013, 308 . 311 [RFC1035] Mockapetris, P., "Domain names - implementation and 312 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 313 November 1987, . 315 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 316 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 317 1998, . 319 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 320 DOI 10.17487/RFC2818, May 2000, 321 . 323 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 324 Text on Security Considerations", BCP 72, RFC 3552, 325 DOI 10.17487/RFC3552, July 2003, 326 . 328 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 329 Rose, "DNS Security Introduction and Requirements", 330 RFC 4033, DOI 10.17487/RFC4033, March 2005, 331 . 333 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 334 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 335 DOI 10.17487/RFC4271, January 2006, 336 . 338 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 339 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 340 June 2010, . 342 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 343 Infrastructure (RPKI) to Router Protocol", RFC 6810, 344 DOI 10.17487/RFC6810, January 2013, 345 . 347 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 348 Trammell, B., Huitema, C., and D. Borkmann, 349 "Confidentiality in the Face of Pervasive Surveillance: A 350 Threat Model and Problem Statement", RFC 7624, 351 DOI 10.17487/RFC7624, August 2015, 352 . 354 [RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and 355 Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, 356 May 2017, . 358 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 359 Specification", RFC 8205, DOI 10.17487/RFC8205, September 360 2017, . 362 Author's Address 364 Brian Trammell 365 ETH Zurich 366 Universitatstrasse 6 367 8092 Zurich 368 Switzerland 370 Email: ietf@trammell.ch