7Internet Engineering Task Force (IETF) V. Dukhovni
8Request for Comments: 7435 Two Sigma
9Category: Informational December 2014
13 Opportunistic Security: Some Protection Most of the Time
17 This document defines the concept "Opportunistic Security" in the
18 context of communications protocols. Protocol designs based on
19 Opportunistic Security use encryption even when authentication is not
20 available, and use authentication when possible, thereby removing
21 barriers to the widespread use of encryption on the Internet.
25 This document is not an Internet Standards Track specification; it is
26 published for informational purposes.
28 This document is a product of the Internet Engineering Task Force
29 (IETF). It represents the consensus of the IETF community. It has
30 received public review and has been approved for publication by the
31 Internet Engineering Steering Group (IESG). Not all documents
32 approved by the IESG are a candidate for any level of Internet
33 Standard; see Section 2 of RFC 5741.
35 Information about the current status of this document, any errata,
36 and how to provide feedback on it may be obtained at
37 http://www.rfc-editor.org/info/rfc7435.
41 Copyright (c) 2014 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents
46 (http://trustee.ietf.org/license-info) in effect on the date of
47 publication of this document. Please review these documents
48 carefully, as they describe your rights and restrictions with respect
49 to this document. Code Components extracted from this document must
50 include Simplified BSD License text as described in Section 4.e of
51 the Trust Legal Provisions and are provided without warranty as
52 described in the Simplified BSD License.
58Dukhovni Informational [Page 1]
60RFC 7435 Opportunistic Security December 2014
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
66 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 2
67 1.2. A New Perspective . . . . . . . . . . . . . . . . . . . . 3
68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
69 3. Opportunistic Security Design Principles . . . . . . . . . . 5
70 4. Example: Opportunistic TLS in SMTP . . . . . . . . . . . . . 8
71 5. Operational Considerations . . . . . . . . . . . . . . . . . 8
72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
74 7.1. Normative References . . . . . . . . . . . . . . . . . . 10
75 7.2. Informative References . . . . . . . . . . . . . . . . . 10
76 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
83 Historically, Internet security protocols have emphasized
84 comprehensive "all or nothing" cryptographic protection against both
85 passive and active attacks. With each peer, such a protocol achieves
86 either full protection or else total failure to communicate (hard
87 fail). As a result, operators often disable these security protocols
88 when users have difficulty connecting, thereby degrading all
89 communications to cleartext transmission.
91 Protection against active attacks requires authentication. The
92 ability to authenticate any potential peer on the Internet requires
93 an authentication mechanism that encompasses all such peers. No IETF
94 standard for authentication scales as needed and has been deployed
95 widely enough to meet this requirement.
97 The Public Key Infrastructure (PKI) model employed by browsers to
98 authenticate web servers (often called the "Web PKI") imposes cost
99 and management burdens that have limited its use. With so many
100 Certification Authorities (CAs), not all of which everyone is willing
101 to trust, the communicating parties don't always agree on a mutually
102 trusted CA. Without a mutually trusted CA, authentication fails,
103 leading to communications failure in protocols that mandate
104 authentication. These issues are compounded by operational
105 difficulties. For example, a common problem is for site operators to
106 forget to perform timely renewal of expiring certificates. In Web
107 PKI interactive applications, security warnings are all too frequent,
108 and end users learn to actively ignore security problems, or site
109 administrators decide that the maintenance cost is not worth the
110 benefit so they provide a cleartext-only service to their users.
114Dukhovni Informational [Page 2]
116RFC 7435 Opportunistic Security December 2014
119 The trust-on-first-use (TOFU) authentication approach assumes that an
120 unauthenticated public key obtained on first contact (and retained
121 for future use) will be good enough to secure future communication.
122 TOFU-based protocols do not protect against an attacker who can
123 hijack the first contact communication and require more care from the
124 end user when systems update their cryptographic keys. TOFU can make
125 it difficult to distinguish routine key management from a malicious
128 DNS-Based Authentication of Named Entities (DANE) [RFC6698] defines a
129 way to distribute public keys bound to DNS names. It can provide an
130 alternative to the Web PKI. DANE needs to be used in conjunction
131 with DNSSEC [RFC4033]. At the time of writing, DNSSEC is not
132 sufficiently widely deployed to allow DANE to authenticate all
133 potential peers. Protocols that mandate authenticated communication
134 cannot yet generally do so via DANE (at the time of writing).
136 The lack of a global key management system means that for many
137 protocols, only a minority of communications sessions can be
138 predictably authenticated. When protocols only offer a choice
139 between authenticated-and-encrypted communication, or no protection,
140 the result is that most traffic is sent in cleartext. The fact that
141 most traffic is not encrypted makes pervasive monitoring easier by
142 making it cost-effective, or at least not cost-prohibitive (see
143 [RFC7258] for more detail).
145 For encryption to be used more broadly, authentication needs to be
146 optional. The use of encryption defends against pervasive monitoring
147 and other passive attacks. Even unauthenticated, encrypted
148 communication (defined below) is preferable to cleartext.
1501.2. A New Perspective
152 This document describes a change of perspective. Until now, the
153 protocol designer has viewed protection against both passive and
154 active attacks as the default, and anything short of that as
155 "degraded security" or a "fallback". The new viewpoint is that
156 without specific knowledge of peer capabilities (or explicit
157 configuration or direct request of the application), the default
158 protection is no protection, and anything more than that is an
161 "Opportunistic Security" (OS) is defined as the use of cleartext as
162 the baseline communication security policy, with encryption and
163 authentication negotiated and applied to the communication when
170Dukhovni Informational [Page 3]
172RFC 7435 Opportunistic Security December 2014
175 Cleartext, not comprehensive protection, is the default baseline. An
176 OS protocol is not falling back from comprehensive protection when
177 that protection is not supported by all peers; rather, OS protocols
178 aim to use the maximum protection that is available. (At some point
179 in time for a particular application or protocol all but a negligible
180 fraction of peers might support encryption. At that time, the
181 baseline security might be raised from cleartext to always require
182 encryption, and only authentication would have to be done
185 To achieve widespread adoption, OS must support incremental
186 deployment. Incremental deployment implies that security
187 capabilities will vary from peer to peer, perhaps for a very long
188 time. OS protocols will attempt to establish encrypted communication
189 whenever both parties are capable of such, and authenticated
190 communication if that is also possible. Thus, use of an OS protocol
191 may yield communication that is authenticated and encrypted,
192 unauthenticated but encrypted, or cleartext. This last outcome will
193 occur if not all parties to a communication support encryption (or if
194 an active attack makes it appear that this is the case).
196 When less than complete protection is negotiated, there is no need to
197 prompt the user with "your security may be degraded, please click OK"
198 dialogs. The negotiated protection is as good as can be expected.
199 Even if not comprehensive, it is often better than the traditional
200 outcome of either "no protection" or "communications failure".
202 OS is not intended as a substitute for authenticated, encrypted
203 communication when such communication is already mandated by policy
204 (that is, by configuration or direct request of the application) or
205 is otherwise required to access a particular resource. In essence,
206 OS is employed when one might otherwise settle for cleartext. OS
207 protocols never preempt explicit security policies. A security
208 administrator may specify security policies that override OS. For
209 example, a policy might require authenticated, encrypted
210 communication, in contrast to the default OS security policy.
212 In this document, the word "opportunistic" carries a positive
213 connotation. Based on advertised peer capabilities, an OS protocol
214 uses as much protection as possible. The adjective "opportunistic"
215 applies to the adaptive choice of security mechanisms peer by peer.
216 Once that choice is made for a given peer, OS looks rather similar to
217 other designs that happen to use the same set of mechanisms.
219 The remainder of this document provides definitions of important
220 terms, sets out the OS design principles, and provides an example of
221 an OS design in the context of communication between mail relays.
226Dukhovni Informational [Page 4]
228RFC 7435 Opportunistic Security December 2014
233 Trust on First Use (TOFU): In a protocol, TOFU calls for accepting
234 and storing a public key or credential associated with an asserted
235 identity, without authenticating that assertion. Subsequent
236 communication that is authenticated using the cached key or
237 credential is secure against an MiTM attack, if such an attack did
238 not succeed during the vulnerable initial communication. The SSH
239 protocol [RFC4251] in its commonly deployed form makes use of
240 TOFU. The phrase "leap of faith" [RFC4949] is sometimes used as a
243 Authenticated, encrypted communication: Encrypted communication
244 using a session establishment method in which at least the
245 initiator (or client) authenticates the identity of the acceptor
246 (or server). This is required to protect against both passive and
247 active attacks. Mutual authentication, in which the server also
248 authenticates the client, plays a role in mitigating active
249 attacks when the client and server roles change in the course of a
252 Unauthenticated, encrypted communication: Encrypted communication
253 using a session establishment method that does not authenticate
254 the identities of the peers. In typical usage, this means that
255 the initiator (client) has not verified the identity of the target
256 (server), making MiTM attacks possible.
258 Perfect Forward Secrecy (PFS): As defined in [RFC4949].
260 Man-in-the-Middle (MiTM) attack: As defined in [RFC4949].
262 OS protocol: A protocol that follows the opportunistic approach to
263 security described herein.
2653. Opportunistic Security Design Principles
267 OS provides a near-term approach to counter passive attacks by
268 removing barriers to the widespread use of encryption. OS offers an
269 incremental path to authenticated, encrypted communication in the
270 future, as suitable authentication technologies are deployed. OS
271 promotes the following design principles:
273 Coexist with explicit policy: Explicit security policies preempt OS.
274 Opportunistic security never displaces or preempts explicit
275 policy. Many applications and types of data are too sensitive to
276 use OS, and more traditional security designs are appropriate in
282Dukhovni Informational [Page 5]
284RFC 7435 Opportunistic Security December 2014
287 Prioritize communication: The primary goal of OS is to not impede
288 communication while maximizing the deployment of usable security.
289 OS protocols need to be deployable incrementally, with each peer
290 configured independently by its administrator or user. With OS,
291 communication is still possible even when some peers support
292 encryption or authentication and others do not.
294 Maximize security peer by peer: OS protocols use encryption when it
295 is mutually supported. OS protocols enforce peer authentication
296 when an authenticated out-of-band channel is available to provide
297 the requisite keys or credentials. In general, communication
298 should be at least encrypted. OS should employ PFS wherever
299 possible in order to protect previously recorded encrypted
300 communication from decryption even after a compromise of long-term
303 No misrepresentation of security: Unauthenticated, encrypted
304 communication must not be misrepresented to users or in
305 application logs of non-interactive applications as equivalent to
306 authenticated, encrypted communication.
308 An OS protocol first determines the capabilities of the peer with
309 which it is attempting to communicate. Peer capabilities may be
310 discovered by out-of-band or in-band means. (Out-of-band mechanisms
311 include the use of DANE records or cached keys or credentials
312 acquired via TOFU. In-band determination implies negotiation between
313 peers.) The capability determination phase may indicate that the
314 peer supports authenticated, encrypted communication;
315 unauthenticated, encrypted communication; or only cleartext
318 Encryption is used to mitigate the risk of passive monitoring
319 attacks, while authentication is used to mitigate the risk of active
320 MiTM attacks. When encryption capability is advertised over an
321 insecure channel, MiTM downgrade attacks to cleartext may be
322 possible. Since encryption without authentication only mitigates
323 passive attacks, this risk is consistent with the expected level of
324 protection. For authentication to protect against MiTM attacks, the
325 peer capability advertisements that convey support for authentication
326 need to be over an out-of-band authenticated channel that is itself
327 resistant to MiTM attack.
329 Opportunistic security protocols may hard-fail with peers for which a
330 security capability fails to function as advertised. Security
331 services that work reliably (when not under attack) are more likely
332 to be deployed and enabled by default. It is vital that the
333 capabilities advertised for an OS-compatible peer match the deployed
334 reality. Otherwise, OS systems will detect such a broken deployment
338Dukhovni Informational [Page 6]
340RFC 7435 Opportunistic Security December 2014
343 as an active attack and communication may fail. This might mean that
344 advertised peer capabilities are further filtered to consider only
345 those capabilities that are sufficiently operationally reliable.
346 Capabilities that can't be expected to work reliably should be
347 treated by an OS protocol as "not present" or "undefined".
349 With unauthenticated, encrypted communication, OS protocols may
350 employ more liberal settings than would be best practice when
351 security is mandated by policy. Some legacy systems support
352 encryption, but implement only outdated algorithms or protocol
353 versions. Compatibility with these systems avoids the need to resort
354 to cleartext fallback.
356 For greater assurance of channel security, an OS protocol may enforce
357 more stringent cryptographic parameters when the session is
358 authenticated. For example, the set of enabled Transport Layer
359 Security (TLS) [RFC5246] cipher suites might exclude deprecated
360 algorithms that would be tolerated with unauthenticated, encrypted
363 OS protocols should produce authenticated, encrypted communication
364 when authentication of the peer is "expected". Here, "expected"
365 means a determination via a downgrade-resistant method that
366 authentication of that peer is expected to work. Downgrade-resistant
367 methods include: validated DANE DNS records, existing TOFU identity
368 information, and manual configuration. Such use of authentication is
369 "opportunistic", in that it is performed when possible, on a per-
372 When communicating with a peer that supports encryption but not
373 authentication, any authentication checks enabled by default must be
374 disabled or configured to soft-fail in order to avoid unnecessary
375 communications failure or needless downgrade to cleartext.
377 The support of cleartext and the use of outdated algorithms, and
378 especially broken algorithms, is for backwards compatibility with
379 systems already deployed. Protocol designs based on Opportunistic
380 Security prefer to encrypt and prefer to use the best available
381 encryption algorithms available. OS protocols employ cleartext or
382 broken encryption algorithms only with peers that do not appear to be
383 capable of doing otherwise. The eventual desire is to transition
384 away from cleartext and broken algorithms, and particularly for
385 broken algorithms, it is highly desirable to remove such
386 functionality from implementations.
394Dukhovni Informational [Page 7]
396RFC 7435 Opportunistic Security December 2014
3994. Example: Opportunistic TLS in SMTP
401 Most Message Transfer Agents (MTAs) [RFC5598] support the STARTTLS
402 [RFC3207] ESMTP extension. MTAs acting as SMTP [RFC5321] clients
403 generally support cleartext transmission of email. They negotiate
404 TLS encryption when the SMTP server announces STARTTLS support.
405 Since the initial ESMTP negotiation is not cryptographically
406 protected, the STARTTLS advertisement is vulnerable to MiTM downgrade
409 Recent reports from a number of large providers (e.g., [fb-starttls]
410 and [goog-starttls]) suggest that the majority of SMTP email
411 transmission on the Internet is now encrypted, and the trend is
412 toward increasing adoption.
414 Various MTAs that advertise STARTTLS exhibit interoperability
415 problems in their implementations. As a work-around, it is common
416 for a client MTA to fall back to cleartext when the TLS handshake
417 fails, or when TLS fails during message transmission. This is a
418 reasonable trade-off, since STARTTLS only protects against passive
419 attacks. In the absence of an active attack, TLS failures are
420 generally one of the known interoperability problems.
422 Some client MTAs employing STARTTLS abandon the TLS handshake when
423 the server MTA fails authentication and immediately start a cleartext
425 signed certificates, but not expired certificates; again falling back
426 to cleartext. These and similar behaviors are NOT consistent with OS
427 principles, since they needlessly fall back to cleartext when
428 encryption is clearly possible.
430 Protection against active attacks for SMTP is described in
431 [SMTP-DANE]. That document introduces the terms "Opportunistic TLS"
432 and "Opportunistic DANE TLS", and is consistent with the OS design
433 principles defined in this document. With "Opportunistic DANE TLS",
434 authenticated, encrypted communication is enforced with peers for
435 which appropriate DANE records are present. For the remaining peers,
436 "Opportunistic TLS" is employed as before.
4385. Operational Considerations
440 OS protocol designs should minimize the possibility of failure of
441 negotiated security mechanisms. OS protocols may need to employ
442 "fallback", to work-around a failure of a security mechanisms that is
443 found in practice to encounter interoperability problems. The choice
444 to implement or enable fallback should only be made in response to
445 significant operational obstacles.
450Dukhovni Informational [Page 8]
452RFC 7435 Opportunistic Security December 2014
455 When protection only against passive attacks is negotiated over a
456 channel vulnerable to active downgrade attacks and the use of
457 encryption fails, a protocol might elect non-intrusive fallback to
458 cleartext. Failure to encrypt may be more often a symptom of an
460 occasional fallback to cleartext may serve the greater good. Even
461 though some traffic is sent in the clear, the alternative is to ask
462 the administrator or user to manually work-around such
463 interoperability problems. If the incidence of such problems is non-
464 negligible, the user or administrator might find it more expedient to
465 just disable Opportunistic Security.
4676. Security Considerations
469 OS supports communication that is authenticated and encrypted,
470 unauthenticated and encrypted, or cleartext. And yet the security
471 provided to communicating peers is not reduced by the use of OS
472 because the default OS policy employs the best security services
473 available based on the capabilities of the peers, and because
474 explicit security policies take precedence over the default OS
475 policy. OS is an improvement over the status quo; it provides better
476 security than the alternative of providing no security services when
477 authentication is not possible (and not strictly required).
479 While the use of OS is preempted by a non-OS explicit policy, such a
480 non-OS policy can be counter-productive when it demands more than
481 many peers can in fact deliver. A non-OS policy should be used with
482 care, lest users find it too restrictive and act to disable security
485 When protocols follow the OS approach, attackers engaged in large-
486 scale passive monitoring can no longer just collect everything, and
487 have to be more selective and/or mount more active attacks. In
488 addition, OS means active attacks on everyone all the time are much
489 more likely to be noticed.
491 Specific techniques for detection and mitigation of active attacks in
492 the absence of authentication are out of scope for this document.
493 Some existing protocols that could support OS may be vulnerable to
494 relatively low-cost downgrade attacks for attackers on the path.
495 However, when such attacks are employed pervasively in order to
496 facilitate, for example, surveillance, this is often detectable;
497 hence, even in such scenarios, OS protocols provide a positive
500 Protocols following the OS approach may need to define additional
501 measures to make systematic downgrades less likely to succeed or more
502 likely to be detected. When we have more experience in this space,
506Dukhovni Informational [Page 9]
508RFC 7435 Opportunistic Security December 2014
511 future revisions of this or related documents may be able to make
512 more generally applicable recommendations.
5167.1. Normative References
518 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
519 Transport Layer Security", RFC 3207, February 2002,
520 <http://www.rfc-editor.org/info/rfc3207>.
522 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
523 Rose, "DNS Security Introduction and Requirements", RFC
525 <http://www.rfc-editor.org/info/rfc4033>.
527 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
528 Protocol Architecture", RFC 4251, January 2006,
529 <http://www.rfc-editor.org/info/rfc4251>.
531 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
533 <http://www.rfc-editor.org/info/rfc4949>.
535 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
536 (TLS) Protocol Version 1.2", RFC 5246, August 2008,
537 <http://www.rfc-editor.org/info/rfc5246>.
539 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
540 October 2008, <http://www.rfc-editor.org/info/rfc5321>.
542 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
543 of Named Entities (DANE) Transport Layer Security (TLS)
544 Protocol: TLSA", RFC 6698, August 2012,
545 <http://www.rfc-editor.org/info/rfc6698>.
5477.2. Informative References
549 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July
550 2009, <http://www.rfc-editor.org/info/rfc5598>.
552 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
553 Attack", BCP 188, RFC 7258, May 2014,
554 <http://www.rfc-editor.org/info/rfc7258>.
562Dukhovni Informational [Page 10]
564RFC 7435 Opportunistic Security December 2014
568 Dukhovni, V. and W. Hardaker, "SMTP security via
569 opportunistic DANE TLS", Work in Progress, draft-ietf-
570 dane-smtp-with-dane-13, October 2014.
573 Facebook, "The Current State of SMTP STARTTLS Deployment",
574 May 2014, <https://www.facebook.com/notes/protect-the-
575 graph/the-current-state-of-smtp-starttls-deployment/
579 Google, "Safer email - Transparency Report - Google", June
580 2014, <https://www.google.com/transparencyreport/
585 I would like to thank Dave Crocker, Peter Duchovni, Paul Hoffman,
586 Benjamin Kaduk, Steve Kent, Scott Kitterman, Pete Resnick, Martin
587 Thomson, Nico Williams, Paul Wouters, and Stephen Farrell for their
588 many helpful suggestions and support.
595 EMail: ietf-dane@dukhovni.org
618Dukhovni Informational [Page 11]