idnits 2.17.1 draft-dukhovni-opportunistic-security-01.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 (July 6, 2014) is 3579 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 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 July 6, 2014 5 Expires: January 7, 2015 7 Opportunistic Security: some protection most of the time 8 draft-dukhovni-opportunistic-security-01 10 Abstract 12 This memo defines the term "opportunistic security". In contrast to 13 the established approach of delivering strong protection some of the 14 time, opportunistic security strives to deliver at least some 15 protection most of the time. The primary goal is therefore broad 16 interoperability, with security policy tailored to the capabilities 17 of peer systems. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 7, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Opportunistic Security Design Philosophy . . . . . . . . . . 3 52 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 54 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 55 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 58 1. Introduction 60 Historically, Internet security protocols have prioritized strong 61 protection for peers capable and motivated to absorb the associated 62 costs. Since strong protection is not universally applicable, while 63 communications traffic was sometimes strongly secured, more typically 64 it was not protected at all. The fact that most traffic is 65 unprotected facilitates nation-state pervasive monitoring (PM 66 [RFC7258]) by making it cost-effective (or at least not cost- 67 prohibitive). Indiscriminate collection of communications traffic 68 would be substantially less attractive if security protocols were 69 designed to operate at a range of protection levels with encrypted 70 transmission accessible to most if not all peers, and stronger 71 security still available where required by policy or 72 opportunistically negotiated. 74 Encryption is easy, but key management is difficult. Key management 75 at Internet scale remains an incompletely solved problem. The PKIX 76 ([RFC5280]) key management model introduces costs that not all peers 77 are willing to bear and is also not sufficient to secure 78 communications when the peer reference identity is obtained 79 indirectly over an insecure channel or communicating parties don't 80 agree on a mutually trusted certification authority (CA). DNSSEC is 81 not at this time sufficiently widely adopted to make DANE a viable 82 alternative at scale. Trust on first use (TOFU) key management 83 models (as with saved SSH fingerprints and various certificate 84 pinning approaches) don't protect initial contact and require user 85 intervention when key continuity fails. 87 Without Internet-scale key management, authentication is often not 88 possible. When protocols only offer the options of strongly- 89 authenticated secure channels or else no security, most traffic gets 90 no security protection. Therefore, in order to make encryption more 91 ubiquitous, authentication needs to be optional. When strongly 92 authenticated communication is not possible, unauthenticated 93 encryption is still substantially stronger than cleartext. 94 Opportunistic security encourages peers to employ as much security as 95 possible, without falling back to unnecessarily weak options. In 96 particular, opportunistic security encourages unauthenticated 97 encryption when authentication is not an option. 99 2. Opportunistic Security Design Philosophy 101 Interoperate to maximize deployment: The primary goal of designs 102 that feature opportunistic security is to be able to communicate 103 with any reasonably configured peer. If many peers are only 104 capable of cleartext, then it is acceptable to fall back to 105 cleartext when encryption is not possible. If authentication is 106 only possible for some peers, then it is acceptable to 107 authenticate only those peers and not the rest. Interoperability 108 must be possible without bilateral coordination. Applications 109 employing opportunistic security need to be deployable at Internet 110 scale, with each peer independently configured to meet its own 111 security needs (within the practical bounds of the application 112 protocol). Opportunistic security must not get in the way of the 113 peers communicating if neither end is misconfigured. 115 Maximize security peer by peer: Subject to the above large-scale 116 interoperability goal, opportunistic security strives to maximize 117 security based on the capabilities of the peer (or peers). For 118 some opportunistic security protocols the maximal protection 119 possible may be just unauthenticated encryption. For others, 120 greater security may be an option, and opportunistic security may 121 at times (in partial conflict with the interoperability goal) 122 refuse to continue with peers where higher security is expected, 123 but for some reason not achieved. The conditions under which 124 connections fail should generally be limited to operational errors 125 at one or the other peer or an active attack, so that well- 126 maintained systems rarely encounter problems in normal use of 127 opportunistic security. 129 Encrypt by default: An opportunistic security protocol MUST 130 interoperably achieve at least unauthenticated encryption between 131 peer systems that don't explicitly disable this capability. Over 132 time, as peer software is updated to support opportunistic 133 security, only legacy systems or a minority of systems where 134 encryption is disabled should be communicating in cleartext. 135 Whenever possible, opportunistic security should employ Perfect 136 Forward Secrecy (PFS) to make recovery of previously sent keys and 137 plaintext computationally expensive even after disclosure of long- 138 term keys. 140 No misrepresentation of security: Unauthenticated communication or 141 use of authentication that is vulnerable to MiTM attacks is not 142 represented as strong security. Where strong security is 143 required, opportunistic security is not a substitute, though the 144 underlying mechanisms may in some cases be very similar. 146 In summary, opportunistic security is an umbrella term that 147 encompasses protocol designs that remove barriers to the widespread 148 use of encryption in the Internet. The actual protection provided by 149 opportunistic security depends on the capabilities of the 150 communicating peers; opportunistic security MUST attempt to at least 151 encrypt network traffic, while allowing fallback to cleartext with 152 peers that do not appear to be encryption capable. 154 It is important to note that opportunistic security is not limited to 155 unauthenticated encryption. When possible, opportunistic security 156 SHOULD provide stronger security on a peer-by-peer basis. For 157 example, some peers may be authenticated via DANE, TOFU or other 158 means. Though authentication failure MAY be a reason to abort a 159 connection to a peer that is expected to be authenticated, it MUST 160 NOT instead lead to communication in cleartext when encryption is an 161 option. Some sending MTAs employing STARTTLS have been observed to 162 abort TLS transmission when the receiving MTA fails authentication, 163 only to immediately deliver the same message over a cleartext 164 connection. This design blunder MUST be avoided. 166 3. Terminology 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 170 "OPTIONAL" in this document are to be interpreted as described in 171 [RFC2119]. 173 The following definitions are derived from the Internet Security 174 Glossary [RFC4949], where applicable. 176 Perfect Forward Secrecy (PFS): For a key management protocol, the 177 property that compromise of long-term keys does not compromise 178 session/traffic/content keys that are derived from or distributed 179 using the long-term keys. 181 Man-in-the-Middle attack (MiTM): A form of active wiretapping attack 182 in which an attacker intercepts and may selectively modify 183 communicated data to masquerade as one of the entities involved in 184 a communication. Masquerading enables the MiTM to violate the 185 confidentiality and/or the integrity of communicated data passing 186 through it. 188 Trust on First Use (TOFU): In a protocol, TOFU typically consists of 189 accepting an asserted identity, without authenticating that 190 assertion, and caching a key or credential associated with the 191 identity. Subsequent communication using the cached key/ 192 credential is secure against a MiTM attack, if such an attack did 193 not succeed during the (vulnerable) initial communication or if 194 the MiTM is not present for all subsequent communications. The 195 SSH protocol makes use of TOFU. The phrase "leap of faith" (LoF) 196 is sometimes used as a synonym. 198 Unauthenticated Encryption: Encryption using a key management 199 technique that enables unauthenticated communication between 200 parties. The communication may be 1-way or 2-way unauthenticated. 201 If 1-way, the initiator (client) or the target (server) may be 202 anonymous. 204 4. Security Considerations 206 Though opportunistic security potentially supports transmission in 207 cleartext, unauthenticated encryption, or other protection levels 208 short of the strongest potentially applicable, the effective security 209 for users is increased, not reduced. Provided strong security is not 210 required by policy or securely negotiated, nothing is lost by 211 allowing weaker protection levels, indeed opportunistic security is 212 strictly stronger than the alternative of providing no security 213 services when maximal security is not applicable. 215 5. Acknowledgements 217 I would like to thank Steve Kent. Some of the text in this document 218 is based on his earlier draft. 220 6. References 222 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 223 Requirement Levels", BCP 14, RFC 2119, March 1997. 225 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 226 4949, August 2007. 228 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 229 Housley, R., and W. Polk, "Internet X.509 Public Key 230 Infrastructure Certificate and Certificate Revocation List 231 (CRL) Profile", RFC 5280, May 2008. 233 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 234 Attack", BCP 188, RFC 7258, May 2014. 236 Author's Address 238 Viktor Dukhovni 239 Two Sigma 241 Email: ietf-dane@dukhovni.org