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

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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
  <!ENTITY rfc4949 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.xml">
  <!ENTITY rfc5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
  <!ENTITY rfc7258 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7258.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-01" 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 memo defines the term "opportunistic security".  In contrast
     to the established approach of delivering strong protection some of
     the time, opportunistic security strives to deliver at least some
     protection most of the time.  The primary goal is therefore broad
     interoperability, with security policy tailored to the capabilities
     of peer systems.
   </t>
  </abstract>

 </front>

 <middle>
  <section title="Introduction">

   <t>
     Historically, Internet security protocols have prioritized
     strong protection for peers capable and motivated to absorb
     the associated costs.  Since strong protection is not universally
     applicable, while communications traffic was sometimes strongly
     secured, more typically it was not protected at all.  The fact
     that most traffic is unprotected facilitates nation-state
     pervasive monitoring (PM <xref target="RFC7258"/>) by making
     it cost-effective (or at least not cost-prohibitive).
     Indiscriminate collection of communications traffic would be
     substantially less attractive if security protocols were
     designed to operate at a range of protection levels with
     encrypted transmission accessible to most if not all peers,
     and stronger security still available where required by policy
     or opportunistically negotiated.
   </t>

   <t>
     Encryption is easy, but key management is difficult.  Key
     management at Internet scale remains an incompletely solved
     problem.  The PKIX (<xref target="RFC5280"/>) key management model
     introduces costs that not all peers are willing to bear and is also
     not sufficient to secure communications when the peer reference
     identity is obtained indirectly over an insecure channel or
     communicating parties don't agree on a mutually trusted
     certification authority (CA).  DNSSEC is not at this time
     sufficiently widely adopted to make DANE a viable alternative at
     scale.  Trust on first use (TOFU) key management models (as with
     saved SSH fingerprints and various certificate pinning approaches)
     don't protect initial contact and require user intervention when
     key continuity fails.
   </t>

   <t>
     Without Internet-scale key management, authentication is often not
     possible.  When protocols only offer the options of
     strongly-authenticated secure channels or else no security, most
     traffic gets no security protection.  Therefore, in order to make
     encryption more ubiquitous, authentication needs to be optional.
     When strongly authenticated communication is not possible,
     unauthenticated encryption is still substantially stronger than
     cleartext.  Opportunistic security encourages peers to employ as
     much security as possible, without falling back to unnecessarily
     weak options.  In particular, opportunistic security encourages
     unauthenticated encryption when authentication is not an option.
   </t>

  </section>

  <section title="Opportunistic Security Design Philosophy">

   <t>
    <list style="hanging">

     <t hangText="Interoperate to maximize deployment:"> The primary
     goal of designs that feature opportunistic security is to be able
     to communicate with any reasonably configured peer.  If many peers
     are only capable of cleartext, then it is acceptable to fall back
     to cleartext when encryption is not possible.  If authentication is
     only possible for some peers, then it is acceptable to authenticate
     only those peers and not the rest.  Interoperability must be
     possible without bilateral coordination.  Applications employing
     opportunistic security need to be deployable at Internet scale,
     with each peer independently configured to meet its own security
     needs (within the practical bounds of the application protocol).
     Opportunistic security must not get in the way of the peers
     communicating if neither end is misconfigured.  </t>

     <t hangText="Maximize security peer by peer:"> Subject to the above
     large-scale interoperability goal, opportunistic security strives
     to maximize security based on the capabilities of the peer (or
     peers).  For some opportunistic security protocols the maximal
     protection possible may be just unauthenticated encryption.  For
     others, greater security may be an option, and opportunistic
     security may at times (in partial conflict with the
     interoperability goal) refuse to continue with peers where higher
     security is expected, but for some reason not achieved.  The
     conditions under which connections fail should generally be limited
     to operational errors at one or the other peer or an active attack,
     so that well-maintained systems rarely encounter problems in normal
     use of opportunistic security.  </t>

     <t hangText="Encrypt by default:"> An opportunistic security
     protocol MUST interoperably achieve at least unauthenticated
     encryption between peer systems that don't explicitly disable this
     capability.  Over time, as peer software is updated to support
     opportunistic security, only legacy systems or a minority of
     systems where encryption is disabled should be communicating in
     cleartext.  Whenever possible, opportunistic security should employ
     Perfect Forward Secrecy (PFS) to make recovery of previously sent
     keys and plaintext computationally expensive even after disclosure
     of long-term keys.  </t>

     <t hangText="No misrepresentation of security:"> Unauthenticated
     communication or use of authentication that is vulnerable to MiTM
     attacks is not represented as strong security.  Where strong
     security is required, opportunistic security is not a substitute,
     though the underlying mechanisms may in some cases be very similar.
     </t>

    </list>
   </t>

   <t>
     In summary, opportunistic security is an umbrella term that
     encompasses protocol designs that remove barriers to the
     widespread use of encryption in the Internet.  The actual
     protection provided by opportunistic security depends on the
     capabilities of the communicating peers; opportunistic security
     MUST attempt to at least encrypt network traffic, while allowing
     fallback to cleartext with peers that do not appear to be
     encryption capable.
   </t>

   <t>
     It is important to note that opportunistic security is not
     limited to unauthenticated encryption.  When possible,
     opportunistic security SHOULD provide stronger security on a
     peer-by-peer basis.  For example, some peers may be authenticated
     via DANE, TOFU or other means.  Though authentication failure
     MAY be a reason to abort a connection to a peer that is expected
     to be authenticated, it MUST NOT instead lead to communication
     in cleartext when encryption is an option.  Some sending MTAs
     employing STARTTLS have been observed to abort TLS transmission
     when the receiving MTA fails authentication, only to immediately
     deliver the same message over a cleartext connection.  This
     design blunder MUST be avoided.
   </t>

  </section>

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

   <t>
     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
     NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
     "MAY", and "OPTIONAL" in this document are to be interpreted
     as described in <xref target="RFC2119"/>.
   </t>

   <t>
     The following definitions are derived from the Internet Security
     Glossary <xref target="RFC4949" />, where applicable.

     <list style="hanging">
       <t hangText="Perfect Forward Secrecy (PFS):">For a key management
       protocol, the property that compromise of long-term keys does not
       compromise session/traffic/content keys that are derived from or
       distributed using the long-term keys.  </t>

       <t hangText="Man-in-the-Middle attack (MiTM):">A form of active
       wiretapping attack in which an attacker intercepts and may
       selectively modify communicated data to masquerade as one of the
       entities involved in a communication.  Masquerading enables the
       MiTM to violate the confidentiality and/or the integrity of
       communicated data passing through it.  </t>

       <t hangText="Trust on First Use (TOFU):">In a protocol, TOFU
       typically consists of accepting an asserted identity, without
       authenticating that assertion, and caching a key or credential
       associated with the identity.  Subsequent communication using the
       cached key/credential is secure against a MiTM attack, if such an
       attack did not succeed during the (vulnerable) initial
       communication or if the MiTM is not present for all subsequent
       communications.  The SSH protocol makes use of TOFU. The phrase
       "leap of faith" (LoF) is sometimes used as a synonym.</t>

       <t hangText="Unauthenticated Encryption:">Encryption using a key
       management technique that enables unauthenticated communication
       between parties. The communication may be 1-way or 2-way
       unauthenticated.  If 1-way, the initiator (client) or the target
       (server) may be anonymous.</t>
     </list>
   </t>

  </section>

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

    <t>
      Though opportunistic security potentially supports transmission in
      cleartext, unauthenticated encryption, or other protection levels
      short of the strongest potentially applicable, the effective
      security for users is increased, not reduced.  Provided strong
      security is not required by policy or securely negotiated, nothing
      is lost by allowing weaker protection levels, indeed opportunistic
      security is strictly stronger than the alternative of providing no
      security services when maximal security is not applicable.
    </t>

  </section>

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

    <t>
      I would like to thank Steve Kent.  Some of the text in this
      document is based on his earlier draft.
    </t>

  </section><!-- Acknowledgements -->

 </middle>

 <back>
  <references>
   &rfc2119;
   &rfc4949;
   &rfc5280;
   &rfc7258;
  </references>
 </back>
</rfc>