Network Working Group B. Trammell
Internet-Draft ETH Zurich
Intended status: Informational March 18, 2018
Expires: September 19, 2018
Optional Security Is Not An Option
draft-trammell-optional-security-not-00
Abstract
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.
Status of This Memo
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 September 19, 2018.
Copyright Notice
Copyright (c) 2018 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.
Trammell Expires September 19, 2018 [Page 1]
Internet-Draft optional-security March 2018
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 2
3. Case studies . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Routing security: BGPSEC and RPKI . . . . . . . . . . . . 4
3.2. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. HTTP over TLS . . . . . . . . . . . . . . . . . . . . . . 5
4. Discussion and guidelines . . . . . . . . . . . . . . . . . . 5
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
6. Informative References . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
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 protocols to provide
confidentiality, integrity, and authenticity for those protocols, in
a legal environment where cryptographic technology was largely
protected by restricted licensing and/or prohibited by law. The
result has been a protocol stack where security properties have been
added to core protocols using those protocol's 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.
2. Problem statement
Consider an optional security extension with the following
properties:
1. The extension is optional: a given connection or operation will
succeed without the extension, albeit without the security
properties the extension guarantees.
2. The extension has a true positive probability P: the probability
that it will cause any given operation to fail, thereby
successfully preventing an attack that would have otherwise
succeeded had the extension not been enabled. This probability
is a function of the extension's effectiveness as well as the
Trammell Expires September 19, 2018 [Page 2]
Internet-Draft optional-security March 2018
probability that said operation will be an instance of the attack
the extension prevents.
3. The extension has a false positive probability Q: the probability
it will cause any given operation to fail due to some condition
other than an attack, e.g. due to a misconfiguration.
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 a disincentive (section
5.2) 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 becomes greater than 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".
3. Case studies
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.
Trammell Expires September 19, 2018 [Page 3]
Internet-Draft optional-security March 2018
3.1. Routing security: BGPSEC and RPKI
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]. In both
cases the lack of incentives for each independent deployment,
including the false positive risk, greatly reduces the speed of
incremental deployment and the chance of a successful transition
[RFC8170].
3.2. DNSSEC
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
Trammell Expires September 19, 2018 [Page 4]
Internet-Draft optional-security March 2018
SLDs are 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 [Chung17].
However, the base-rate effect tends to reduce the use of DNSSEC
validating resolvers, which remains below 15% of Internet clients
[DNSSEC-DEPLOYMENT].
3.3. HTTP over TLS
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, due to accelerated deployment in the wake of the
Snowden revelations in 2013, and increased confidentiality of Web
content delivery was considered useful to address the attacker model
laid out in [RFC7624].
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) were less forceful due
to the prevalence of these configurations. The reduction of
misconfigurations and the cost of obtaining certificates with basic
authentication checks through automation [I-D.ietf-acme-acme] has
been a major force in improving Web security.
The ubiquitous deployment of HTTPS is a rare, eventual success story
in the deployment of an optional security mechanism. We note that
each endpoint deciding to use HTTPS saw an immediate benefit, which
indicates good chances of success for incremental deployment.
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 (the Snowden
relevations) which provided a "call to arms".
4. Discussion and guidelines
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
Trammell Expires September 19, 2018 [Page 5]
Internet-Draft optional-security March 2018
replacements are less susceptible to base-rate effects, they have the
same misaligned incentives to deploy. In these cases, we note that
there are, however, some small reasons for hope:
o When natural incentives are not enough to overcome base-rate
effects, external incentives (such as financial incentives) have
been shown to be effective to motivate single deployment
decisions.
o Efforts to automate configuration of security protocols, and
thereby reduce the incidence of misconfiguration Q, also has a
positive impact on deployability.
5. Acknowledgments
Many thanks to Peter Hessler, Geoff Huston, and Roland van Rijswijk-
Deij for conversations leading to the problem statement presented in
this document. 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.
6. Informative References
[Axelsson99]
Axelsson, S., "The Base-Rate Fallacy and its Implications
for the Difficulty of Intrusion Detection (in ACM CCS
1999)", 1999, <http://www.raid-
symposium.org/raid99/PAPERS/Axelsson.pdf>.
[Chung17] Chung, T., van Rijswijk-Deij, R., Choffnes, D., Levin, D.,
Maggs, B., Mislove, A., and C. Wilson, "Understanding the
Role of Registrars in DNSSEC Deployment", November 2017,
<https://conferences.sigcomm.org/imc/2017/papers/
imc17-final53.pdf>.
[DNSSEC-DEPLOYMENT]
Internet Society, ., "State of DNSSEC Deployment 2016",
December 2016,
<https://www.internetsociety.org/resources/doc/2016/
state-of-dnssec-deployment-2016/>.
Trammell Expires September 19, 2018 [Page 6]
Internet-Draft optional-security March 2018
[Gilad17] Gilad, Y., Cohen, A., Herzberg, A., Schapira, M., and H.
Schulman, "Are We There Yet? On RPKI's Deployment and
Security (in NDSS 2017)", November 2017,
<https://www.ndss-symposium.org/ndss2017/ndss-2017-
programme/
are-we-there-yet-rpkis-deployment-and-security/>.
[I-D.ietf-acme-acme]
Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", draft-ietf-acme-acme-10 (work in progress), March
2018.
[IAB-CONFIDENTIALITY]
Internet Architecture Board, ., "IAB Statement on Internet
Confidentiality", November 2014,
<https://www.iab.org/2014/11/14/
iab-statement-on-internet-confidentiality/>.
[Lychev13]
Lychev, R., Goldberg, S., and M. Schapira, "BGP Security
in Partial Deployment - Is the Squeeze Worth the Juice?
(in SIGCOMM 2013)", 2013,
<https://conferences.sigcomm.org/sigcomm/2013/papers/
sigcomm/p171.pdf>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, DOI 10.17487/RFC2385, August
1998, <https://www.rfc-editor.org/info/rfc2385>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
Trammell Expires September 19, 2018 [Page 7]
Internet-Draft optional-security March 2018
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6810] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol", RFC 6810,
DOI 10.17487/RFC6810, January 2013,
<https://www.rfc-editor.org/info/rfc6810>.
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
Trammell, B., Huitema, C., and D. Borkmann,
"Confidentiality in the Face of Pervasive Surveillance: A
Threat Model and Problem Statement", RFC 7624,
DOI 10.17487/RFC7624, August 2015,
<https://www.rfc-editor.org/info/rfc7624>.
[RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and
Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170,
May 2017, <https://www.rfc-editor.org/info/rfc8170>.
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
Specification", RFC 8205, DOI 10.17487/RFC8205, September
2017, <https://www.rfc-editor.org/info/rfc8205>.
Author's Address
Brian Trammell
ETH Zurich
Universitatstrasse 6
8092 Zurich
Switzerland
Email: ietf@trammell.ch
Trammell Expires September 19, 2018 [Page 8]