INFORMATIONAL

Internet Engineering Task Force (IETF) V. Dukhovni Request for Comments: 7435 Two Sigma Category: Informational December 2014 ISSN: 2070-1721 Opportunistic Security: Some Protection Most of the Time Abstract This document defines the concept "Opportunistic Security" in the context of communications protocols. Protocol designs based on Opportunistic Security use encryption even when authentication is not available, and use authentication when possible, thereby removing barriers to the widespread use of encryption on the Internet. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7435. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Dukhovni Informational [Page 1]

RFC 7435 Opportunistic Security December 2014 RFC6698] defines a way to distribute public keys bound to DNS names. It can provide an alternative to the Web PKI. DANE needs to be used in conjunction with DNSSEC [RFC4033]. At the time of writing, DNSSEC is not sufficiently widely deployed to allow DANE to authenticate all potential peers. Protocols that mandate authenticated communication cannot yet generally do so via DANE (at the time of writing). The lack of a global key management system means that for many protocols, only a minority of communications sessions can be predictably authenticated. When protocols only offer a choice between authenticated-and-encrypted communication, or no protection, the result is that most traffic is sent in cleartext. The fact that most traffic is not encrypted makes pervasive monitoring easier by making it cost-effective, or at least not cost-prohibitive (see [RFC7258] for more detail). For encryption to be used more broadly, authentication needs to be optional. The use of encryption defends against pervasive monitoring and other passive attacks. Even unauthenticated, encrypted communication (defined below) is preferable to cleartext. 1.2 . A New Perspective Dukhovni Informational [Page 3]

RFC 7435 Opportunistic Security December 2014 Dukhovni Informational [Page 4]

RFC 7435 Opportunistic Security December 2014 2 . Terminology RFC4251] in its commonly deployed form makes use of TOFU. The phrase "leap of faith" [RFC4949] is sometimes used as a synonym. Authenticated, encrypted communication: Encrypted communication using a session establishment method in which at least the initiator (or client) authenticates the identity of the acceptor (or server). This is required to protect against both passive and active attacks. Mutual authentication, in which the server also authenticates the client, plays a role in mitigating active attacks when the client and server roles change in the course of a single session. Unauthenticated, encrypted communication: Encrypted communication using a session establishment method that does not authenticate the identities of the peers. In typical usage, this means that the initiator (client) has not verified the identity of the target (server), making MiTM attacks possible. Perfect Forward Secrecy (PFS): As defined in [RFC4949]. Man-in-the-Middle (MiTM) attack: As defined in [RFC4949]. OS protocol: A protocol that follows the opportunistic approach to security described herein. 3 . Opportunistic Security Design Principles Dukhovni Informational [Page 5]

RFC 7435 Opportunistic Security December 2014 Dukhovni Informational [Page 6]

RFC 7435 Opportunistic Security December 2014 RFC5246] cipher suites might exclude deprecated algorithms that would be tolerated with unauthenticated, encrypted communication. OS protocols should produce authenticated, encrypted communication when authentication of the peer is "expected". Here, "expected" means a determination via a downgrade-resistant method that authentication of that peer is expected to work. Downgrade-resistant methods include: validated DANE DNS records, existing TOFU identity information, and manual configuration. Such use of authentication is "opportunistic", in that it is performed when possible, on a per- session basis. When communicating with a peer that supports encryption but not authentication, any authentication checks enabled by default must be disabled or configured to soft-fail in order to avoid unnecessary communications failure or needless downgrade to cleartext. The support of cleartext and the use of outdated algorithms, and especially broken algorithms, is for backwards compatibility with systems already deployed. Protocol designs based on Opportunistic Security prefer to encrypt and prefer to use the best available encryption algorithms available. OS protocols employ cleartext or broken encryption algorithms only with peers that do not appear to be capable of doing otherwise. The eventual desire is to transition away from cleartext and broken algorithms, and particularly for broken algorithms, it is highly desirable to remove such functionality from implementations. Dukhovni Informational [Page 7]

RFC 7435 Opportunistic Security December 2014 4 . Example: Opportunistic TLS in SMTP RFC5598] support the STARTTLS [RFC3207] ESMTP extension. MTAs acting as SMTP [RFC5321] clients generally support cleartext transmission of email. They negotiate TLS encryption when the SMTP server announces STARTTLS support. Since the initial ESMTP negotiation is not cryptographically protected, the STARTTLS advertisement is vulnerable to MiTM downgrade attacks. Recent reports from a number of large providers (e.g., [fb-starttls] and [goog-starttls]) suggest that the majority of SMTP email transmission on the Internet is now encrypted, and the trend is toward increasing adoption. Various MTAs that advertise STARTTLS exhibit interoperability problems in their implementations. As a work-around, it is common for a client MTA to fall back to cleartext when the TLS handshake fails, or when TLS fails during message transmission. This is a reasonable trade-off, since STARTTLS only protects against passive attacks. In the absence of an active attack, TLS failures are generally one of the known interoperability problems. Some client MTAs employing STARTTLS abandon the TLS handshake when the server MTA fails authentication and immediately start a cleartext connection. Other MTAs have been observed to accept unverified self- signed certificates, but not expired certificates; again falling back to cleartext. These and similar behaviors are NOT consistent with OS principles, since they needlessly fall back to cleartext when encryption is clearly possible. Protection against active attacks for SMTP is described in [SMTP-DANE]. That document introduces the terms "Opportunistic TLS" and "Opportunistic DANE TLS", and is consistent with the OS design principles defined in this document. With "Opportunistic DANE TLS", authenticated, encrypted communication is enforced with peers for which appropriate DANE records are present. For the remaining peers, "Opportunistic TLS" is employed as before. 5 . Operational Considerations Dukhovni Informational [Page 8]

RFC 7435 Opportunistic Security December 2014 6 . Security Considerations Dukhovni Informational [Page 9]

RFC 7435 Opportunistic Security December 2014 SMTP-DANE] Dukhovni, V. and W. Hardaker, "SMTP security via opportunistic DANE TLS", Work in Progress, draft-ietf- dane-smtp-with-dane-13, October 2014. [fb-starttls] Facebook, "The Current State of SMTP STARTTLS Deployment", May 2014, <https://www.facebook.com/notes/protect-the- graph/the-current-state-of-smtp-starttls-deployment/ 1453015901605223>. [goog-starttls] Google, "Safer email - Transparency Report - Google", June 2014, <https://www.google.com/transparencyreport/ saferemail/>. Acknowledgements I would like to thank Dave Crocker, Peter Duchovni, Paul Hoffman, Benjamin Kaduk, Steve Kent, Scott Kitterman, Pete Resnick, Martin Thomson, Nico Williams, Paul Wouters, and Stephen Farrell for their many helpful suggestions and support. Author's Address Viktor Dukhovni Two Sigma EMail: ietf-dane@dukhovni.org Dukhovni Informational [Page 11]