One document matched: draft-dukhovni-opportunistic-security-06.xml

<?xml version="1.0" encoding="utf-8" ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY rfc3207 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3207.xml">
  <!ENTITY rfc4033 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml">
  <!ENTITY rfc4251 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4251.xml">
  <!ENTITY rfc4949 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4949.xml">
  <!ENTITY rfc5246 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml">
  <!ENTITY rfc5321 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5321.xml">
  <!ENTITY rfc5598 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5598.xml">
  <!ENTITY rfc6698 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6698.xml">
  <!ENTITY rfc7258 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7258.xml">
  <!ENTITY I-D.ietf-dane-smtp-with-dane SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dane-smtp-with-dane.xml">
]>

<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc subcompact="no" ?>
<?rfc symrefs="yes" ?>
<?rfc toc="yes" ?>

<rfc submissionType="independent" category="info" docName="draft-dukhovni-opportunistic-security-06" ipr="trust200902">
 <front>
  <title abbrev="Opportunistic Security">Opportunistic Security: Some
  Protection Most of the Time</title>
  <author initials="V." surname="Dukhovni" fullname="Viktor Dukhovni">
   <organization>Two Sigma</organization>
   <address>
    <email>ietf-dane@dukhovni.org</email>
   </address>
  </author>

  <date />

  <abstract>

   <t>
     This document defines the concept "Opportunistic Security" in
     the context of communications protocols.  Protocol designs
     based on Opportunistic Security use encryption even
     when authentication is not available, and use authentication
     when possible, thereby removing barriers to the widespread
     use of encryption on the Internet.
  </t>

  </abstract>

 </front>

 <middle>
  <section title="Introduction">


    <section title="Background">

     <t>
       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 when users have
       difficulty connecting, thereby degrading all communications
       to cleartext transmission.
     </t>

     <t>
       Protection against active attacks requires authentication. The
       ability to authenticate any potential peer on the Internet
       requires an authentication mechanism that encompasses all such
       peers.  No IETF standard for authentication scales as needed and
       has been deployed widely enough to meet this requirement.
     </t>

     <t>
       The Public Key Infrastructure (PKI) model employed by browsers
       to authenticate web servers (often called the "Web PKI")
       imposes cost and management burdens that have limited its
       use.  With so many Certification Authorities (CAs), not all
       of which 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 in protocols that mandate authentication.
       These issues are compounded by operational difficulties.
       For example, a common problem is for site operators to forget
       to perform timely renewal of expiring certificates.  In Web
       PKI interactive applications, security warnings are all too
       frequent, and end-users learn to actively ignore security
       problems, or site administrators decide that the maintenance
       cost is not worth the benefit so they provide a cleartext-only
       service to their users.
     </t>

     <t>
       The trust-on-first-use (TOFU) authentication approach assumes
       that an unauthenticated public key obtained on first contact
       (and retained for future use) will be good enough to secure
       future communication.  TOFU-based protocols do not protect
       against an attacker who can hijack the first contact
       communication and require more care from the end-user when
       systems update their cryptographic keys.  TOFU can make it
       difficult to distinguish routine key management from a
       malicious attack.
     </t>

     <t>
       DNS-Based Authentication of Named Entities (DANE <xref
       target="RFC6698"/>) defines a way to distribute public keys bound
       to DNS names.  It can provide an alternative to the Web PKI.
       DANE needs to be used in conjunction with DNSSEC <xref
       target="RFC4033"/>.  At the time of writing, DNSSEC is not
       sufficiently widely deployed to allow DANE to authenticate all
       potential peers.  Protocols that mandate authenticated
       communication cannot yet generally do so via DANE (at the time of
       writing).
     </t>

     <t>
       The lack of a global key management system means that for
       many protocols, only a minority of communications sessions
       can be predictably authenticated.  When protocols only offer
       a choice between authenticated-and-encrypted communication,
       or no protection, the result is that most traffic is sent
       in cleartext.  The fact that most traffic is not encrypted
       makes pervasive monitoring easier by making it cost-effective,
       or at least not cost-prohibitive (see <xref target="RFC7258"/>
       for more detail).
     </t>

     <t>
       For encryption to be used more broadly, authentication needs to
       be optional.  The use of encryption defends against pervasive
       monitoring and other passive attacks.  Even unauthenticated,
       encrypted communication (defined below) is preferable to
       cleartext.
     </t>

    </section>

    <section title="A New Perspective">

     <t>
       This document describes a change of perspective.  Until now,
       the protocol designer has viewed protection against both
       passive and active attacks as the default, and anything short
       of that as "degraded security" or a "fallback".  The new
       viewpoint is that without specific knowledge of peer
       capabilities (or explicit configuration or direct request
       of the application), the default protection is no protection,
       and anything more than that is an improvement.
     </t>

     <t>
       "Opportunistic Security" (OS) is defined as the use of
       cleartext as the baseline communication security policy,
       with encryption and authentication negotiated and applied
       to the communication when available.
     </t>

     <t>
       Cleartext, not comprehensive protection, is the default
       baseline.  An OS protocol is not falling back from comprehensive
       protection when that protection is not supported by all
       peers; rather, OS protocols aim to use the maximum protection
       that is available.  (At some point in time for a particular
       application or protocol all but a negligible fraction of
       peers might support encryption.  At that time, the baseline
       security might be raised from cleartext to always require
       encryption, and only authentication would have to be done
       opportunistically.)
     </t>

     <t>
       To achieve widespread adoption, OS must support incremental
       deployment.  Incremental deployment implies that security
       capabilities will vary from peer to peer, perhaps for a very
       long time.  OS protocols will attempt to establish encrypted
       communication whenever both parties are capable of such, and
       authenticated communication if that is also possible.  Thus,
       use of an OS protocol may yield communication that is authenticated
       and encrypted, unauthenticated but encrypted, or cleartext.
       This last outcome will occur if not all parties to a communication
       support encryption (or if an active attack makes it appear
       that this is the case).
     </t>

     <t>
       When less than complete protection is negotiated, there is
       no need to prompt the user with "your security may be degraded,
       please click OK" dialogs.  The negotiated protection is as
       good as can be expected.  Even if not comprehensive, it is
       often better than the traditional outcome of either "no
       protection" or "communications failure".
     </t>

     <t>
       OS is not intended as a substitute for authenticated, encrypted
       communication when such communication is already mandated by policy
       (that is, by configuration or direct request of the application) or
       is otherwise required to access a particular resource. In essence,
       OS is employed when one might otherwise settle for cleartext.  OS
       protocols never preempt explicit security policies. A security
       administrator may specify security policies that override OS.  For
       example, a policy might require authenticated, encrypted
       communication, in contrast to the default OS security policy.
     </t>

     <t>
       In this document, the word "opportunistic" carries a positive
       connotation.  Based on advertised peer capabilities, an OS
       protocol uses as much protection as possible.  The adjective
       "opportunistic" applies to the adaptive choice of security
       mechanisms peer by peer.  Once that choice is made for a
       given peer, OS looks rather similar to other designs that
       happen to use the same set of mechanisms.
     </t>

     <t>
       The remainder of this document provides definitions of
       important terms, sets out the OS design principles, and
       provides an example of an OS design in the context of
       communication between mail relays.
     </t>

    </section>

  </section>

  <section title="Terminology" anchor="sec_terminology">

   <t>
     <list style="hanging">

       <t hangText="Trust on First Use (TOFU):">In a protocol, TOFU
       calls for accepting and storing a public key or credential
       associated with an asserted identity, without authenticating
       that assertion.  Subsequent communication that is authenticated
       using the cached key or credential is secure against an MiTM
       attack, if such an attack did not succeed during the vulnerable
       initial communication.  The SSH protocol <xref target="RFC4251"/>
       in its commonly deployed form makes use of TOFU.  The phrase
       "leap of faith" (LoF, <xref target="RFC4949"/>) is sometimes
       used as a synonym.  </t>

       <t hangText="Authenticated, encrypted communication:">
       Encrypted communication using a session establishment method
       in which at least the initiator (or client) authenticates
       the identity of the acceptor (or server).  This is required
       to protect against both passive and active attacks.  Mutual
       authentication, in which the server also authenticates the
       client, plays a role in mitigating active attacks when the
       client and server roles change in the course of a single
       session. </t>

       <t hangText="Unauthenticated, encrypted communication:">Encrypted
       communication using a session establishment method that does
       not authenticate the identities of the peers.  In typical
       usage, this means that the initiator (client) has not verified
       the identity of the target (server), making MiTM attacks
       possible.  </t>

       <t hangText="Perfect Forward Secrecy (PFS):"> As defined in
       <xref target="RFC4949"/>.  </t>

       <t hangText="Man-in-the-Middle (MiTM) attack:"> As defined
       in <xref target="RFC4949"/>.  </t>

       <t hangText="OS protocol:">A protocol that follows the
       opportunistic approach to security described herein.  </t>

     </list>
   </t>

  </section>

  <section title="Opportunistic Security Design Principles">

   <t>
     OS provides a near-term approach to counter passive attacks
     by removing barriers to the widespread use of encryption.  OS
     offers an incremental path to authenticated, encrypted
     communication in the future, as suitable authentication
     technologies are deployed.  OS promotes the following design
     principles:
   </t>

   <t>
    <list style="hanging">

     <t hangText="Coexist with explicit policy:">Explicit security policies
     preempt OS.  Opportunistic security never displaces or preempts
     explicit policy.  Many applications and types of data are too
     sensitive to use OS, and more traditional security designs are
     appropriate in such cases.  </t>

     <t hangText="Prioritize communication:">The primary goal of
     OS is to not impede communication while maximizing the deployment
     of usable security.  OS protocols need to be deployable
     incrementally, with each peer configured independently by its
     administrator or user.  With OS, communication is still possible
     even when some peers support encryption or authentication and
     others do not. </t>

     <t hangText="Maximize security peer by peer:"> OS protocols
     use encryption when it is mutually supported.  OS protocols
     enforce peer authentication when an authenticated out-of-band
     channel is available to provide the requisite keys or credentials.
     In general, communication should be at least encrypted.  OS
     should employ Perfect Forward Secrecy (PFS) wherever possible
     in order to protect previously recorded encrypted communication
     from decryption even after a compromise of long-term keys.  </t>

     <t hangText="No misrepresentation of security:"> Unauthenticated,
     encrypted communication must not be misrepresented to users
     or in application logs of non-interactive applications as
     equivalent to authenticated, encrypted communication.  </t>

    </list>
   </t>

   <t>
     An OS protocol first determines the capabilities of the peer
     with which it is attempting to communicate.  Peer capabilities
     may be discovered by out-of-band or in-band means.  (Out-of-band
     mechanisms include the use of DANE records or cached keys or
     credentials acquired via TOFU. In-band determination implies
     negotiation between peers.)  The capability determination phase
     may indicate that the peer supports authenticated, encrypted
     communication; unauthenticated, encrypted communication; or
     only cleartext communication.
   </t>

   <t>
     Encryption is used to mitigate the risk of passive monitoring
     attacks, while authentication is used to mitigate the risk of
     active man-in-the-middle (MiTM) attacks.  When encryption
     capability is advertised over an insecure channel, MiTM downgrade
     attacks to cleartext may be possible.  Since encryption without
     authentication only mitigates passive attacks, this risk is
     consistent with the expected level of protection.  For
     authentication to protect against MiTM attacks the peer
     capability advertisements that convey support for authentication
     need to be over an out-of-band authenticated channel that is
     itself resistant to MiTM attack.
   </t>

   <t>
     Opportunistic security protocols may hard-fail with peers for
     which a security capability fails to function as advertised.
     Security services that work reliably (when not under attack)
     are more likely to be deployed and enabled by default.  It is
     vital that the capabilities advertised for an OS-compatible
     peer match the deployed reality.  Otherwise, OS systems will
     detect such a broken deployment as an active attack and
     communication may fail.  This might mean that advertised peer
     capabilities are further filtered to consider only those
     capabilities that are sufficiently operationally reliable.
     Capabilities that can't be expected to work reliably should
     be treated by an OS protocol as "not present" or "undefined".
   </t>

   <t>
     With unauthenticated, encrypted communication, OS protocols
     may employ more liberal settings than would be best-practice
     when security is mandated by policy.  Some legacy systems
     support encryption, but implement only outdated algorithms or
     protocol versions.  Compatibility with these systems avoids
     the need to resort to cleartext fallback.
   </t>

   <t>
     For greater assurance of channel security, an OS protocol may
     enforce more stringent cryptographic parameters when the session
     is authenticated.  For example, the set of enabled Transport
     Layer Security (TLS <xref target="RFC5246"/>) cipher suites
     might exclude deprecated algorithms that would be tolerated
     with unauthenticated, encrypted communication.
   </t>

   <t>
     OS protocols should produce authenticated, encrypted communication
     when authentication of the peer is "expected".  Here, "expected"
     means a determination via a downgrade-resistant method that
     authentication of that peer is expected to work.  Downgrade-resistant
     methods include: validated DANE DNS records, existing TOFU
     identity information, and manual configuration.  Such use of
     authentication is "opportunistic", in that it is performed
     when possible, on a per-session basis.
   </t>

   <t>
     When communicating with a peer that supports encryption but
     not authentication, any authentication checks enabled by default
     must be disabled or configured to soft-fail in order to avoid
     unnecessary communications failure or needless downgrade to
     cleartext.
   </t>

   <t>
     The support of cleartext and the use of outdated algorithms, and
     especially broken algorithms, is for backwards compatibility with
     systems already deployed.  Protocol designs based on Opportunistic
     Security prefer to encrypt, and prefer to use the best available
     encryption algorithms available.  OS protocols employ cleartext or
     broken encryption algorithms only with peers that do not appear to be
     capable of doing otherwise.  The eventual desire is to transition
     away from cleartext and broken algorithms, and particularly for
     broken algorithms, it is highly desirable to remove such
     functionality from implementations.
   </t>

  </section>

  <section title="Example: Opportunistic TLS in SMTP">

   <t>
     Most Message Transfer Agents (MTAs, <xref target="RFC5598"/>)
     support the STARTTLS (<xref target="RFC3207"/>) ESMTP extension.
     MTAs acting as SMTP (<xref target="RFC5321"/>) clients generally support cleartext
     transmission of email.  They negotiate TLS encryption when the
     SMTP server announces STARTTLS support.  Since the initial
     ESMTP negotiation is not cryptographically protected, the
     STARTTLS advertisement is vulnerable to MiTM downgrade attacks.
   </t>

   <t>
     Recent reports from a number of large providers (e.g., <xref
     target="fb-starttls"/> and <xref target="goog-starttls"/>)
     suggest that the  majority of SMTP email transmission on the
     Internet is now encrypted, and the trend is toward increasing
     adoption.
   </t>

   <t>
     Various MTAs that advertise STARTTLS exhibit interoperability
     problems in their implementations.  As a work-around, it is
     common for a client MTA to fall back to cleartext when the TLS
     handshake fails, or when TLS fails during message transmission.
     This is a reasonable trade-off, since STARTTLS only protects
     against passive attacks.  In the absence of an active attack
     TLS failures are generally one of the known interoperability
     problems.
   </t>

   <t>
     Some client MTAs employing STARTTLS abandon the TLS handshake
     when the server MTA fails authentication, and immediately start
     a cleartext connection.  Other MTAs have been observed to
     accept unverified self-signed certificates, but not expired
     certificates; again falling back to cleartext.  These and
     similar behaviors are NOT consistent with OS principles, since
     they needlessly fall back to cleartext when encryption is
     clearly possible.
   </t>

   <t>
     Protection against active attacks for SMTP is described in
     <xref target="I-D.ietf-dane-smtp-with-dane"/>.  That document
     introduces the terms "Opportunistic TLS" and "Opportunistic
     DANE TLS", and is consistent with the OS design principles
     defined in this document.  With "Opportunistic DANE TLS",
     authenticated, encrypted communication is enforced with peers
     for which appropriate DANE records are present.  For the
     remaining peers, "Opportunistic TLS"  is employed as before.
   </t>

  </section>

  <section title="Operational Considerations">

   <t>
     OS protocol designs should minimize the possibility of failure
     of negotiated security mechanisms.  OS protocols may need to
     employ "fallback", to work-around a failure of a security
     mechanisms that is found in practice to encounter interoperability
     problems.  The choice to implement or enable fallback should
     only be made in response to significant operational obstacles.
   </t>

   <t>
     When protection only against passive attacks is negotiated over a
     channel vulnerable to active downgrade attacks, and the use of
     encryption fails, a protocol might elect non-intrusive fallback to
     cleartext.  Failure to encrypt may be more often a symptom of an
     interoperability problem than an active attack.  In such a
     situation occasional fallback to cleartext may serve the greater
     good.  Even though some traffic is sent in the clear, the
     alternative is to ask the administrator or user to manually
     work-around such interoperability problems.  If the incidence of
     such problems is non-negligible, the user or administrator might
     find it more expedient to just disable Opportunistic Security.
   </t>

  </section>

  <section title="Security Considerations" anchor="sec_security">

   <t>
     OS supports communication that is authenticated and encrypted,
     unauthenticated and encrypted, or cleartext.  And yet the
     security provided to communicating peers is not reduced by the
     use of OS because the default OS policy employs the best
     security services available based on the capabilities of the
     peers, and because explicit security policies take precedence
     over the default OS policy.  OS is an improvement over the
     status quo; it provides better security than the alternative
     of providing no security services when authentication is not
     possible (and not strictly required).
   </t>

   <t>
     While the use of OS is preempted by a non-OS explicit policy,
     such a non-OS policy can be counter-productive when it demands
     more than many peers can in fact deliver.  Non-OS policy should
     be used with care, lest users find it too restrictive and act
     to disable security entirely.
   </t>

   <t>
     When protocols follow the OS approach, attackers engaged in
     large scale passive monitoring can no longer just collect
     everything, and have to be more selective and/or mount more
     active attacks. And OS means active attacks on everyone all
     the time are much more likely to be noticed.
   </t>

   <t>
     Specific techniques for detection and mitigation of active
     attacks in the absence of authentication are out of scope for
     this document. Some existing protocols that could support
     OS may be vulnerable to relatively low-cost downgrade attacks
     for attackers on the path.  However, when such attacks are
     employed pervasively in order to facilitate e,g, surveillance,
     this is often detectable; hence, even in such scenarios
     OS protocols provide a positive benefit.
   </t>

   <t>
     Protocols following the OS approach may need to define
     additional measures to make systematic downgrades less
     likely to succeed or more likely to be detected. When we
     have more experience in this space future revisions of this
     or related documents may be able to make more generally
     applicable recommendations.
   </t>

  </section>

  <section anchor="Acknowledgements" title="Acknowledgements">

    <t>
      I would like to thank Dave Crocker, Peter Duchovni, Paul
      Hoffman, Benjamin Kaduk, Steve Kent, Scott Kitterman, Pete
      Resnick, Martin Thomson, Nico Williams, Paul Wouters and
      Stephen Farrell for their many helpful suggestions and support.
    </t>

  </section>

 </middle>

 <back>
  <references title="Normative References">
   &rfc3207;
   &rfc4033;
   &rfc4251;
   &rfc4949;
   &rfc5246;
   &rfc5321;
   &rfc6698;
  </references>
  <references title="Informative References">
   &rfc5598;
   &rfc7258;
   &I-D.ietf-dane-smtp-with-dane;

   <reference
     target="https://www.facebook.com/notes/protect-the-graph/the-current-state-of-smtp-starttls-deployment/1453015901605223"
     anchor="fb-starttls">
    <front>
     <title>The Current State of SMTP STARTTLS Deployment</title>
     <author>
      <organization>Facebook</organization>
     </author>
     <date month="May" year="2014"/>
    </front>
   </reference>

   <reference
     target="https://www.google.com/transparencyreport/saferemail/"
     anchor="goog-starttls">
    <front>
     <title>Safer email - Transparency Report - Google</title>
     <author>
      <organization>Google</organization>
     </author>
     <date month="June" year="2014"/>
    </front>
   </reference>

  </references>
 </back>
</rfc>