Stephen,You are right that I failed to compare the released -03 version toSteve, On 18/08/14 22:18, Stephen Kent wrote:short of re-writing it for him, I don't see how to fix this mess.I think that's going too far and is disrespectful to Viktor and to those others who have expressed support for the document. That's especially egregious given that you haven't even bothered to compare -03 to the earlier on-list discussion. the pre-release version. When I began to read the released -03 version I noted that almost none of the suggested changes appeared in the abstract or in most of section 1, which promoted my reply. But, I agree that I should have read the rest of the doc before commenting. Now that I have read the whole doc, I see that Viktor did adopt make changes reflecting some of my comments, though not consistently. My apologies for not reading the entirety of the new version before commenting. Still, I stand by my comments that the doc was still badly written, though it was better in several respects. The fact that some others have commented that they find the quality of the writing to be acceptable does not change reality. I also note that several of those expressing support for the writing (not the design per se) have authored very few RFCs. Please provide a detailed description of how -03 does or does not map to the earlier mailing list discussion. I've done better that than. I have re-written the doc with an intent to address all of the issues I raised, retaining the design principles in the latest version, eliminating a lot of redundant text, and using less ambiguous language. The result is much shorter and, in my view, clearer and better organized. Steve ---------- Network Working Group
V.
Dukhovni Internet-Draft
Two Sigma Intended status: Informational August
15, 2014 Expires: February 16, 2015
Opportunistic Security: Some Protection Most of the Time
draft-dukhovni-opportunistic-security-03 Abstract This
memo
introduces the concept "Opportunistic Crypto-Security" (OCS). OCS is a set of protocol
design
principles that
attempt to remove
barriers to the widespread
use of encryption
on the Internet. OCS
is not a
protocol. Protocols that adhere to OCS guidelines may offer
additional
crypto-security services, e.g., integrity and authentication,
if these
services are supported by all parties to a
communication. The OCS
design philosophy departs from the common
practice of
other Internet security protocols; they commonly require
cryptographic
protection against both passive and active attacks,
or offer
no protection at all. OCS
protocols
strive to offer
encryption
even if authentication is
not available.
This document
encourages
designs in which cryptographic protection against
both
passive and active attacks can be deployed incrementally,
without
creating barriers to communication. Status of This Memo This
Internet-Draft
is submitted in full conformance with the provisions
of
BCP 78 and BCP 79. Internet-Drafts
are
working documents of the Internet Engineering Task
Force
(IETF). Note that other
groups may also
distribute working
documents
as Internet-Drafts. The
list
of current Internet- Drafts
is at
http://datatracker.ietf.org/drafts/current/. Internet-Drafts
are
draft documents valid for a maximum of six months and
may be
updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use
Internet-Drafts as
reference material
or to
cite them other than as "work in progress." This
Internet-Draft
will expire on February 16, 2015. Copyright Notice Copyright
(c)
2014 IETF Trust and the persons identified as the document
authors. All rights
reserved. Dukhovni
Expires February 16, 2015
[Page 1] Internet-Draft
Opportunistic Security
August 2014 This
document is
subject to BCP 78 and the IETF Trust's Legal Provisions
Relating
to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the
date of publication
of
this document. Please
review these
documents carefully,
as
they describe your rights and restrictions with respect to
this
document. Table of Contents 1. Introduction
. . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . .
. . . . . . . .
. . . . . . . . 4 3. The Opportunistic Security
Design Pattern . .
. . . . . . . . 5 4. Opportunistic Security Design
Principles . . . . . . . .
. . 7 5. Example: Opportunistic TLS in
SMTP . . . . . . . . . . .
. . 8 6. Security Considerations . . .
. . . . . . . .
. . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . .
. . . . . .
. 9 8. References
. . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . .
. . . 9 8.2. Informative References . . . . . . . . . . . . . . .
. . 10 Author's
Address . . . . . . . . .
. . . . . . .
. . . . . . . . 10 1. Introduction The
development
of Opportunistic Crypto-Security (OCS) is motivated by
the concerns
raised in [RFC7258]. Pervasive monitoring (as defined in
that RFC) is
feasible because of the lack of widespread use of encryption
for
confidentiality. Although the IETF has developed many security
protocols
(e.g., TLS, IPsec, SSH, …) that employ encryption for
confidentiality,
most of them also require one-way or two-way authentication. Authentication
is mandated by
the protocols to protect against
active
attacks. If communicating peers are unable to meet the authentication
requirements
imposed by these protocols, the result may be
no
communication, or plaintext communication. 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 criteria. The Public Key Infrastructure
(PKI)
model employed by browsers to authenticate web servers
(often
called the "Web PKI" [cite]) imposes cost and management burdens
that
have limited its use. 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, e.g., SSH [cite]
work well
in enterprise environments, but were not designed to scale
for
Internet-wide use. DNS-Based Authentication of
Named Entities
(DANE [RFC6698]) defines a way
to
distribute public keys bound to DNS names. It can provide an alterative
to the
Web PKI (for other than EV certificates [cite]). DANE
should be used
in conjunction with DNSSEC [RFC4033]. At time, DNSSEC
is not
sufficiently widely deployed to allow DANE to satisfy the Internet-wide,
any-to-any
authentication criteria noted above. Thus protocols
that
mandate authenticated communication cannot generally do
so via DANE
(at time). Internet-Draft
Opportunistic Security August 2014 OCS
provides a
near-term approach to removing barriers to widespread use
of
encryption, while offering a path to authenticated, encrypted communication
in
the future. The primary goal of OCS is to counter attacks,
consistent
with the goals established in [RFC7258]. However, OCS
does not
preclude offering protection against active attacks, if suitable
authentication
capabilities are available. OCS is not intended as
a substitute
for authenticated, encrypted communication when such communication is already
available to peers,
e.g., based on TLS, IPsec, SSH,
etc. To
achieve widespread
adoption, OCS must support incremental deployment. Incremental
deployment
implies that security capabilities will vary from
peer to
peer, perhaps for a very long time. Thus use of an OCS protocol
by one peer may yield
communication that is unauthenticated
but
encrypted,
authenticated and encrypted, or plaintext. This last outcome
will occur if not all
parties to a
communication support OCS (or
if an active
attack makes it appear that this is the case). OCS protocols will attempt to establish
authenticated,
encrypted communication
whenever
both parties are capable of such, but will fallback
to
unauthenticated encrypted communication if authentication is
not possible.
Fallback to plaintext communication will occur as noted
above. OCS
protocols do
not prohibit the use of local security policies. A security
administrator
may specify security policies that override opportunistic security. For
example, a policy might
require authenticated, encrypted communication, in
contrast to the
default OCS security policy. The remainder of this
document provides
definitions of critical terms, enumerates
the OCS design
principles/guidelines, and provides an example of
an OSC
design, in the context of communication between mail relays. 2. Terminology Perfect
Forward
Secrecy (PFS): As defined
in [RFC4949].
Man-in-the-Middle (MiTM) attack:
As defined in [RFC4949]. Trust
on First
Use (TOFU): In a protocol,
TOFU calls
for accepting and
storing a
public key/credential associated with an asserted identity,
without
authenticating that assertion. Subsequent communication
that
is authenticated 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, [RFC4949])
is
sometimes used as a synonym. [note that this is still not quite correct.
In an
enterprise environment it is common for the enterprise to provide an
out-of-band
means of verifying the One-way
and
Two-way Authentication <fill in> Dukhovni
Expires February 16, 2015
[Page 3] Internet-Draft
Opportunistic Security August 2014 3. Opportunistic Crypto-Security Design
Principles As
noted in
Section 1, OCS aims to remove barriers to the widespread
use
of encryption on the Internet. A secondary goal is protection
against
active attacks, by enabling incremental deployment
of
authenticated, encrypted communication. OCS seeks to
achieve the best
protection possible, based on the capabilities of
communicating
peers. 1. Determine
Peer
Security Capabilities: An OCS 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. (Inband determination implies negotiation between peers.
Out-of-band
mechanism include the use of
DANE
records or cached
keys/credentials
acquired via TOFU.) The capability phase determination may indicate that
the peer supports
authenticated, encrypted
communication,
unauthenticated encrypted communication, or
only
plaintext communication. (Note that use of out-of-band capability
determine,
e.g., DANE or TOFU, is downgrade resistant, and
thus
preferred over in-band negotiation techniques. The goal of
this
design principle is to maximize the offered security services
on
a pairwise, peer basis. 2. Apply
Security
Policy: Having determined peer security capabilities, an
OCS protocol
next applies any local security polices in addition to
the default OCS
policy (see below). Local policies may 3. Employ
Perfect
Forward Secrecy: OCS
protocols SHOULD
employ PFS to protect previously recorded
encrypted communication
from 4.
No
misrepresentation of security:
Unauthenticated encrypted communication
must
not be misrepresented to users (or in logs) of non-interactive
applications as
equivalent to communication
over
an authenticated encrypted channel. This principle is
consistent
with the goal of not encouraging use of OCS in lieu of protocols
that
offer additional security services, when such protocols can
be
employed successfully. Dukhovni
Expires February 16, 2015
[Page 4] Internet-Draft
Opportunistic Security
August 2014 4. Example:
Opportunistic
TLS in SMTP Many
Message
Transfer Agents (MTAs, [RFC5598]) support the STARTTLS ([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
the
use of STARTTLS for
SMTP
protects only against passive attacks. MTAs that implement STARTTLS
establish either
an authenticated, encrypted
session
or deliver messages over a plaintext channel. Recent
reports [cite?]
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. The
STARTTLS
advertisement is vulnerable to active attacks and some MTAs that advertise
STARTTLS exhibit
various interoperability problems
in
their implementations. As
a result, it is
common for a pair
of
STARTTLS-enabled MTAs to fall back to plaintext communication
when
the TLS handshake fails, or when TLS fails during message
transmission. This is a
reasonable
trade-off, consistent with OCS
principles, since
STARTTLS protects against only passive attacks;
absent
an active attack TLS failures are simply interoperability
problems. Some MTAs employing STARTTLS
abandon the TLS
handshake when the peer
MTA fails
authentication, only to immediately deliver the
same message
over a plaintext connection. Other
MTAs
have been observed
to
tolerate unverified self-signed certificates, but not expired
certificates,
again falling back to plaintext.
These and similar
behaviors
are NOT consistent with OCS principles, since they
revert to
plaintext communication when authentication fails, instead
of
employing unauthenticated, encryption, communication. Protection
against
active attacks for SMTP is described in
[I-D.ietf-dane-smtp-with-dane].
That draft introduces the terms
"Opportunistic TLS" and "Opportunistic DANE TLS";
this draft is consistent
with
the OCS design principles defined in this document. Dukhovni
Expires February 16, 2015
[Page 5] Internet-Draft
Opportunistic Security
August 2014 6. Security
Considerations OCS supports communication
that is
authenticated and encrypted, unauthenticated
and
encrypted, or plaintext. The security services offered
to
communicating peers is not reduced by the use of OCS. This
is because
the default OCS policy employs the best security services
available
based on the capabilities of the peers, and because
local
security policies take precedence over the default OCS
policy. OCS
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) OCS
coexists
with and is preempted by local, non-OCS security polices. Non-OCS policies may inhibit
use of
encryption when many peers cannot offer
authenticated,
encrypted communication. Unless authenticated, encrypted
communication
is necessary, non-OCS local policies of this sort
run counter
to the goals established in [RFC7258]. 7.
Acknowledgements 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, Scott Kitterman, Martin Thomson,
Nico
Williams, Paul Wouters and Stephen Farrell for their helpful
suggestions
and support. 8. References 8.1. Normative
References [RFC3207] Hoffman, P., "SMTP Service
Extension for
Secure SMTP over
Transport Layer Security", RFC 3207, February 2002. [RFC4033] Arends, R., Austein, R.,
Larson, M., Massey,
D., and S.
Rose,
"DNS Security Introduction and Requirements", RFC
4033,
March 2005. [RFC5116] McGrew, D., "An Interface and
Algorithms
for Authenticated
Encryption", RFC 5116, January 2008. [RFC5246] Dierks, T. and E. Rescorla,
"The
Transport Layer Security
(TLS)
Protocol Version 1.2", RFC 5246, August 2008. [RFC6125] Saint-Andre, P. and J.
Hodges,
"Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011. Dukhovni
Expires February 16, 2015
[Page 6] Internet-Draft
Opportunistic Security
August 2014 [RFC6698] Hoffman, P. and J. Schlyter,
"The
DNS-Based Authentication
of
Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, August 2012. 8.2. Informative
References
[I-D.ietf-dane-smtp-with-dane]
Dukhovni, V. and W. Hardaker, "SMTP security via
opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-11
(work
in progress), August 2014. [RFC4949] Shirey, R., "Internet
Security Glossary,
Version 2", RFC
4949,
August 2007. [RFC5598] Crocker, D., "Internet Mail
Architecture", RFC 5598, July
2009. [RFC7258] Farrell, S. and H.
Tschofenig,
"Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, May 2014. Author's Address Viktor
Dukhovni Two
Sigma Email:
ietf-dane@xxxxxxxxxxxx Dukhovni
Expires February 16, 2015
[Page 7] |