One document matched: draft-dukhovni-opportunistic-security-05.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-05" 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>
</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>
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. 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>
</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;
&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:38:37 |