Pervasive Encryption as a Countermeasure to Pervasive Monitoring

Recent discussions in the IETF about pervasive monitoring (PM) have suggested a desire to increase use of encryption, even when the encrypted communication is unauthenticated. The term "opportunistic encryption" has been used frequently, but often without a precise definition. Some have suggested it refers to unauthenticated encryption, others view it as a shorthand for any set of mechanisms that encourage more widespread use of encryption, a marketing term that need not be precisely defined. This document examines a range of terminology relevant to the topic, and suggests use of a new term: "pervasive encryption" (PE). It also proposes a definition for the term, in the belief that the IETF deserves more than a marketing catchphrase. PE (for realtime communication) exhibits the following characteristics: It is invisible to users (so that they do not become confused by the set of security services they are being offered). It is not a substitute for authenticated, integrity-protected encryption when that set of security services can be provided to a user. PE makes use of perfect forward secrecy (PFS) for key agreement. Detection of a man-in-the-middle (MiTM) attacks is a desired, thought not mandatory, feature. Authentication is a desired, thought not mandatory, feature. Use of PE must not introduce delays in session/connection establishment that will discourage its use. As a result, MiTM detection and authentication should take place after an encrypted session/connection is established. This ordering implies that some data may be transmitted prior to authentication or detection of a MiTM. Because PE calls for a new key management paradigm, it requires new capabilities by peers. Thus, until PE is universally adopted, an outcome of attempting PE may be a fallback to plaintext communication. The term opportunistic encryption (OE) was coined by Michael Richardson in "Opportunistic Encryption using the Internet Key Exchange (IKE)" an Informational RFC . In this RFC the term is defined as: ... the process of encrypting a session with authenticated knowledge of who the other party is without prearrangement. This definition above is a bit opaque. The introduction to RFC 4322 provides a clearer description of the term, by stating the goal of OE: The objective of opportunistic encryption is to allow encryption without any pre-arrangement specific to the pair of systems involved. Later the RFC notes: Opportunistic encryption creates tunnels between nodes that are essentially strangers. This is done without any prior bilateral arrangement. The reference to "prior bilateral arrangement" is relevant to IPsec but not to most other IETF security protocols. If every pair of communicating entities were required to make prior bilateral arrangements to enable encryption between them, a substantial impediment would exist to widespread use of encryption. However, other IETF security protocols define ways to enable encryption that do not require prior bilateral arrangements. Some of these protocols require that the target of a communication make available a public key, for use by any initiator of a communication; an example of a prior unilateral arrangement. The essential difference between IPsec and most other IETF security protocols is that IPsec intrinsically incorporates access control; other IETF security protocols do not. The definition provided in is specific to the IPsec context and ought not be used to describe the goals noted above, as a countermeasure to PM. Because IPsec implements access controls, it requires explicit specification (by each peer) of how to process all traffic that crosses an "IPsec boundary" (inbound and outbound). Traffic is either discarded, permitted to pass w/o IPsec protection, or protected using IPsec. The goal of OE (as per ) is to enable IPsec protected communication without a priori configuration of access control database entries at each peer (hence, bilateral). Opportunistic encryption calls for each party to identify the other, using IKE (equivalently, IKE v2) authentication mechanisms, so it is not an unauthenticated key management approach. Also note that RFC 4322 describes OE relative to IKE, as it should; IPsec implements encryption using ESP . ESP usually provides data integrity and authentication, as well as confidentiality, thus the phrase opportunistic encryption is unduly narrow relative to the anti-PM goal. OE for IPsec is described in more detail in Section 3. RFC 4322 also defines anonymous encryption: Anonymous encryption: the process of encrypting a session without any knowledge of who the other parties are. No authentication of identities is done. Thus, in RFC 4322, the term anonymous encryption refers to encrypted communication where neither party is authenticated to the other. Also note that the definition above refers to "the process of encrypting a session ..." In fact, it the key management process that causes an encrypted session to be authenticated, or not. Thus it would be more accurate to refer to "anonymous keying", rather than anonymous encryption. This document adopts the commonly used terminology, to maintain compatibility with most IETF security standards. One can distinguish two classes of anonymous encryption, based on whether one party or both are not authenticated. For example, TLS (, , and ) typically is used in a fashion that provides server, but not client, authenticated communication. However, TLS also supports two-way authenticated sessions and "pure" unauthenticated sessions, in which neither party asserts an identity during the handshake protocol. Thus TLS offers 2-way anonymous communication and client-anonymous communication. (The same analysis applies to DTLS .) Some security experts distinguish between anonymity and pseudonymity. Pseudonymity implies use of a identifier, but one that represents a "false name" for an entity. Use of pseudonyms is common in some Internet communication contexts. Many Gmail, Yahoo, and Hotmail mail addresses likely represent pseudonyms. From a technical perspective, a pseudonym is an attractive way to provide "unauthenticated" communication. A pseudonym typically makes use of the same syntax as a real identity, and thus protocols designed to make use of authenticated identities are compatible with use of pseudonyms, to first order. "Traceable Anonymous Certificate", is an Experimental RFC that describes a specific mechanism for a Certification Authority (CA) to issue an X.509 certificate with a pseudonym. The goal of the mechanisms described in that RFC is to conceal a user's identity in PKI-based application contexts (for privacy), but to permit authorities to reveal the true identity (under controlled circumstances). This appears to be the only RFC that explicitly addresses pseudonymous key management; although it uses the term "pseudonym" extensively, it also uses the term "anonymous" more often, treating the two as synonyms. Self-signed certificates are often used with TLS in both browser and non-browser contexts. In the HTTPS (browser) context, a self-signed certificate typically is accepted after a warning has been displayed to a user; the HTTPS requirement to match a server DNS name against a certificate Subject name does not apply in non-browser contexts. The Subject name in a self-signed certificate is completely under the control of the entity that issued it, thus this is a trivial way to generate a pseudonymous certificate, without using the mechanisms specified in . Thus support for pseudonymous key management is supported in web browsing, as a side effect of this deviation from . (Some speculate that most self-signed certificates contain accurate user or device IDs; the certificates are used to avoid the costs associated with issuance of certificates by Web PKI CAs.) Based on the examples above, one could define an additional term: "pseudonymous encryption". Pseudonymous encryption is the result of applying techniques to distribute keys when an authentication exchange is based on a pseudonym, e.g., a self-signed certificate containing a pseudonym. As with anonymous encryption, pseudonymous encryption may apply to one or both parties in an encrypted communication. One also can imagine mixed mode communications, e.g., in which anonymous encryption is employed by one party and pseudonymous encryption is employed by the other. An examination of about 70 papers published in ACM, IEEE, and other security conference proceedings identified numerous uses of the terms opportunistic and anonymous encryption. Most, though not all, of the papers used the terms opportunistic encryption and anonymous encryption as defined in , but in some papers the terminology was unclear or inconsistent with the definition. Another popular source (Wikipedia) uses a somewhat different definition for opportunistic encryption. Wikipedia provides the following definition: Opportunistic encryption refers to any system that, when connecting to another system, attempts to encrypt the communications channel otherwise falling back to unencrypted communications. This method requires no pre-arrangement between the two systems. This definition shares some aspects of the RFC 4322 definition, but it is not exactly equivalent; it makes no mention of authentication or access control, two essential aspects of opportunistic encryption as per . The Wikipedia article goes on to state that opportunistic encryption can be employed with other protocols. The article describes the potential for opportunistic encryption based on the use of self-signed certificates with TLS, instead of certificates issued by a "certificate [sic] authority." This use of the term is at odds with and with TLS RFCs, which define anonymous encryption differently. The Wikipedia article further notes that use of self-signed certificates with HTTP [sic] (really HTTPS), will result in warning to users, unless browser extensions are employed, which makes user acceptance of such problematic. It cites use of the STARTTLS extension for SMTP , and use of TLS with IMAP, POP3, and ACAP , as ways of achieving opportunistic encryption for these protocols, when self-signed certificates are employed. Use of a self-signed certificate that does not attest to an authentic identity is an example of pseudonymous encryption. ZRTP is cited in the Wikipedia article as an example of opportunistic encryption for VoIP. ZRTP uses ephemeral Diffie-Hellman key management, and thus is more accurately described as offering two-way anonymous encryption. ZRTP also offers an optional mode of operation in which X.509 certificates or OpenPGP-formatted keys are employed to counter MITM attacks. An X.509 certificate used with ZRTP might be self-signed, which could enable pseudonymous keying, or it might be issued in PKI context, which would support authenticated encryption. An OpenPGP-formatted key could offer the same services. In any case, opportunistic encryption is not the most appropriate term to describe ZRTP, based on the description in . Anonymous encryption is a reasonable term to use when discussing the result of anonymous key management capabilities of protocols such as TLS and S/MIME. Access control is not part of these security protocols and there are explicit anonymous key management mechanisms that support 1-way or 2-way anonymity (for TLS). Pseudonymous encryption is the most accurate term to describe secure communication based on using identifiers that are pseudonyms. Most RFCs use the term "anonymous" even when the term "pseudonymous" is more accurate, as noted in the discussion of RFC 5636. This document uses these terms in a more precise fashion, to avoid confusion and to highlight the security-relevant differences associated with each. Most security experts view two-way authenticated, encrypted, and integrity-protected traffic as the most desirable state for secured communications. This state allows each communicant to detect (and reject) man-in-the-middle attacks. It also seems a good match to what a user expects to be true of a communication, in the absence of attacks. Most IETF security protocols have been designed to achieve this state. However, the current concerns about pervasive monitoring motivate exploring approaches to remove barriers to the widespread use of encryption. In that light, encrypted communications without authentication are viewed as a good alternative, when the preferred approach is not readily achievable. As noted earlier, the model for PE (for realtime communications) is to first establish an encrypted session, and then attempt to "upgrade" it to an authenticated communication. This is analogous to what IKE does. As experience with IKE has shown, this creates a DoS vulnerability, i.e., an attacker can cause the target of a session/connection to expend resources performing key agreement operations prior to authenticating the initiator of the communication. Implementations of PE will have to address this concern. PE designs also will have to address various flavors of downgrade attacks, since PE will allow unauthenticated or plaintext communication. Even though PE assumes that a user is not alerted to its use, it may be appropriate to alert a user to such attacks, or provide a means by which a system administrator can become aware of them. The details of how these concerns are addressed probably will be specific to the protocol context in which PE is implemented. The result of an authentication attempt may yield a 1-way or 2-way authenticated communication, or pseudonymous communication, depending on details of the protocol. Although the intent of PE should be the same for all realtime IETF protocols, the means by which each protocol achieves the goals of PE are likely to differ. So, for example, in some protocols, one might use DANE to retrieve credentials in support of authentication, in others the existing Web PKI might be employed, etc. For store-and-forward communication, the situation is more complex. A sender may choose to be anonymous or pseudonymous or authenticated; a recipient might be authenticated or pseudonymous. Because a message is addressed one or more recipients, it seems odd to refer to the recipient(s) as anonymous. If cryptographic message integrity is offered, tampering with a message en route is detectable. But, if the sender's identity is not authenticated, the often murky distinction between integrity and authentication becomes more significant. Pseudonymous, encrypted communication is another potential outcome of a key management exchange, as noted above. There is an obvious downside to use of pseudonymous credentials for key management as an alternative to anonymous key management. Pseudonymous credentials often employ the same syntax for identifiers as real credentials, and thus users may be confused by the subtle distinction. Thus it is preferable to employ anonymous keying when authenticated keying is not possible, or not desired.

The following definitions are derived from the Internet Security Glossary , where applicable. A key management technique that enables unauthenticated, communication between parties. The communication may be 1-way or 2-way anonymous. If 1-way, the initiator (client) or the target (server) may be anonymous. The process of verifying a claim that a system or entity has a certain attribute value. In the IETF context, authentication typically refers to verification of an identity claim. A key management technique for client/server communication in which the server is authenticated by the client, but the client does not assert its identity and thus is not authenticated by the server. This is an example of 1-way authentication. The security service that prevents information becoming available to unauthorized entities. Encryption is the security mechanism typically used to implement confidentiality. The security service that enables a recipient of a message or a packet to determine if the data has been modified or destroyed in an unauthorized manner. A key establishment method based on asymmetric cryptography, in which a pair of entities engage in a public exchange of data (public keys and associated data), to generate the same shared secret value. (Thus both entities contribute secret values to the resulting key.) This value is later used to create symmetric keys used for encryption and/or integrity checking. A key establishment method by which a secret (symmetric) key is generated by one entity and securely sent to another entity. (Thus only one entity contributes secret values to the resulting key.) Key transport may make use of either symmetric or asymmetric cryptographic algorithms. In a protocol, a leap of faith typically consists of accepting a claimed peer identity, without authenticating that claim, and caching a key or credential associated with the claim. Subsequent communication using the cached key/credential is secure against a MITM attack, if such an attack did not succeed during the vulnerable initial communication and if the MITM is not present for all subsequent communications. The SSH protocol (, , ) makes use of LoF. See also TOFU, below. A form of active wiretapping attack in which the attacker intercepts and selectively modifies communicated data to masquerade as one or more of the entities involved in a communication association. Masquerading enables the MITM to violate the confidentiality and/or the integrity of communicated data passing through it. A key management technique that enables authenticated, communication between parties, and that does not require a priori, bilateral arrangements. This term is defined only for IPsec. The result of employing a key management technique that attempts to establish an encrypted communication automatically and invisibly to a user. PE attempts to upgrade an encrypted communication to detect MiTM attacks and/or 1-way or 2-way authentication, If PE is unable to create an encrypted communication, e.g., because the other communicant does not support PE, unencrypted (plaintext) communication results. For a key management protocol, the property that compromise of long-term keying material does not compromise session/traffic keys that were previously derived from or distributed using the long-term material. The secret component of a pair of cryptographic keys used for asymmetric cryptography. The publicly disclosed component of a pair of cryptographic keys used for asymmetric cryptography. The phrase "public key data" includes a public key and any additional parameters required to perform computation using the public key. A key management technique that enables pseudonymous communication between parties, e.g., based on use of a self-signed certificate. Pseudonymous keying may be one-way or two-way, depending on details of the key management mechanism employed. A realtime communication between entities. A value derived from a key agreement algorithm and used as an input to generate a CEK or traffic encryption key. A type of cryptography in which the algorithms employ the same key for encryption and decryption, and the key is not publically disclosed. A symmetric key used to encrypt/decrypt traffic carried via an association. In a protocol, TOFU typically consists of accepting a claimed peer identity, without authenticating that claim, and caching a key or credential associated with the claimed identity. Subsequent communication using the cached key/credential is secure against a MITM attack, if such an attack did not succeed during the vulnerable, initial communication and if the MITM is not present for all subsequent communications. The SSH protocol makes use of this technique. See also Leap of Faith, above.