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]