One document matched: draft-dukhovni-opportunistic-security-04.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-04" 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 remove barriers to the widespread
use of encryption on the Internet by using encryption even
when authentication is not available, and using authentication
when possible.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Broadly speaking, Opportunistic Security (OS) is a pragmatic
risk management approach. With Opportunistic Security, one
applies the tools at hand to mitigate the risks that can
reasonably be addressed, and accepts the rest.
</t>
<t> <list style="hanging">
<t hangText="Definition:"> In the context of communications
protocols, "Opportunistic Security" is defined as the use of
encryption when possible, with authentication when possible.
In the above, the phrase "when possible" means when support
for the corresponding capability is advertised by the peer,
ideally in a downgrade-resistant manner.</t>
</list> </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 alone
mitigates only passive attacks, this risk is consistent with
the expected level of protection. For authentication based
on peer capabilities to protect against MiTM attacks, capability
advertisements need to be over an out-of-band authenticated
channel that is itself resistant to MiTM attack.
</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>
For a particular protocol or application, if and when all but
a negligible fraction of peers support encryption, the baseline
security may be raised from cleartext to always require
encryption. Similarly, once support for authentication is
near-universal, the baseline may be raised to always require
authentication.
</t>
<t>
OS is not intended as a substitute for authenticated, encrypted
communication when such communication is already mandated by
policy or is otherwise required to access a particular resource.
In essence, OS is employed when one might otherwise settle for
cleartext (or the minimum protection possible if the protocol
is always encrypted). OS protocols never preempt local 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>
<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 standards for authentication 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, 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 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
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 system administration 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 satisfy
the Internet-wide, any-to-any authentication requirement
noted above. 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 (which are employed not
only by nation states). Even unauthenticated, encrypted
communication (defined below) is preferable to cleartext.
</t>
<t>
For some applications or protocols the set of potential peers
includes a long tail of implementations that support only
cleartext. Such applications or protocols cannot set a
baseline security policy that requires encryption without
losing the ability to communicate with the cleartext-only
peers.
</t>
</section>
<section title="A New Perspective">
<t>
This document proposes 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". Now, with
OS, the new viewpoint is that without specific knowledge of
peer capabilities (or applicable local policy), the default
protection is no protection, and anything more than that is
an improvement.
</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 employ the maximum protection
possible. OS protocols work transparently behind the scenes,
without disrupting communication.
</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>
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>
</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 local policy:">Local security policies
preempt OS. Opportunistic security never displaces or preempts
local 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="Emphasize enabling communication:">The primary
goal of OS is to enable communication and maximize the deployment
of usable security. OS protocols need to be deployable
incrementally, with each peer configured independently by its
administrator or user. </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.
Communication should generally 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>
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>
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 be more restrictive for authenticated sessions.
</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>
Cleartext is supported for backwards compatibility with systems
already deployed. 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="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. An active attacker could equally have
suppressed the use of encryption during negotiation, so 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 local 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 local 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>
</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, Benjamin Kaduk,
Steve Kent, Scott Kitterman, 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;
&rfc5246;
&rfc5321;
&rfc6698;
</references>
<references title="Informative References">
&rfc4949;
&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>
| PAFTECH AB 2003-2026 | 2026-04-23 15:39:02 |