| Network Working Group | B. Trammell |
| Internet-Draft | |
| Intended status: Informational | October 17, 2019 |
| Expires: April 19, 2020 |
Optional Security Is Not An Option
draft-trammell-optional-security-not-02
This document explores the common properties of optional security protocols and extensions, and notes that due to the base-rate fallacy and general issues with coordinated deployment of protocols under uncertain incentives, optional security protocols have proven difficult to deploy in practice. This document defines the problem, examines efforts to add optional security for routing, naming, and end-to-end transport, and extracts guidelines for future efforts to deploy optional security protocols based on successes and failures to date.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 19, 2020.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Many of the protocols that make up the Internet architecture were designed and first implemented in an envrionment of mutual trust among network engineers, operators, and users, on computers that were incapable of using cryptographic protection of confidentiality, integrity, and authenticity for those protocols, in a legal environment where the distribution of cryptographic technology was largely restricted by licensing and/or prohibited by law. The result has been a protocol stack where security properties have been added to core protocols using those protocols’ extension mechanisms.
As extension mechanisms are by design optional features of a protocol, this has led to a situation where security is optional up and down the protocol stack. Protocols with optional security have proven to be difficult to deploy. This document describes and examines this problem, and provides guidance for future evolution of the protocol, based on current work in network measurement and usable security research.
Consider an optional security extension with the following properties:
Moving from no deployment of an optional security extension to full deployment is a protocol transition as described in [RFC8170]. We posit that the implicit transition plans for these protocols have generally suffered from an underestimation of the disincentive (as in section 5.2 of [RFC8170]) linked to the relationship between P and Q for any given protocol.
Specifically, if Q is much greater than P, then any user of an optional security extension will face an overwhelming incentive to disable that extension, as the cost of dealing with spuriously failing operations overwhelms the cost of dealing with relatively rare successful attacks. This incentive becomes stronger when the cause of the false positive is someone else’s problem; i.e. not a misconfiguration the user can possibly fix. This situation can arise when poor design, documentation, or tool support elevates the incidence of misconfiguration (high Q), in an environment where the attack models addressed by the extension are naturally rare (low P).
This is not a novel observation; a similar phenomenon following from the base-rate fallacy has been studied in the literature on operational security, where the false positive and true positive rates for intrusion detection systems have a similar effect on the applicability of these systems. Axelsson showed [Axelsson99] that the false positive rate must be held extremely low, on the order of 1 in 100,000, for the probability of an intrusion given an alarm to be worth the effort of further investigation.
Indeed, the situation is even worse than this. Experience with operational security monitoring indicates that when Q is high enough, even true positives P may be treated as “in the way”.
Here we examine four optional security extensions, BGPSEC [RFC8205], RPKI [RFC6810], DNSSEC [RFC4033], and the addition of TLS to HTTP/1.1 [RFC2818], to see how the relationship of P and Q has affected their deployment.
We choose these examples as all four represent optional security, and that perfect deployment of the associated extensions – securing the routing control plane, the Internet naming system, and end-to-end transport (at least for the Web platform) – would represent completely “securing” the Internet architecture at layers 3 and 4.
The Border Gateway Protocol [RFC4271] (BGP) is used to propagate interdomain routing information in the Internet. Its original design has no integrity protection at all, either on a hop-by-hop or on an end-to-end basis. In the meantime, the TCP Authentication Option [RFC5925] (and MD5 authentication [RFC2385], which it replaces) have been deployed to add hop-by-hop integrity protection.
End-to-end protection of the integrity of BGP announcements is protected by two complementary approaches. Route announcements in BGP updates protected by BGPSEC [RFC8205] have the property that the every Autonomous System (AS) on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route to the subsequent AS in the path. RPKI [RFC6810] protects prefixes, granting the right to advertise a prefix (i.e., be the first AS in the AS path) to a specific AS. RPKI serves as a trust root for BGPSEC, as well.
These approaches are not yet universally deployed. BGP route origin authentication approaches provide little benefit to individual deployers until it is almost universally deployed [Lychev13]. RPKI route origin validation is similarly deployed in about 15% of the Internet core; two thirds of these networks only assign lower preference to non-validating announcements. This indicates significant caution with respect to RPKI mistakes [Gilad17].
There are indications that this caution may be abating. At the RIPE 78 meeting in May 2019, Job Snijders reported that networks are beginning to validate route origins, especially on peering sessions [Snijders19]. Concerted effort to improve tooling for RPKI signing and validation have reduced Q. Deployment is acclerating, which Snijders attributes in part to fear of missing out: as individual networks deploy validation and find that the risk to availability is lower than feared, and their operators realize that the added security of rejecting RPKI invalid announcements can be used as a competetive advantage. The actions of smaller networks can drive to decisions by larger ones: Snijders relates a story in which the current “snowball effect” began with a single small operator in the Netherlands announcing that they were rejecting invalids, and that nothing bad had happened. This uptake appears to continue: RIPE NCC reported at the following RIPE 79 meeting in October 2019 [Trenaman19] that the RPKI is growing to be a fundamental part of the Internet infrastructure, and that they are increasing budget and investing in technical infrastructure and process improvements to better support RPKI. This investment and attention should have the effect of reducing Q.
The Domain Name System (DNS) [RFC1035] provides a distributed protocol for the mapping of Internet domain names to information about those names. As originally specified, an answer to a DNS query was considered authoritative if it came from an authoritative server, which does not allow for authentication of information in the DNS. DNS Security [RFC4033] remedies this through an extension, allowing DNS resource records to be signed using keys linked to zones, also distributed via DNS. A name can be authenticated if every level of the DNS hierarchy from the root up to the zone containing the name is signed.
The root zone of the DNS has been signed since 2010. As of 2016, 89% of TLD zones were also signed. However, the deployment status of DNSSEC for second-level domains (SLDs) varies wildly from region to region and is generally poor: only about 1% of .com, .net. and .org SLDs were properly signed [DNSSEC-DEPLOYMENT]. Chung et al found recently that second-level domain adoption was linked incentives for deployment: TLDs which provided direct financial incentives to SLDs for having correctly signed DNS zones tend to have much higher deployment, though these incentives must be carefully designed to ensure that they measure correct deployment, as opposed to more easily-gamed indirect metrics [Chung17].
However, the base-rate effect tends to reduce the use of DNSSEC validating resolvers, which remains below 15% of Internet clients [DNSSEC-DEPLOYMENT].
DNSSEC deployment is hindered by other obstacles, as well. Since the organic growth of DNS software predates even TCP/IP, even EDNS, the foundational extension upon which DNSSEC is built are not universally deployed, which inflates Q. The recent DNS Flag Day effort (see https://dnsflagday.net) aims to remedy this by purposely breaking backward interoperability with servers that are not EDNS-capable, by coordinating action among DNS software developers and vendors.
In addition, for the Web platform at least, DNSSEC is not percieved as having essential utility, given the deployment of TLS and the assurances provided by the Web PKI (on which, see Section 3.3). A connection intercepted due to a poisoned DNS cache would fail to authenticate unless the attacker also obtained a valid certificate from the name, rendering DNS interception less useful, in effect, reducing P.
Security was added to the Web via HTTPS, running HTTP over TLS over TCP, in the 1990s [RFC2818]. Deployment of HTTPS crossed 50% of web traffic in 2017.
Base-rate effects didn’t hinder the deployment of HTTPS per se; however, until recently, warnings about less-safe HTTPS configurations (e.g. self-signed certificates, obsolete versions of SSL/TLS, old ciphersuites, etc.) were less forceful due to the prevalence of these configurations. As with DNS Flag Day, making changes to browser user interfaces that inform the user of low-security configurations is facilitated by coordination among browser developers [ChromeHTTPS]. If one browser moves alone to start displaying warnings or refusing to connect to sites with less-safe or unsafe configurations, then users will tend to percieve the safer browser as more broken, as websites that used to work don’t anymore: i.e., non-coordinated action can lead to the false perception that an increase in P is an increase in Q. This coordination continues up the Web stack within the W3C [SecureContexts].
The Automated Certificate Management Environment [ACME] has further accelerated the deployment of HTTPS on the server side, by drastically reducing the effort required to properly manage server certificates, reducing Q by making configuration easier than misconfiguration. Let’s Encrypt leverages ACME to make it possible to offer certificates at scale for no cost with automated validation, issuing 90 million active certificates protecting 150 million domain names in December 2018 [LetsEncrypt2019].
Deployment of HTTPS accelerated in the wake of the Snowden revelations. Here, the perception of the utility of HTTPS has changed. Increasing confidentiality of Web traffic for openly-available content was widely seen as not worth the cost and effort prior to these revelations. However, as it became clear that the attacker model laid out in [RFC7624] was a realistic one, content providers and browser vendors put the effort in to increase implementation and deployment.
The ubiquitous deployment of HTTPS is not yet complete; however, all indications are that it will represent a rare eventual success story in the ubiquitous deployment of an optional security extention. What can we learn from this success? We note that each endpoint deciding to use HTTPS saw an immediate benefit, which is an indicator of good chances of success for incremental deployment [RFC8170]. However, the acceleration of deployment since 2013 is the result of the coordinated effort of actors throughout the Web application and operations stack, unified around a particular event which acted as a call to arms. While there are downsides to market consolidation, the relative consolidation of the browser market has made coordinated action to change user interfaces possible, as well as making it possible to launch a new certificate authority (by adding its issuer to the trusted roots of a relatively small number of browsers) from nothing in a short period of time.
It has been necessary for all new protocol work in the IETF to consider security since 2003 [RFC3552], and the Internet Architecture Board recommended that all new protocol work provide confidentiality by default in 2014 [IAB-CONFIDENTIALITY]; new protocols should therefore already not rely on optional extensions to provide security guarantees for their own operations or for their users.
In many cases in the running Internet, the ship has sailed: it is not at this point realistic to replace protocols relying on optional features for security with new, secure protocols. While these full replacements would be less susceptible to base-rate effects, they have the same misaligned incentives to deploy as the extensions the architecture presently relies on.
The base rate fallacy is essential to this situation, so the P/Q problem is difficult to sidestep. However, an examination of our case studies does suggest incremental steps toward improving the current situation:
Coordinated action has demonstrated success in the case of HTTPS, so examining the outcome (or failure) of DNS Flag Day will provide more information about the likelihood of future such actions to move deployment of optional security features forward. It is difficult to see how insights on coordinated action in DNS and HTTPS can be applied to routing security, however, given the number of actors who would need to coordinate to make present routing security approaches widely useful. We note, however, that the MANRS effort (https://www.manrs.org) provides an umbrella activity under which any future coordination might take place.
We note that the cost of a deployment decision (at least for DNSSEC) could readily be extracted from the literature [Chung17]. Extrapolation from this work of a model for determining the total cost of full deployment of DNSSEC (or, indeed, of comprehensive routing security) is left as future work.
Many thanks to Peter Hessler, Geoff Huston, and Roland van Rijswijk-Deij for conversations leading to the problem statement presented in this document. Thanks to Martin Thomson for his feedback on the document itself, which has greatly improved subsequent versions. The title shamelessly riffs off that of Berkeley tech report about IP options written by Rodrigo Fonseca et al., via a paper at IMC 2017 by Brian Goodchild et al.
This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat for Education, Research, and Innovation under contract no. 15.0268. This support does not imply endorsement.