idnits 2.17.1 draft-hoffman-uta-opportunistic-tls-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 2, 2014) is 3737 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft VPN Consortium 4 Intended status: Standards Track February 2, 2014 5 Expires: August 6, 2014 7 Opportunistic Encryption Using TLS 8 draft-hoffman-uta-opportunistic-tls-00 10 Abstract 12 This document defines the term "opportunistic encryption using TLS" 13 as it applies to application protocols that use TLS. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on August 6, 2014. 32 Copyright Notice 34 Copyright (c) 2014 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 1. Introduction 48 The term "opportunistic encryption" has many informal definitions, 49 and this panoply of definitions has made discussion of using 50 opportunistic encryption in particular protocols more difficult. The 51 term has acquired many different meanings in different contexts, so 52 having a single definition that can be used by protocol 53 specifications and application developers will benefit the Internet 54 community. 56 Opportunistic encryption using TLS is considered a good way to 57 prevent passive monitoring of communications that would otherwise be 58 sent unencrypted. It is clear that such monitoring is fairly 59 pervasive in many Internet environments, and it is also clear that 60 many people would like prevent their communications from being 61 watched by governments, companies, groups, and individuals whom they 62 do not know. Opportunistic encryption using TLS causes the start of 63 application communication to happen later than it normally would have 64 due to the round trips and mathematical computations required to 65 establish a TLS session. The creators of an application program must 66 weigh these and other factors when deciding whether or not to use 67 opportunistic encryption in their program. Similarly, protocol 68 designers need to take these and other factors into account when 69 deciding whether or not to require, suggest, or even allow 70 opportunistic encryption using TLS in their protocol specifications. 72 The definition of opportunistic encryption using TLS in this document 73 explicitly sets user interface requirements for applications. 74 Although this is rarely done in other IETF standards, doing so is 75 required here for security reasons. 77 Note that "opportunistic encryption using TLS" is different than 78 "unauthenticated TLS". The latter describes a similar but distinct 79 concept, and it applies to different scenarios. There is a wide 80 industry agreement that unauthenticated TLS is almost always a bad 81 practice. The two terms are often confused, and thus 82 "unauthenticated TLS" is described only in an appendix of this 83 document. 85 This document applies to all versions of TLS, including TLS 1.2 86 [RFC5246], TLS 1.1 [RFC4346], and TLS 1.0 [RFC2246]. It may or may 87 not apply to future versions of TLS. The definition of 88 "opportunistic encryption using TLS" in this document applies to any 89 protocol that can be protected with TLS; this means that it mostly 90 applies to layer 7 protocols, also known as "application layer 91 protocols". This document only defines opportunistic encryption 92 using TLS; it does not describe opportunistic encryption with other 93 encrypting protocols such as IPsec. 95 1.1. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119, BCP 14 100 [RFC2119]. 102 2. Definition of 'Opportunistic Encryption Using TLS' 104 An application supports opportunistic encryption using TLS if the 105 application attempts to perform TLS negotiation without the user who 106 is running the application knowing whether or not TLS is in use. The 107 application MUST NOT have any user-visible configuration that enables 108 opportunistic encryption using TLS. Stated another way, it is 109 impossible for a program to have a configuration option for 110 opportunistic encryption: having such an option inherently is not for 111 opportunistic encryption. 113 When an application that supports opportunistic encryption negotiates 114 TLS, that application might or might not authenticate the TLS server. 115 It is expected that the common case is that applications that 116 supports opportunistic encryption will not authenticate the TLS 117 servers they connect to. However, it is acceptable for an 118 application that supports opportunistic encryption to only complete 119 the TLS negotiation if the TLS server can be validated. 121 When an application that is doing opportunistic encryption 122 successfully creates a TLS session, that application MUST NOT show 123 the user any indication that TLS is in use. 125 An application that does opportunistic encryption using TLS finds the 126 appropriate TLS server using one or more of many mechanisms, none of 127 which are described here in detail. Some of those mechanisms include 128 in-protocol upgrade to TLS, in-protocol pointers to TLS servers, DNS 129 queries whose responses indicate the presence of appropriate TLS 130 servers, and simply trying a TCP port on which TLS is expected. 132 3. IANA Considerations 134 None 136 4. Security Considerations 138 Opportunistic encryption using TLS prevents observation by passive 139 attackers on the network. However, it doesn't completely prevent the 140 attacker from knowing anything about the contents of the encrypted 141 information. For example, the attacker can know what protocol is 142 being encrypted, the approximate size of the encrypted messages, and 143 so on. The attacker can also learn about the cryptographic 144 capabilities of the client and server by observing the TLS handshake. 146 The purpose for the requirement that the application not have any 147 user-visible configuration that enables opportunistic encryption is 148 that having user-visible configuration is likely to cause lower 149 security for the Internet. A widely-used setting that says "use TLS 150 even when it is not called for" would cause server operators to 151 become more lax with their TLS deployments, such as not bothering to 152 renew (or even get) widely-accepted certificates for their sites 153 because they know that most applications could reach them with TLS 154 anyway. 156 The purpose for the requirement that the application not show that 157 TLS is in use if the TLS was established with opportunistic 158 encryption is that such an indication is likely to cause lower 159 security for the Internet, particularly in web browsers. 161 5. References 163 5.1. Normative References 165 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 166 Requirement Levels", March 1997. 168 5.2. Informative References 170 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 171 RFC 2246, January 1999. 173 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 174 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 176 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 177 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 179 Appendix A. Unauthenticated TLS 181 The term "unauthenticated encryption", when used in the context of 182 TLS, is fairly straight-forward. However, in discussions on many 183 security and protocol mailing lists, it is often confused with 184 "opportunistic encryption using TLS". 186 Unauthenticated encryption for TLS is the act of setting up a TLS 187 session at the request of a user where the TLS client does not 188 authenticate the TLS server. 190 When the TLS session is being set up at the request of the user, such 191 as when the user enters a URL that should only be resolved with TLS, 192 using unauthenticated TLS is rarely the expected or desired result. 193 In such a situation, the application might allow unauthenticated TLS 194 after giving the user some warning, or the application might even 195 have a configuration setting that tells the application to allow 196 unauthenticated TLS even when trying to set up an explicit TLS 197 session. 199 Many security-conscious protocol developers are severely critical of 200 applications that allow unauthenticated encryption with TLS, even if 201 the application gives the user warnings when authentication failed. 202 Similarly, many security-conscious protocol developers are severely 203 critical of applications that allow unauthenticated encryption to be 204 configured at all. 206 Note that "opportunistic encryption using TLS" may allow the TLS 207 session to be set up without the client authenticating the server. 208 This is a completely different scenario than "unauthenticated 209 encryption" using TLS. The definition of opportunistic encryption 210 with TLS precludes the TLS session being set up at the request of the 211 user; the definition of unauthenticated encryption with TLS requires 212 that the TLS session is being set up at the request of the user. 214 Author's Address 216 Paul Hoffman 217 VPN Consortium 219 Email: paul.hoffman@vpnc.org