Optional Security Is Not An Option
draft-trammell-optional-security-not-01

Document Type Active Internet-Draft (individual)
Last updated 2019-01-14
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        B. Trammell
Internet-Draft                                                ETH Zurich
Intended status: Informational                          January 14, 2019
Expires: July 18, 2019

                   Optional Security Is Not An Option
                draft-trammell-optional-security-not-01

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.  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.

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 July 18, 2019.

Copyright Notice

   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

Trammell                  Expires July 18, 2019                 [Page 1]
Internet-Draft              optional-security               January 2019

   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.

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  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  HTTP over TLS . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Discussion and Recommendations  . . . . . . . . . . . . . . .   7
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   6.  Informative References  . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

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 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.

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.

Trammell                  Expires July 18, 2019                 [Page 2]
Internet-Draft              optional-security               January 2019

   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
Show full document text