idnits 2.17.1 draft-dukhovni-opportunistic-security-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 3, 2014) is 3525 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Dukhovni 3 Internet-Draft Two Sigma 4 Intended status: Informational August 3, 2014 5 Expires: February 4, 2015 7 Opportunistic Security: some protection most of the time 8 draft-dukhovni-opportunistic-security-02 10 Abstract 12 This memo defines the term "opportunistic security". In contrast to 13 the established approach of employing protection against both passive 14 and active attacks or else (frequently) no protection at all, 15 opportunistic security strives to deliver at least some protection 16 most of the time. The primary goal is therefore broad 17 interoperability, with security policy tailored to the capabilities 18 of peer systems. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on February 4, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Opportunistic Security Design Philosophy . . . . . . . . . . 3 54 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 55 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 56 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 59 1. Introduction 61 Historically, Internet security protocols have prioritized 62 comprehensive protection against both passive and active attacks for 63 peers capable and motivated to absorb the associated costs. Since 64 protection against active attacks relies on authentication, which at 65 Internet scale is not universally available, while communications 66 traffic was sometimes strongly protected, more typically it was not 67 protected at all. The fact that most traffic is unprotected 68 facilitates nation-state pervasive monitoring (PM [RFC7258]) by 69 making it cost-effective (or at least not cost-prohibitive). 70 Indiscriminate collection of communications traffic would be 71 substantially less attractive if security protocols were designed to 72 operate at a range of protection levels; with encrypted transmission 73 accessible to most if not all peers, and protection against active 74 attacks still available where required by policy or opportunistically 75 negotiated. 77 Encryption is easy, but key management is difficult. Key management 78 at Internet scale remains an incompletely solved problem. The PKIX 79 ([RFC5280]) key management model, which is based on broadly trusted 80 public certification authorities (CAs), introduces costs that not all 81 peers are willing to bear. PKIX is not sufficient to secure 82 communications when the peer reference identity ([RFC6125]) is 83 obtained indirectly over an insecure channel or communicating parties 84 don't agree on a mutually trusted CA. DNSSEC ([RFC4033]) is not at 85 this time sufficiently widely adopted to make DANE ([RFC6698]) a 86 viable alternative at scale. Trust on first use (TOFU) key 87 management models (as with saved SSH fingerprints and various 88 certificate pinning approaches) don't protect initial contact and 89 require user intervention when key continuity fails. 91 Without Internet-scale key management, authentication required for 92 protection against active attacks is often not possible. When 93 protocols only offer the options of authenticated secure channels or 94 else cleartext, most traffic is sent in the clear. Therefore, in 95 order to make encryption more ubiquitous, authentication needs to be 96 optional. When authenticated communication is not possible, 97 unauthenticated encryption is still substantially stronger than 98 cleartext. Opportunistic security encourages peers to employ as much 99 security as possible, without falling back to unnecessarily weak 100 options. In particular, opportunistic security encourages 101 unauthenticated encryption when authentication is not an option. 103 2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in 108 [RFC2119]. 110 The following definitions are derived from the Internet Security 111 Glossary [RFC4949], where applicable. 113 Perfect Forward Secrecy (PFS): For a key management protocol, the 114 property that compromise of long-term keys does not compromise 115 session/traffic/content keys that are derived from or distributed 116 using the long-term keys. 118 Man-in-the-Middle attack (MiTM): A form of active wiretapping attack 119 in which an attacker intercepts and may selectively modify 120 communicated data to masquerade as one of the entities involved in 121 a communication. Masquerading enables the MiTM to violate the 122 confidentiality and/or the integrity of communicated data passing 123 through it. 125 Trust on First Use (TOFU): In a protocol, TOFU typically consists of 126 accepting an asserted identity, without authenticating that 127 assertion, and caching a key or credential associated with the 128 identity. Subsequent communication using the cached key/ 129 credential is secure against a MiTM attack, if such an attack did 130 not succeed during the (vulnerable) initial communication or if 131 the MiTM is not present for all subsequent communications. The 132 SSH protocol makes use of TOFU. The phrase "leap of faith" (LoF) 133 is sometimes used as a synonym. 135 Unauthenticated Encryption: Encryption using a key management 136 technique that enables unauthenticated communication between 137 parties. The communication may be 1-way or 2-way unauthenticated. 138 If 1-way, the initiator (client) or the target (server) may be 139 anonymous. 141 3. Opportunistic Security Design Philosophy 143 Interoperate to maximize deployment: The primary goal of designs 144 that feature opportunistic security is to be able to communicate 145 with any reasonably configured peer. If many peers are only 146 capable of cleartext, then it is acceptable to fall back to 147 cleartext when encryption is not possible. If authentication is 148 only possible for some peers, then it is acceptable to 149 authenticate only those peers and not the rest. Interoperability 150 must be possible without a need for the administrators of 151 communicating systems to coordinate security settings. 152 Applications employing opportunistic security need to be 153 deployable at Internet scale, with each peer independently 154 configured to meet its own security needs (within the practical 155 bounds of the application protocol). Opportunistic security must 156 not get in the way of the peers communicating if neither end is 157 misconfigured. 159 Maximize security peer by peer: Subject to the above Internet-scale 160 interoperability goal, opportunistic security strives to maximize 161 security based on the capabilities of the peer (or peers). For 162 some opportunistic security protocols the maximal protection 163 possible may be just unauthenticated encryption to address passive 164 monitoring. For others, protection against active MiTM attacks 165 may be an option. Opportunistic security protocols may at times 166 refuse to operate with peers for which higher security is 167 expected, but for some reason not achieved. The conditions under 168 which connections fail should generally be limited to operational 169 errors at one or the other peer or an active attack, so that well- 170 maintained systems rarely encounter problems in normal use of 171 opportunistic security. 173 Encrypt by default: An opportunistic security protocol MUST 174 interoperably achieve at least unauthenticated encryption between 175 peer systems that don't explicitly disable this capability. To 176 facilitate incremental deployment, opportuistic security protocols 177 may tolerate cleartext connections or sessions with peers that 178 don't support encryption. Over time, as peer software is updated 179 to support opportunistic security, only legacy systems or a 180 minority of systems where encryption is disabled should be 181 communicating in cleartext. Whenever possible, opportunistic 182 security should employ Perfect Forward Secrecy (PFS) to make 183 recovery of previously sent keys and plaintext computationally 184 expensive even after disclosure of long-term keys. 186 No misrepresentation of security: Unauthenticated communication or 187 use of authentication that is vulnerable to MiTM attacks is not 188 represented as strong security. Where protection against active 189 attacks is required, unauthenticated opportunistic security is not 190 a substitute. 192 In summary, opportunistic security is an umbrella term that 193 encompasses protocol designs that remove barriers to the widespread 194 use of encryption in the Internet. The actual protection provided by 195 opportunistic security depends on the capabilities of the 196 communicating peers; opportunistic security MUST attempt to at least 197 encrypt network traffic, while allowing fallback to cleartext with 198 peers that do not appear to be encryption capable. 200 It is important to note that opportunistic security is not limited to 201 unauthenticated encryption. When possible, opportunistic security 202 SHOULD provide stronger security on a peer-by-peer basis. For 203 example, some peers may be authenticated via DANE, TOFU or other 204 means. Though authentication failure MAY be a reason to abort a 205 connection to a peer that is expected to be authenticated, it MUST 206 NOT instead lead to communication in cleartext when encryption is an 207 option. Some Message Transfer Agents (MTAs, [RFC5598] Section 4.3.2) 208 employing STARTTLS ([RFC3207]) have been observed to abort TLS 209 ([RFC5246]) transmission when the receiving MTA fails authentication, 210 only to immediately deliver the same message over a cleartext 211 connection. This design blunder MUST be avoided. 213 4. Security Considerations 215 Though opportunistic security potentially supports transmission in 216 cleartext, unauthenticated encryption, or other protection levels 217 short of the strongest potentially applicable, the effective security 218 for users is increased, not reduced. Provided strong security is not 219 required by policy or securely negotiated, nothing is lost by 220 allowing weaker protection levels, indeed opportunistic security is 221 strictly stronger than the alternative of providing no security 222 services when maximal security is not applicable. 224 5. Acknowledgements 226 I would like to thank Steve Kent. Some of the text in this document 227 is based on his earlier draft. 229 6. References 231 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 232 Requirement Levels", BCP 14, RFC 2119, March 1997. 234 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 235 Transport Layer Security", RFC 3207, February 2002. 237 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 238 Rose, "DNS Security Introduction and Requirements", RFC 239 4033, March 2005. 241 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 242 4949, August 2007. 244 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 245 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 247 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 248 Housley, R., and W. Polk, "Internet X.509 Public Key 249 Infrastructure Certificate and Certificate Revocation List 250 (CRL) Profile", RFC 5280, May 2008. 252 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 253 2009. 255 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 256 Verification of Domain-Based Application Service Identity 257 within Internet Public Key Infrastructure Using X.509 258 (PKIX) Certificates in the Context of Transport Layer 259 Security (TLS)", RFC 6125, March 2011. 261 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 262 of Named Entities (DANE) Transport Layer Security (TLS) 263 Protocol: TLSA", RFC 6698, August 2012. 265 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 266 Attack", BCP 188, RFC 7258, May 2014. 268 Author's Address 270 Viktor Dukhovni 271 Two Sigma 273 Email: ietf-dane@dukhovni.org