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

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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY rfc3207 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3207.xml">
  <!ENTITY rfc4033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
  <!ENTITY rfc4949 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.xml">
  <!ENTITY rfc5116 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5116.xml">
  <!ENTITY rfc5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
  <!ENTITY rfc5598 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5598.xml">
  <!ENTITY rfc6125 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6125.xml">
  <!ENTITY rfc6698 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6698.xml">
  <!ENTITY rfc7258 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7258.xml">
  <!ENTITY I-D.ietf-dane-smtp-with-dane SYSTEM "http://xml.resource.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-03" 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 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.
   </t>

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

  </abstract>

 </front>

 <middle>
  <section title="Introduction">

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

   <t>
     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 (<xref target="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 common problem is for site
     operators to forget to perform timely renewal of expiring
     certificates.  In interactive applications, security warnings
     are all too frequent, and end-users learn to actively ignore
     security problems.
   </t>

   <t>
     DNS Security (DNSSEC <xref target="RFC4033"/>) can be used to
     leverage the global DNS infrastructure as a distributed
     authentication system.  DNS-Based Authentication of Named
     Entities (DANE <xref target="RFC6698"/>) provides the guidelines
     and DNS records to use the DNS as an alternative to the Web
     PKI.  However, at this time, DNSSEC is not sufficiently widely
     adopted to allow DANE to play the role of an Internet-wide
     any-to-any authentication system.  Therefore, protocols that
     mandate authentication for all peers cannot generally do so
     via DANE.  Opportunistic security protocols on the other hand,
     can begin to use DANE immediately, without waiting for universal
     adoption.
   </t>

   <t>
     Other authentication mechanisms have been designed that do not
     rely on trusted third parties.  The trust-on-first-use (TOFU)
     authentication approach makes a leap of faith (LoF, <xref
     target="RFC4949"/>) by assuming that unauthenticated public
     keys obtained on first contact will likely be good enough to
     secure future communication.  TOFU is employed in SSH and in
     various certificate pinning designs.  TOFU does not protect
     against an attacker who can hijack the first contact communication
     and requires more care from the end-user when systems update
     their cryptographic keys.  TOFU can make it difficult to
     distinguish routine system administration from a malicious
     attack.
   </t>

   <t>
     The lack of a global key management system means that for many
     protocols only a minority of communications sessions can be
     authenticated.  When protocols only offer the choice between
     an authenticated encrypted channel 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>
     To reach broad adoption, it must be possible to roll out support
     for unauthenticated encryption or authentication incrementally.
     Incremental rollout on the scale of the Internet means that
     for some considerable time security capabilities vary from
     peer to peer, and therefore protection against passive and
     active attacks needs to be applied selectively peer by peer.
   </t>

   <t>
     We will use the phrase "opportunistically employed" to mean
     that the use of a type of protection or a security mechanism
     was tailored to the advertised capabilities of the peer.  Both
     opportunistically employed encryption and opportunistically
     employed authentication need to avoid deployment roadblocks
     and need to be designed with care to "just work".
   </t>

   <t>
     To enable broader use of encryption, it must be possible to
     opportunistically employ encryption with peers that support
     it without always demanding authentication.  This defends
     against pervasive monitoring and other passive attacks, as
     even unauthenticated encryption (see definition in <xref
     target="sec_terminology"/>) is preferable to cleartext.
   </t>

   <t>
     The opportunistic security design pattern involves stepping
     up from a baseline security policy compatible with all relevant
     peers to the most secure policy compatible with the capabilities
     of a given peer.  Note, this is rather different from setting
     a high standard and attempting to determine (perhaps by asking
     the user) whether an exception can be made.
   </t>

   <t>
     The risk of active attacks should not be ignored.  The
     opportunistic security design pattern recommends that protocols
     employ multiple cryptographic protection levels, with encrypted
     transmission accessible to most if not all peers.  Protocol
     designers are encouraged to produce protocols that can securely
     determine which peers support authentication, and can then
     establish authenticated communication channels resistant to
     active attacks with those peers.
   </t>

   <t>
     Operators must be able specify explicit security policies that
     override opportunistic security where appropriate.
   </t>

  </section>

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

   <t>
     <list style="hanging">

       <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="Trust on First Use (TOFU):">In a protocol, TOFU
       typically consists of accepting and storing an asserted
       identity, without authenticating that assertion. Subsequent
       communication using the cached key/credential is secure
       against an MiTM attack, if such an attack did not succeed
       during the (vulnerable) initial communication.  The SSH
       protocol makes use of TOFU. The phrase "leap of faith" (LoF,
       <xref target="RFC4949"/>) is sometimes used as a synonym.
       </t>

       <t hangText="Authenticated encryption:"> Encryption using a
       session establishment method in which at least the initiator
       (client) authenticates the identity of the acceptor (server).
       This is required to protect against both passive and active
       attacks.  Authenticated encryption can be one-sided, where
       only the client authenticates the server.  One-sided
       authentication of the server by the client is the most common
       deployment used with Transport Layer Security (TLS, <xref
       target="RFC5246"/>) for "secure browsing" in which client
       authentication is typically performed at another layer in
       the protocol.  Authenticated encryption can also be two-sided
       or "mutual".  Mutual authentication plays a role in mitigating
       active attacks when the client and server roles change in
       the course of a single session.  Authenticated encryption
       is not synonymous with use of AEAD <xref target="RFC5116"/>.
       AEAD algorithms can be used with either authenticated or
       unauthenticated peers. </t>

       <t hangText="Unauthenticated Encryption:">Encryption 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.
       Unauthenticated encryption is not synonymous with non-use
       of AEAD <xref target="RFC5116"/>.  </t>

     </list>
   </t>

  </section>

  <section title="The Opportunistic Security Design Pattern">

   <t>
     Opportunistic Security is a protocol design pattern that aims
     to remove barriers to the widespread use of encryption on the
     Internet.  A related goal is broader adoption of protection
     against active attacks, by enabling incremental deployment of
     authenticated encryption.
   </t>

   <t>
     The opportunistic security design pattern supports multiple
     protection levels, while seeking the best protection possible.
   </t>

   <t>
     The determination of which security mechanisms to use can vary
     from case to case and depends on the properties of the protocol
     in which OS is applied.  In many cases, OS will result in
     negotiating channels with one of the following security
     properties:

     <list style="symbols">
      <t> No encryption (cleartext), which provides no protection
      against passive or active attacks.  </t>

      <t> Unauthenticated encryption (definition in <xref
      target="sec_terminology"/>), which protects only against
      passive attacks.  </t>

      <t> Authenticated encryption, (definition in <xref
      target="sec_terminology"/>) which protects against both passive
      and active attacks.  </t>
     </list>

   </t>

   <t>
     An opportunistic security protocol first determines the
     capabilities of a peer.  This might include whether that peer
     supports authenticated encryption, unauthenticated encryption
     or perhaps only cleartext.  After each peer has determined the
     capabilities of the other, the most preferred common security
     capabilities are activated.  Peer capabilities can be advertised
     out-of-band or (negotiated) in-band.
   </t>

   <t>
     An OS protocol may elect to apply more stringent security
     settings for authenticated encryption than for unauthenticated
     encryption.  For example, the set of enabled TLS cipher-suites
     might be more restrictive when authentication is required.
   </t>

   <t>
     Security services that "just work" 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.
   </t>

   <t>
     This might mean that peer capabilities are further filtered
     to consider only those capabilities that are sufficiently
     operationally reliable, and any that work only "some of the
     time" are treated by an opportunistic security protocol as
     "not present" or "undefined".
   </t>

   <t>
     Opportunistic security does not start with an over-estimate
     of peer capabilities only to settle for lesser protection when
     a peer fails to deliver.  Rather, opportunistic security sets
     a minimum protection level expected of all peers, which is
     raised for peers that are capable of more.
   </t>

   <t>
     Opportunistic security protocols should provide a means to
     enforce authentication for those peers for which authentication
     can be expected to succeed based on information advertised by
     the peer via DANE, TOFU or other means.  With DANE, the
     advertisement that a peer supports authentication is
     downgrade-resistant.  What is "opportunistic" here is the
     selective use of authentication for certain peers; much in the
     same way as unauthenticated encryption may be used "opportunistically"
     with peers capable of more than cleartext.
   </t>

   <t>
     Enforcement of authentication is not incompatible with
     opportunistic security.  If an OS-enabled peer (A) makes
     available authenticated key material, e.g., via DANE, to peer
     (B), then B should make use of this material to authenticate
     A, if B is OS-enabled and supports DANE.
   </t>

   <t>
     With a peer that does not advertise authentication support,
     to which transmission even in cleartext is permissible,
     authentication (or the lack thereof) must never downgrade
     encrypted communication to cleartext.  When employing opportunistic
     unauthenticated encryption, any enabled by default authentication
     checks need to be disabled or configured to soft-fail, allowing
     the unauthenticated encrypted session to proceed.
   </t>

   <t>
     Cleartext support is for backwards compatibility with already
     deployed systems.  Even when cleartext needs to be supported,
     protocol designs based on opportunistic security prefer to
     encrypt, employing cleartext only with peers that do not appear
     to be encryption capable.
   </t>

  </section>

  <section title="Opportunistic Security Design Principles">

   <t>
    <list style="hanging">

     <t hangText="Coexist with explicit policy:">Explicit security
     policy preempts opportunistic security.  Administrators or
     users can elect to disable opportunistic security for some or
     all peers and set a fixed security policy not based on
     capabilities advertised or published by the peer.  Alternatively,
     opportunistic security might be enabled only for specified
     peers, rather than by default.  Opportunistic security never
     displaces or preempts explicit policy.  Some applications or
     data may be too sensitive to employ opportunistic security,
     and more traditional security designs can be more appropriate
     in such cases.  </t>

     <t hangText="Emphasize enabling communication:"> The primary
     goal of opportunistic security is to enable secure communication
     and maximize deployment.  If potential peers are only capable
     of cleartext, then it may be acceptable to employ cleartext
     when encryption is not possible.  If authentication is only
     possible for some peers, then it is likely best to require
     authentication for only those peers and not the rest.
     Opportunistic security needs to be deployable incrementally,
     with each peer configured independently by its administrator
     or user.  Opportunistic security must not get in the way of
     two peers communicating when neither advertises or negotiates
     security services that are not in fact available or that don't
     function correctly. </t>

     <t hangText="Maximize security peer by peer:"> Opportunistic
     security strives to maximize security based on the capabilities
     of the peers.  Communications traffic should generally be at
     least encrypted.  Opportunistic security protocols may refuse
     to communicate with peers for which higher security is expected,
     but for some reason is not achieved.  Advertised capabilities
     must match reality to ensure that the only condition under
     which there is a failure of communication is when one or both
     peers are under an active attack.  </t>

     <t hangText="Employ PFS:"> Opportunistic Security should employ
     Perfect Forward Secrecy (PFS) 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 communication over an authenticated encrypted
     channel.  </t>

    </list>
   </t>

  </section>

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

   <t>
     Many Message Transfer Agents (MTAs, <xref target="RFC5598"/>)
     support the STARTTLS (<xref target="RFC3207"/>) ESMTP extension.
     MTAs acting as SMTP clients are generally willing to send email
     without TLS (and therefore without encryption), but will employ
     TLS (and therefore 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.  Further, MTAs do not
     generally require peer authentication.  Thus opportunistic TLS
     for SMTP only protects against passive attacks.
   </t>

   <t>
     Therefore, MTAs that implement opportunistic TLS either employ
     unauthenticated encryption or deliver over a cleartext channel.
     Recent reports from a number of large providers suggest that
     the majority of SMTP email transmission on the Internet is now
     encrypted, and the trend is toward increasing adoption.
   </t>

   <t>
     Not only is the STARTTLS advertisement vulnerable to active
     attacks, but also at present some MTAs that advertise STARTTLS
     exhibit various interoperability problems in their implementations.
     As a result, it is common practice to fall back to cleartext
     transmission not only when STARTTLS is not offered, but also
     when the TLS handshake fails, or even when TLS fails during
     message transmission.  This is a reasonable trade-off, since
     STARTTLS protects only against passive attacks, and absent an
     active attack TLS failures are simply interoperability problems.
   </t>

   <t>
     Some MTAs employing STARTTLS (<xref target="RFC3207"/>) abandon
     the TLS handshake when the server MTA fails authentication,
     only to immediately deliver the same message over a cleartext
     connection.  Other MTAs have been observed to tolerate unverified
     self-signed certificates, but not expired certificates, again
     falling back to cleartext.  These and similar implementation
     errors must be avoided.  In either case, had these MTAs instead
     used the OS design pattern, the communication would still have
     been encrypted and therefore protected against passive attacks.
   </t>

   <t>
     Protection against active attacks for SMTP is proposed in <xref
     target="I-D.ietf-dane-smtp-with-dane"/>.  That draft introduces
     the terms "Opportunistic TLS" and "Opportunistic DANE TLS",
     which are for now informal.
   </t>

  </section>

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

    <t>
      Though opportunistic security potentially supports transmission
      in cleartext, unauthenticated encryption, or other cryptographic
      protection levels short of the strongest potentially applicable,
      the effective security for peers is not reduced.  If a
      cryptographic capability is neither required by policy nor
      supported by the peer, nothing is lost by going without.
      Opportunistic security is strictly stronger than the alternative
      of providing no security services when maximal security is
      not applicable.
    </t>

    <t>
      Opportunistic security coexists with and is preempted by any
      applicable non-opportunistic security policy.  However, such
      non-opportunistic policy can be counter-productive when it
      demands more than many peers can in fact deliver.  Non-opportunistic
      policy should be used with care, lest users find it too
      restrictive and act to disable security entirely.
    </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.  I would like to thank
      Dave Crocker, Peter Duchovni, Paul Hoffman, Steve Kent, Scott
      Kitterman, Martin Thomson, Nico Williams, Paul Wouters and
      Stephen Farrell for their helpful suggestions and support.
    </t>

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

 </middle>

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