Internet DRAFT - draft-hoffman-uta-opportunistic-tls
draft-hoffman-uta-opportunistic-tls
Network Working Group P. Hoffman
Internet-Draft VPN Consortium
Intended status: Standards Track February 2, 2014
Expires: August 6, 2014
Opportunistic Encryption Using TLS
draft-hoffman-uta-opportunistic-tls-00
Abstract
This document defines the term "opportunistic encryption using TLS"
as it applies to application protocols that use TLS.
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 August 6, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
1. Introduction
Hoffman Expires August 6, 2014 [Page 1]
Internet-Draft Opportunistic TLS February 2014
The term "opportunistic encryption" has many informal definitions,
and this panoply of definitions has made discussion of using
opportunistic encryption in particular protocols more difficult. The
term has acquired many different meanings in different contexts, so
having a single definition that can be used by protocol
specifications and application developers will benefit the Internet
community.
Opportunistic encryption using TLS is considered a good way to
prevent passive monitoring of communications that would otherwise be
sent unencrypted. It is clear that such monitoring is fairly
pervasive in many Internet environments, and it is also clear that
many people would like prevent their communications from being
watched by governments, companies, groups, and individuals whom they
do not know. Opportunistic encryption using TLS causes the start of
application communication to happen later than it normally would have
due to the round trips and mathematical computations required to
establish a TLS session. The creators of an application program must
weigh these and other factors when deciding whether or not to use
opportunistic encryption in their program. Similarly, protocol
designers need to take these and other factors into account when
deciding whether or not to require, suggest, or even allow
opportunistic encryption using TLS in their protocol specifications.
The definition of opportunistic encryption using TLS in this document
explicitly sets user interface requirements for applications.
Although this is rarely done in other IETF standards, doing so is
required here for security reasons.
Note that "opportunistic encryption using TLS" is different than
"unauthenticated TLS". The latter describes a similar but distinct
concept, and it applies to different scenarios. There is a wide
industry agreement that unauthenticated TLS is almost always a bad
practice. The two terms are often confused, and thus
"unauthenticated TLS" is described only in an appendix of this
document.
This document applies to all versions of TLS, including TLS 1.2
[RFC5246], TLS 1.1 [RFC4346], and TLS 1.0 [RFC2246]. It may or may
not apply to future versions of TLS. The definition of
"opportunistic encryption using TLS" in this document applies to any
protocol that can be protected with TLS; this means that it mostly
applies to layer 7 protocols, also known as "application layer
protocols". This document only defines opportunistic encryption
using TLS; it does not describe opportunistic encryption with other
encrypting protocols such as IPsec.
Hoffman Expires August 6, 2014 [Page 2]
Internet-Draft Opportunistic TLS February 2014
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119, BCP 14
[RFC2119].
2. Definition of 'Opportunistic Encryption Using TLS'
An application supports opportunistic encryption using TLS if the
application attempts to perform TLS negotiation without the user who
is running the application knowing whether or not TLS is in use. The
application MUST NOT have any user-visible configuration that enables
opportunistic encryption using TLS. Stated another way, it is
impossible for a program to have a configuration option for
opportunistic encryption: having such an option inherently is not for
opportunistic encryption.
When an application that supports opportunistic encryption negotiates
TLS, that application might or might not authenticate the TLS server.
It is expected that the common case is that applications that
supports opportunistic encryption will not authenticate the TLS
servers they connect to. However, it is acceptable for an
application that supports opportunistic encryption to only complete
the TLS negotiation if the TLS server can be validated.
When an application that is doing opportunistic encryption
successfully creates a TLS session, that application MUST NOT show
the user any indication that TLS is in use.
An application that does opportunistic encryption using TLS finds the
appropriate TLS server using one or more of many mechanisms, none of
which are described here in detail. Some of those mechanisms include
in-protocol upgrade to TLS, in-protocol pointers to TLS servers, DNS
queries whose responses indicate the presence of appropriate TLS
servers, and simply trying a TCP port on which TLS is expected.
3. IANA Considerations
None
4. Security Considerations
Opportunistic encryption using TLS prevents observation by passive
attackers on the network. However, it doesn't completely prevent the
attacker from knowing anything about the contents of the encrypted
information. For example, the attacker can know what protocol is
being encrypted, the approximate size of the encrypted messages, and
Hoffman Expires August 6, 2014 [Page 3]
Internet-Draft Opportunistic TLS February 2014
so on. The attacker can also learn about the cryptographic
capabilities of the client and server by observing the TLS handshake.
The purpose for the requirement that the application not have any
user-visible configuration that enables opportunistic encryption is
that having user-visible configuration is likely to cause lower
security for the Internet. A widely-used setting that says "use TLS
even when it is not called for" would cause server operators to
become more lax with their TLS deployments, such as not bothering to
renew (or even get) widely-accepted certificates for their sites
because they know that most applications could reach them with TLS
anyway.
The purpose for the requirement that the application not show that
TLS is in use if the TLS was established with opportunistic
encryption is that such an indication is likely to cause lower
security for the Internet, particularly in web browsers.
5. References
5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
5.2. Informative References
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
Appendix A. Unauthenticated TLS
The term "unauthenticated encryption", when used in the context of
TLS, is fairly straight-forward. However, in discussions on many
security and protocol mailing lists, it is often confused with
"opportunistic encryption using TLS".
Unauthenticated encryption for TLS is the act of setting up a TLS
session at the request of a user where the TLS client does not
authenticate the TLS server.
Hoffman Expires August 6, 2014 [Page 4]
Internet-Draft Opportunistic TLS February 2014
When the TLS session is being set up at the request of the user, such
as when the user enters a URL that should only be resolved with TLS,
using unauthenticated TLS is rarely the expected or desired result.
In such a situation, the application might allow unauthenticated TLS
after giving the user some warning, or the application might even
have a configuration setting that tells the application to allow
unauthenticated TLS even when trying to set up an explicit TLS
session.
Many security-conscious protocol developers are severely critical of
applications that allow unauthenticated encryption with TLS, even if
the application gives the user warnings when authentication failed.
Similarly, many security-conscious protocol developers are severely
critical of applications that allow unauthenticated encryption to be
configured at all.
Note that "opportunistic encryption using TLS" may allow the TLS
session to be set up without the client authenticating the server.
This is a completely different scenario than "unauthenticated
encryption" using TLS. The definition of opportunistic encryption
with TLS precludes the TLS session being set up at the request of the
user; the definition of unauthenticated encryption with TLS requires
that the TLS session is being set up at the request of the user.
Author's Address
Paul Hoffman
VPN Consortium
Email: paul.hoffman@vpnc.org
Hoffman Expires August 6, 2014 [Page 5]
