Opportunistic Security: Some Protection Most of the Time
draft-dukhovni-opportunistic-security-03

The information below is for an old version of the document
Document Type Active Internet-Draft (individual in sec area)
Last updated 2014-08-15
Stream IETF
Intended RFC status Informational
Formats pdf htmlized bibtex
Reviews
Stream WG state Submitted to IESG for Publication
Doc Shepherd Follow-up Underway
Document shepherd Paul Hoffman
Shepherd write-up Show (last changed 2014-07-08)
IESG IESG state Waiting for Writeup
Consensus Boilerplate Unknown
Telechat date
Responsible AD Stephen Farrell
IESG note Shepherd write-up is promised for this week. I'll make my AD review comments
as IETF LC comments.
Send notices to ietf-dane@dukhovni.org, draft-dukhovni-opportunistic-security@tools.ietf.org
IANA IANA review state Version Changed - Review Needed
Network Working Group                                        V. Dukhovni
Internet-Draft                                                 Two Sigma
Intended status: Informational                           August 15, 2014
Expires: February 16, 2015

        Opportunistic Security: Some Protection Most of the Time
                draft-dukhovni-opportunistic-security-03

Abstract

   This memo introduces the "Opportunistic Security" (OS) protocol
   design pattern.  Protocol designs based on OS depart from the
   established practice of employing cryptographic protection against
   both passive and active attacks, or no protection at all.  As a
   result, with OS at least some cryptographic protection should be
   provided most of the time.  For example, the majority of Internet
   SMTP traffic is now opportunistically encrypted.  OS designs remove
   barriers to the widespread use of encryption on the Internet.  The
   actual protection provided by opportunistic security depends on the
   advertised security capabilities of the communicating peers.

   This document promotes designs in which cryptographic protection
   against both passive and active attacks can be rolled out
   incrementally as new systems are deployed, without creating barriers
   to communication.

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 http://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 February 16, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Dukhovni                Expires February 16, 2015               [Page 1]
Internet-Draft           Opportunistic Security              August 2014

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  The Opportunistic Security Design Pattern . . . . . . . . . .   5
   4.  Opportunistic Security Design Principles  . . . . . . . . . .   7
   5.  Example: Opportunistic TLS in SMTP  . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Historically, Internet security protocols have emphasized
   comprehensive "all or nothing" cryptographic protection against both
   passive and active attacks.  With each peer, such a protocol achieves
   either full protection or else total failure to communicate (hard
   fail).  As a result, operators often disable these security protocols
   at the first sign of trouble, degrading all communications to
   cleartext transmission.  Protection against active attacks requires
   authentication.  The ability to authenticate any potential peer on
   the Internet requires a key management approach that works for all.

   Designing and deploying a key management for the whole Internet is
   for now an unsolved problem.  For example, the Public Key
   Infrastructure (PKI) used by the web (often called the "Web PKI") is
   based on broadly trusted public certification authorities (CAs).  The
   Web PKI has too many trusted authorities and imposes burdens that not
   all peers are willing to bear.  Web PKI authentication is vulnerable
   to MiTM attacks when the peer reference identifier ([RFC6125]) is
   obtained indirectly over an insecure channel, perhaps via an MX or
   SRV lookup.  With so many certification authorities, which not
   everyone is willing to trust, the communicating parties don't always
   agree on a mutually trusted CA.  Without a mutually trusted CA,
   authentication fails, leading to communications failure.  The above
   issues are compounded by operational difficulties.  For example, a
Show full document text