idnits 2.17.1 draft-dukhovni-opportunistic-security-05.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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2014) is 3441 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-19) exists of draft-ietf-dane-smtp-with-dane-13 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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 October 27, 2014 5 Expires: April 30, 2015 7 Opportunistic Security: Some Protection Most of the Time 8 draft-dukhovni-opportunistic-security-05 10 Abstract 12 This document defines the concept "Opportunistic Security" in the 13 context of communications protocols. Protocol designs based on 14 Opportunistic Security use encryption even when authentication is not 15 available, and use authentication when possible, thereby removing 16 barriers to the widespread use of encryption on the Internet. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 30, 2015. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.2. A New Perspective . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3. Opportunistic Security Design Principles . . . . . . . . . . 5 54 4. Example: Opportunistic TLS in SMTP . . . . . . . . . . . . . 7 55 5. Operational Considerations . . . . . . . . . . . . . . . . . 8 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 57 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 58 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 60 8.2. Informative References . . . . . . . . . . . . . . . . . 10 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 63 1. Introduction 65 1.1. Background 67 Historically, Internet security protocols have emphasized 68 comprehensive "all or nothing" cryptographic protection against both 69 passive and active attacks. With each peer, such a protocol achieves 70 either full protection or else total failure to communicate (hard 71 fail). As a result, operators often disable these security protocols 72 when users have difficulty connecting, thereby degrading all 73 communications to cleartext transmission. 75 Protection against active attacks requires authentication. The 76 ability to authenticate any potential peer on the Internet requires 77 an authentication mechanism that encompasses all such peers. No IETF 78 standard for authentication scales as needed and has been deployed 79 widely enough to meet this requirement. 81 The Public Key Infrastructure (PKI) model employed by browsers to 82 authenticate web servers (often called the "Web PKI") imposes cost 83 and management burdens that have limited its use. With so many 84 Certification Authorities (CAs), not all of which everyone is willing 85 to trust, the communicating parties don't always agree on a mutually 86 trusted CA. Without a mutually trusted CA, authentication fails, 87 leading to communications failure in protocols that mandate 88 authentication. These issues are compounded by operational 89 difficulties. For example, a common problem is for site operators to 90 forget to perform timely renewal of expiring certificates. In Web 91 PKI interactive applications, security warnings are all too frequent, 92 and end-users learn to actively ignore security problems, or site 93 administrators decide that the maintenance cost is not worth the 94 benefit so they provide a cleartext-only service to their users. 96 The trust-on-first-use (TOFU) authentication approach assumes that an 97 unauthenticated public key obtained on first contact (and retained 98 for future use) will be good enough to secure future communication. 99 TOFU-based protocols do not protect against an attacker who can 100 hijack the first contact communication and require more care from the 101 end-user when systems update their cryptographic keys. TOFU can make 102 it difficult to distinguish routine key management from a malicious 103 attack. 105 DNS-Based Authentication of Named Entities (DANE [RFC6698]) defines a 106 way to distribute public keys bound to DNS names. It can provide an 107 alternative to the Web PKI. DANE needs to be used in conjunction 108 with DNSSEC [RFC4033]. At the time of writing, DNSSEC is not 109 sufficiently widely deployed to allow DANE to authenticate all 110 potential peers. Protocols that mandate authenticated communication 111 cannot yet generally do so via DANE (at the time of writing). 113 The lack of a global key management system means that for many 114 protocols, only a minority of communications sessions can be 115 predictably authenticated. When protocols only offer a choice 116 between authenticated-and-encrypted communication, or no protection, 117 the result is that most traffic is sent in cleartext. The fact that 118 most traffic is not encrypted makes pervasive monitoring easier by 119 making it cost-effective, or at least not cost-prohibitive (see 120 [RFC7258] for more detail). 122 For encryption to be used more broadly, authentication needs to be 123 optional. The use of encryption defends against pervasive monitoring 124 and other passive attacks. Even unauthenticated, encrypted 125 communication (defined below) is preferable to cleartext. 127 1.2. A New Perspective 129 This document describes a change of perspective. Until now, the 130 protocol designer has viewed protection against both passive and 131 active attacks as the default, and anything short of that as 132 "degraded security" or a "fallback". The new viewpoint is that 133 without specific knowledge of peer capabilities (or explicit 134 configuration or direct request of the application), the default 135 protection is no protection, and anything more than that is an 136 improvement. 138 "Opportunistic Security" (OS) is defined as the use of cleartext as 139 the baseline communication security policy, with encryption and 140 authentication negotiated and applied to the communication when 141 available. 143 Cleartext, not comprehensive protection, is the default baseline. An 144 OS protocol is not falling back from comprehensive protection when 145 that protection is not supported by all peers; rather, OS protocols 146 aim to use the maximum protection that is available. (At some point 147 in time for a particular application or protocol all but a negligible 148 fraction of peers might support encryption. At that time, the 149 baseline security might be raised from cleartext to always require 150 encryption, and only authentication would have to be done 151 opportunistically.) 153 To achieve widespread adoption, OS must support incremental 154 deployment. Incremental deployment implies that security 155 capabilities will vary from peer to peer, perhaps for a very long 156 time. OS protocols will attempt to establish encrypted communication 157 whenever both parties are capable of such, and authenticated 158 communication if that is also possible. Thus, use of an OS protocol 159 may yield communication that is authenticated and encrypted, 160 unauthenticated but encrypted, or cleartext. This last outcome will 161 occur if not all parties to a communication support encryption (or if 162 an active attack makes it appear that this is the case). 164 When less than complete protection is negotiated, there is no need to 165 prompt the user with "your security may be degraded, please click OK" 166 dialogs. The negotiated protection is as good as can be expected. 167 Even if not comprehensive, it is often better than the traditional 168 outcome of either "no protection" or "communications failure". 170 OS is not intended as a substitute for authenticated, encrypted 171 communication when such communication is already mandated by policy 172 (that is, by configuration or direct request of the application) or 173 is otherwise required to access a particular resource. In essence, 174 OS is employed when one might otherwise settle for cleartext. OS 175 protocols never preempt explicit security policies. A security 176 administrator may specify security policies that override OS. For 177 example, a policy might require authenticated, encrypted 178 communication, in contrast to the default OS security policy. 180 In this document, the word "opportunistic" carries a positive 181 connotation. Based on advertised peer capabilities, an OS protocol 182 uses as much protection as possible. The adjective "opportunistic" 183 applies to the adaptive choice of security mechanisms peer by peer. 184 Once that choice is made for a given peer, OS looks rather similar to 185 other designs that happen to use the same set of mechanisms. 187 The remainder of this document provides definitions of important 188 terms, sets out the OS design principles, and provides an example of 189 an OS design in the context of communication between mail relays. 191 2. Terminology 193 Trust on First Use (TOFU): In a protocol, TOFU calls for accepting 194 and storing a public key or credential associated with an asserted 195 identity, without authenticating that assertion. Subsequent 196 communication that is authenticated using the cached key or 197 credential is secure against an MiTM attack, if such an attack did 198 not succeed during the vulnerable initial communication. The SSH 199 protocol [RFC4251] in its commonly deployed form makes use of 200 TOFU. The phrase "leap of faith" (LoF, [RFC4949]) is sometimes 201 used as a synonym. 203 Authenticated, encrypted communication: Encrypted communication 204 using a session establishment method in which at least the 205 initiator (or client) authenticates the identity of the acceptor 206 (or server). This is required to protect against both passive and 207 active attacks. Mutual authentication, in which the server also 208 authenticates the client, plays a role in mitigating active 209 attacks when the client and server roles change in the course of a 210 single session. 212 Unauthenticated, encrypted communication: Encrypted communication 213 using a session establishment method that does not authenticate 214 the identities of the peers. In typical usage, this means that 215 the initiator (client) has not verified the identity of the target 216 (server), making MiTM attacks possible. 218 Perfect Forward Secrecy (PFS): As defined in [RFC4949]. 220 Man-in-the-Middle (MiTM) attack: As defined in [RFC4949]. 222 3. Opportunistic Security Design Principles 224 OS provides a near-term approach to counter passive attacks by 225 removing barriers to the widespread use of encryption. OS offers an 226 incremental path to authenticated, encrypted communication in the 227 future, as suitable authentication technologies are deployed. OS 228 promotes the following design principles: 230 Coexist with explicit policy: Explicit security policies preempt OS. 231 Opportunistic security never displaces or preempts explicit 232 policy. Many applications and types of data are too sensitive to 233 use OS, and more traditional security designs are appropriate in 234 such cases. 236 Prioritize communication: The primary goal of OS is to not impede 237 communication while maximizing the deployment of usable security. 238 OS protocols need to be deployable incrementally, with each peer 239 configured independently by its administrator or user. With OS, 240 communication is still possible even when some peers support 241 encryption or authentication and others do not. 243 Maximize security peer by peer: OS protocols use encryption when it 244 is mutually supported. OS protocols enforce peer authentication 245 when an authenticated out-of-band channel is available to provide 246 the requisite keys or credentials. In general, communication 247 should be at least encrypted. OS should employ Perfect Forward 248 Secrecy (PFS) wherever possible in order to protect previously 249 recorded encrypted communication from decryption even after a 250 compromise of long-term keys. 252 No misrepresentation of security: Unauthenticated, encrypted 253 communication must not be misrepresented to users or in 254 application logs of non-interactive applications as equivalent to 255 authenticated, encrypted communication. 257 An OS protocol first determines the capabilities of the peer with 258 which it is attempting to communicate. Peer capabilities may be 259 discovered by out-of-band or in-band means. (Out-of-band mechanisms 260 include the use of DANE records or cached keys or credentials 261 acquired via TOFU. In-band determination implies negotiation between 262 peers.) The capability determination phase may indicate that the 263 peer supports authenticated, encrypted communication; 264 unauthenticated, encrypted communication; or only cleartext 265 communication. 267 Encryption is used to mitigate the risk of passive monitoring 268 attacks, while authentication is used to mitigate the risk of active 269 man-in-the-middle (MiTM) attacks. When encryption capability is 270 advertised over an insecure channel, MiTM downgrade attacks to 271 cleartext may be possible. Since encryption without authentication 272 only mitigates passive attacks, this risk is consistent with the 273 expected level of protection. For authentication to protect against 274 MiTM attacks the peer capability advertisements that convey support 275 for authentication need to be over an out-of-band authenticated 276 channel that is itself resistant to MiTM attack. 278 Opportunistic security protocols may hard-fail with peers for which a 279 security capability fails to function as advertised. Security 280 services that work reliably (when not under attack) are more likely 281 to be deployed and enabled by default. It is vital that the 282 capabilities advertised for an OS-compatible peer match the deployed 283 reality. Otherwise, OS systems will detect such a broken deployment 284 as an active attack and communication may fail. This might mean that 285 advertised peer capabilities are further filtered to consider only 286 those capabilities that are sufficiently operationally reliable. 288 Capabilities that can't be expected to work reliably should be 289 treated by an OS protocol as "not present" or "undefined". 291 With unauthenticated, encrypted communication, OS protocols may 292 employ more liberal settings than would be best-practice when 293 security is mandated by policy. Some legacy systems support 294 encryption, but implement only outdated algorithms or protocol 295 versions. Compatibility with these systems avoids the need to resort 296 to cleartext fallback. 298 For greater assurance of channel security, an OS protocol may enforce 299 more stringent cryptographic parameters when the session is 300 authenticated. For example, the set of enabled Transport Layer 301 Security (TLS [RFC5246]) cipher suites might exclude deprecated 302 algorithms that would be tolerated with unauthenticated, encrypted 303 communication. 305 OS protocols should produce authenticated, encrypted communication 306 when authentication of the peer is "expected". Here, "expected" 307 means a determination via a downgrade-resistant method that 308 authentication of that peer is expected to work. Downgrade-resistant 309 methods include: validated DANE DNS records, existing TOFU identity 310 information, and manual configuration. Such use of authentication is 311 "opportunistic", in that it is performed when possible, on a per- 312 session basis. 314 When communicating with a peer that supports encryption but not 315 authentication, any authentication checks enabled by default must be 316 disabled or configured to soft-fail in order to avoid unnecessary 317 communications failure or needless downgrade to cleartext. 319 Cleartext is supported for backwards compatibility with systems 320 already deployed. Even when cleartext needs to be supported, 321 protocol designs based on Opportunistic Security prefer to encrypt, 322 employing cleartext only with peers that do not appear to be 323 encryption capable. 325 4. Example: Opportunistic TLS in SMTP 327 Most Message Transfer Agents (MTAs, [RFC5598]) support the STARTTLS 328 ([RFC3207]) ESMTP extension. MTAs acting as SMTP ([RFC5321]) clients 329 generally support cleartext transmission of email. They negotiate 330 TLS encryption when the SMTP server announces STARTTLS support. 331 Since the initial ESMTP negotiation is not cryptographically 332 protected, the STARTTLS advertisement is vulnerable to MiTM downgrade 333 attacks. 335 Recent reports from a number of large providers (e.g., [fb-starttls] 336 and [goog-starttls]) suggest that the majority of SMTP email 337 transmission on the Internet is now encrypted, and the trend is 338 toward increasing adoption. 340 Various MTAs that advertise STARTTLS exhibit interoperability 341 problems in their implementations. As a work-around, it is common 342 for a client MTA to fall back to cleartext when the TLS handshake 343 fails, or when TLS fails during message transmission. This is a 344 reasonable trade-off, since STARTTLS only protects against passive 345 attacks. In the absence of an active attack TLS failures are 346 generally one of the known interoperability problems. 348 Some client MTAs employing STARTTLS abandon the TLS handshake when 349 the server MTA fails authentication, and immediately start a 350 cleartext connection. Other MTAs have been observed to accept 351 unverified self-signed certificates, but not expired certificates; 352 again falling back to cleartext. These and similar behaviors are NOT 353 consistent with OS principles, since they needlessly fall back to 354 cleartext when encryption is clearly possible. 356 Protection against active attacks for SMTP is described in 357 [I-D.ietf-dane-smtp-with-dane]. That document introduces the terms 358 "Opportunistic TLS" and "Opportunistic DANE TLS", and is consistent 359 with the OS design principles defined in this document. With 360 "Opportunistic DANE TLS", authenticated, encrypted communication is 361 enforced with peers for which appropriate DANE records are present. 362 For the remaining peers, "Opportunistic TLS" is employed as before. 364 5. Operational Considerations 366 OS protocol designs should minimize the possibility of failure of 367 negotiated security mechanisms. OS protocols may need to employ 368 "fallback", to work-around a failure of a security mechanisms that is 369 found in practice to encounter interoperability problems. The choice 370 to implement or enable fallback should only be made in response to 371 significant operational obstacles. 373 When protection only against passive attacks is negotiated over a 374 channel vulnerable to active downgrade attacks, and the use of 375 encryption fails, a protocol might elect non-intrusive fallback to 376 cleartext. Failure to encrypt may be more often a symptom of an 377 interoperability problem than an active attack. In such a situation 378 occasional fallback to cleartext may serve the greater good. Even 379 though some traffic is sent in the clear, the alternative is to ask 380 the administrator or user to manually work-around such 381 interoperability problems. If the incidence of such problems is non- 382 negligible, the user or administrator might find it more expedient to 383 just disable Opportunistic Security. 385 6. Security Considerations 387 OS supports communication that is authenticated and encrypted, 388 unauthenticated and encrypted, or cleartext. And yet the security 389 provided to communicating peers is not reduced by the use of OS 390 because the default OS policy employs the best security services 391 available based on the capabilities of the peers, and because 392 explicit security policies take precedence over the default OS 393 policy. OS is an improvement over the status quo; it provides better 394 security than the alternative of providing no security services when 395 authentication is not possible (and not strictly required). 397 While the use of OS is preempted by a non-OS explicit policy, such a 398 non-OS policy can be counter-productive when it demands more than 399 many peers can in fact deliver. Non-OS policy should be used with 400 care, lest users find it too restrictive and act to disable security 401 entirely. 403 7. Acknowledgements 405 I would like to thank Dave Crocker, Peter Duchovni, Paul Hoffman, 406 Benjamin Kaduk, Steve Kent, Scott Kitterman, Pete Resnick, Martin 407 Thomson, Nico Williams, Paul Wouters and Stephen Farrell for their 408 many helpful suggestions and support. 410 8. References 412 8.1. Normative References 414 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 415 Transport Layer Security", RFC 3207, February 2002. 417 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 418 Rose, "DNS Security Introduction and Requirements", RFC 419 4033, March 2005. 421 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 422 Protocol Architecture", RFC 4251, January 2006. 424 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 425 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 427 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 428 October 2008. 430 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 431 of Named Entities (DANE) Transport Layer Security (TLS) 432 Protocol: TLSA", RFC 6698, August 2012. 434 8.2. Informative References 436 [I-D.ietf-dane-smtp-with-dane] 437 Dukhovni, V. and W. Hardaker, "SMTP security via 438 opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-13 439 (work in progress), October 2014. 441 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 442 4949, August 2007. 444 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 445 2009. 447 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 448 Attack", BCP 188, RFC 7258, May 2014. 450 [fb-starttls] 451 Facebook, "The Current State of SMTP STARTTLS Deployment", 452 May 2014, . 456 [goog-starttls] 457 Google, "Safer email - Transparency Report - Google", June 458 2014, . 461 Author's Address 463 Viktor Dukhovni 464 Two Sigma 466 Email: ietf-dane@dukhovni.org