| < draft-dukhovni-opportunistic-security-03.txt | | draft-dukhovni-opportunistic-security-03-kent.txt > | |
|
| | | | |
| Network Working Group V. Dukhovni | | Network Working Group V. Dukhovni | |
|
| | | | |
| Internet-Draft Two Sigma | | Internet-Draft Two Sigma | |
| Intended status: Informational August 15, 2014 | | Intended status: Informational August 15, 2014 | |
| Expires: February 16, 2015 | | Expires: February 16, 2015 | |
| | | | |
| Opportunistic Security: Some Protection Most of the Time | | Opportunistic Security: Some Protection Most of the Time | |
| draft-dukhovni-opportunistic-security-03 | | draft-dukhovni-opportunistic-security-03 | |
| | | | |
| Abstract | | Abstract | |
| | | | |
|
| This memo introduces the "Opportunistic Security" (OS) protocol | | This memo introduces the concept "Opportunistic Crypto-Security" | |
| design pattern. Protocol designs based on OS depart from the | | (OCS). OCS is a set of protocol design principles that attempt to | |
| established practice of employing cryptographic protection against | | remove barriers to the widespread use of encryption on the Internet. | |
| both passive and active attacks, or no protection at all. As a | | OCS is not a protocol. Protocols that adhere to OCS guidelines may | |
| result, with OS at least some cryptographic protection should be | | offer additional crypto-security services, e.g., integrity and | |
| provided most of the time. For example, the majority of Internet | | authentication, if these services are supported by all parties | |
| SMTP traffic is now opportunistically encrypted. OS designs remove | | to a communication. The OCS design philosophy departs from the | |
| barriers to the widespread use of encryption on the Internet. The | | common practice of other Internet security protocols; they commonly | |
| actual protection provided by opportunistic security depends on the | | require cryptographic protection against both passive and active | |
| advertised security capabilities of the communicating peers. | | attacks, or offer no protection at all. OCS protocols strive to | |
| | | offer encryption even if authentication is not available. This | |
| This document promotes designs in which cryptographic protection | | document encourages designs in which cryptographic protection | |
| against both passive and active attacks can be rolled out | | against both passive and active attacks can be deployed | |
| incrementally as new systems are deployed, without creating barriers | | incrementally, without creating barriers to communication. | |
| to communication. | | | |
| | | | |
| Status of This Memo | | Status of This Memo | |
| | | | |
| This Internet-Draft is submitted in full conformance with the | | This Internet-Draft is submitted in full conformance with the | |
| provisions of BCP 78 and BCP 79. | | provisions of BCP 78 and BCP 79. | |
| | | | |
| Internet-Drafts are working documents of the Internet Engineering | | Internet-Drafts are working documents of the Internet Engineering | |
| Task Force (IETF). Note that other groups may also distribute | | Task Force (IETF). Note that other groups may also distribute | |
| working documents as Internet-Drafts. The list of current Internet- | | working documents as Internet-Drafts. The list of current Internet- | |
| Drafts is at http://datatracker.ietf.org/drafts/current/. | | Drafts is at http://datatracker.ietf.org/drafts/current/. | |
| | | | |
| skipping to change at page 2, line 28 | | skipping to change at page 3, line ? | |
| 5. Example: Opportunistic TLS in SMTP . . . . . . . . . . . . . 8 | | 5. Example: Opportunistic TLS in SMTP . . . . . . . . . . . . . 8 | |
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |
| 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 | | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 | |
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |
| 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 | | 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 | |
| 8.2. Informative References . . . . . . . . . . . . . . . . . 10 | | 8.2. Informative References . . . . . . . . . . . . . . . . . 10 | |
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 | | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 | |
| | | | |
| 1. Introduction | | 1. Introduction | |
| | | | |
|
| Historically, Internet security protocols have emphasized | | The development of Opportunistic Crypto-Security (OCS) is motivated | |
| comprehensive "all or nothing" cryptographic protection against both | | by the concerns raised in [RFC7258]. Pervasive monitoring (as defined | |
| passive and active attacks. With each peer, such a protocol achieves | | in that RFC) is feasible because of the lack of widespread use of | |
| either full protection or else total failure to communicate (hard | | encryption for confidentiality. Although the IETF has developed many | |
| fail). As a result, operators often disable these security protocols | | security protocols (e.g., TLS, IPsec, SSH, ?) that employ encryption | |
| at the first sign of trouble, degrading all communications to | | for confidentiality, most of them also require one-way or two-way | |
| cleartext transmission. Protection against active attacks requires | | authentication. Authentication is mandated by the protocols to protect | |
| authentication. The ability to authenticate any potential peer on | | against active attacks. If communicating peers are unable to meet the | |
| the Internet requires a key management approach that works for all. | | authentication requirements imposed by these protocols, the result may | |
| | | be no communication, or plaintext communication. | |
| Designing and deploying a key management for the whole Internet is | | | |
| for now an unsolved problem. For example, the Public Key | | | |
| Infrastructure (PKI) used by the web (often called the "Web PKI") is | | | |
| based on broadly trusted public certification authorities (CAs). The | | | |
| Web PKI has too many trusted authorities and imposes burdens that not | | | |
| all peers are willing to bear. Web PKI authentication is vulnerable | | | |
| to MiTM attacks when the peer reference identifier ([RFC6125]) is | | | |
| obtained indirectly over an insecure channel, perhaps via an MX or | | | |
| SRV lookup. With so many certification authorities, which not | | | |
| everyone is willing to trust, the communicating parties don't always | | | |
| agree on a mutually trusted CA. Without a mutually trusted CA, | | | |
| authentication fails, leading to communications failure. The above | | | |
| issues are compounded by operational difficulties. For example, a | | | |
| common problem is for site operators to forget to perform timely | | | |
| renewal of expiring certificates. In interactive applications, | | | |
| security warnings are all too frequent, and end-users learn to | | | |
| actively ignore security problems. | | | |
| | | | |
| DNS Security (DNSSEC [RFC4033]) can be used to leverage the global | | | |
| DNS infrastructure as a distributed authentication system. DNS-Based | | | |
| Authentication of Named Entities (DANE [RFC6698]) provides the | | | |
| guidelines and DNS records to use the DNS as an alternative to the | | | |
| Web PKI. However, at this time, DNSSEC is not sufficiently widely | | | |
| adopted to allow DANE to play the role of an Internet-wide any-to-any | | | |
| authentication system. Therefore, protocols that mandate | | | |
| authentication for all peers cannot generally do so via DANE. | | | |
| Opportunistic security protocols on the other hand, can begin to use | | | |
| DANE immediately, without waiting for universal adoption. | | | |
| | | | |
| Other authentication mechanisms have been designed that do not rely | | | |
| on trusted third parties. The trust-on-first-use (TOFU) | | | |
| authentication approach makes a leap of faith (LoF, [RFC4949]) by | | | |
| assuming that unauthenticated public keys obtained on first contact | | | |
| will likely be good enough to secure future communication. TOFU is | | | |
| employed in SSH and in various certificate pinning designs. TOFU | | | |
| does not protect against an attacker who can hijack the first contact | | | |
| communication and requires more care from the end-user when systems | | | |
| update their cryptographic keys. TOFU can make it difficult to | | | |
| distinguish routine system administration from a malicious attack. | | | |
| | | | |
| The lack of a global key management system means that for many | | | |
| protocols only a minority of communications sessions can be | | | |
| authenticated. When protocols only offer the choice between an | | | |
| authenticated encrypted channel 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. | | | |
| | | | |
|
| To reach broad adoption, it must be possible to roll out support for | | The ability to authenticate any potential peer on the Internet requires | |
| unauthenticated encryption or authentication incrementally. | | an authentication mechanism that encompasses all such peers. No IETF | |
| Incremental rollout on the scale of the Internet means that for some | | standards for authentication meet this criteria. The Public Key | |
| considerable time security capabilities vary from peer to peer, and | | Infrastructure (PKI) model employed by browsers to authenticate web | |
| therefore protection against passive and active attacks needs to be | | servers (often called the "Web PKI" [cite]) imposes cost and management | |
| applied selectively peer by peer. | | burdens that have limited its use. The trust-on-first-use (TOFU) | |
| | | authentication approach assumes that an unauthenticated public key | |
| | | obtained on first contact (and retained for future use) will be good | |
| | | enough to secure future communication. TOFU-based protocols, e.g., SSH | |
| | | [cite] work well in enterprise environments, but were not designed to | |
| | | scale for Internet-wide use. | |
| | | | |
|
| We will use the phrase "opportunistically employed" to mean that the | | DNS-Based Authentication of Named Entities (DANE [RFC6698]) defines a | |
| use of a type of protection or a security mechanism was tailored to | | way to distribute public keys bound to DNS names. It can provide an | |
| the advertised capabilities of the peer. Both opportunistically | | alterative to the Web PKI (for other than EV certificates [cite]). | |
| employed encryption and opportunistically employed authentication | | DANE should be used in conjunction with DNSSEC [RFC4033]. At time, | |
| need to avoid deployment roadblocks and need to be designed with care | | DNSSEC is not sufficiently widely deployed to allow DANE to satisfy the | |
| to "just work". | | Internet-wide, any-to-any authentication criteria noted above. Thus | |
| | | protocols that mandate authenticated communication cannot generally | |
| | | do so via DANE (at time). | |
| | | | |
|
| To enable broader use of encryption, it must be possible to | | OCS provides a near-term approach to removing barriers to widespread | |
| opportunistically employ encryption with peers that support it | | use of encryption, while offering a path to authenticated, encrypted | |
| without always demanding authentication. This defends against | | communication in the future. The primary goal of OCS is to counter | |
| pervasive monitoring and other passive attacks, as even | | attacks, consistent with the goals established in [RFC7258]. However, | |
| unauthenticated encryption (see definition in Section 2) is | | OCS does not preclude offering protection against active attacks, if | |
| preferable to cleartext. | | suitable authentication capabilities are available. OCS is not intended | |
| | | as a substitute for authenticated, encrypted communication when such | |
| | | communication is already available to peers, e.g., based on TLS, IPsec, | |
| | | SSH, etc. | |
| | | | |
|
| The opportunistic security design pattern involves stepping up from a | | To achieve widespread adoption, OCS must support incremental deployment. | |
| baseline security policy compatible with all relevant peers to the | | Incremental deployment implies that security capabilities will vary | |
| most secure policy compatible with the capabilities of a given peer. | | from peer to peer, perhaps for a very long time. Thus use of an OCS | |
| Note, this is rather different from setting a high standard and | | protocol by one peer may yield communication that is unauthenticated | |
| attempting to determine (perhaps by asking the user) whether an | | but encrypted, authenticated and encrypted, or plaintext. This last | |
| exception can be made. | | outcome will occur if not all parties to a communication support OCS | |
| | | (or if an active attack makes it appear that this is the case). OCS | |
| | | protocols will attempt to establish authenticated, encrypted | |
| | | communication whenever both parties are capable of such, but will | |
| | | fallback to unauthenticated encrypted communication if authentication | |
| | | is not possible. Fallback to plaintext communication will occur as | |
| | | noted above. | |
| | | | |
|
| The risk of active attacks should not be ignored. The opportunistic | | OCS protocols do not prohibit the use of local security policies. A | |
| security design pattern recommends that protocols employ multiple | | security administrator may specify security policies that override | |
| cryptographic protection levels, with encrypted transmission | | opportunistic security. For example, a policy might require authenticated, | |
| accessible to most if not all peers. Protocol designers are | | encrypted communication, in contrast to the default OCS security policy. | |
| encouraged to produce protocols that can securely determine which | | | |
| peers support authentication, and can then establish authenticated | | | |
| communication channels resistant to active attacks with those peers. | | | |
| | | | |
|
| Operators must be able specify explicit security policies that | | The remainder of this document provides definitions of critical terms, | |
| override opportunistic security where appropriate. | | enumerates the OCS design principles/guidelines, and provides an example | |
| | | of an OSC design, in the context of communication between mail relays. | |
| | | | |
| 2. Terminology | | 2. Terminology | |
| | | | |
| Perfect Forward Secrecy (PFS): As defined in [RFC4949]. | | Perfect Forward Secrecy (PFS): As defined in [RFC4949]. | |
| | | | |
| Man-in-the-Middle (MiTM) attack: As defined in [RFC4949]. | | Man-in-the-Middle (MiTM) attack: As defined in [RFC4949]. | |
| | | | |
|
| Trust on First Use (TOFU): In a protocol, TOFU typically consists of | | Trust on First Use (TOFU): In a protocol, TOFU calls for accepting | |
| accepting and storing an asserted identity, without authenticating | | and storing a public key/credential associated with an asserted | |
| that assertion. Subsequent communication using the cached key/ | | identity, without authenticating that assertion. Subsequent | |
| credential is secure against an MiTM attack, if such an attack did | | communication that is authenticated using the cached key/credential | |
| not succeed during the (vulnerable) initial communication. The | | is secure against an MiTM attack, if such an attack did not | |
| | | succeed during the (vulnerable) initial communication. The | |
| SSH protocol makes use of TOFU. The phrase "leap of faith" (LoF, | | SSH protocol makes use of TOFU. The phrase "leap of faith" (LoF, | |
| [RFC4949]) is sometimes used as a synonym. | | [RFC4949]) is sometimes used as a synonym. | |
|
| | | [note that this is still not quite correct. In an enterprise environment it | |
| | | is common for the enterprise to provide an out-of-band means of verifying the | |
| | | asserted identity, e.g., based on the hash of the public key.] | |
| | | | |
|
| Authenticated encryption: Encryption using a session establishment | | One-way and Two-way Authentication <fill in> | |
| method in which at least the initiator (client) authenticates the | | | |
| identity of the acceptor (server). This is required to protect | | | |
| against both passive and active attacks. Authenticated encryption | | | |
| can be one-sided, where only the client authenticates the server. | | | |
| One-sided authentication of the server by the client is the most | | | |
| common deployment used with Transport Layer Security (TLS, | | | |
| [RFC5246]) for "secure browsing" in which client authentication is | | | |
| typically performed at another layer in the protocol. | | | |
| | | | |
| Authenticated encryption can also be two-sided or "mutual". | | | |
| Mutual authentication plays a role in mitigating active attacks | | | |
| when the client and server roles change in the course of a single | | | |
| session. Authenticated encryption is not synonymous with use of | | | |
| AEAD [RFC5116]. AEAD algorithms can be used with either | | | |
| authenticated or unauthenticated peers. | | | |
| | | | |
| Unauthenticated Encryption: Encryption 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. Unauthenticated encryption is not synonymous with non- | | | |
| use of AEAD [RFC5116]. | | | |
| | | | |
| 3. The Opportunistic Security Design Pattern | | | |
| | | | |
| Opportunistic Security is a protocol design pattern that aims to | | | |
| remove barriers to the widespread use of encryption on the Internet. | | | |
| A related goal is broader adoption of protection against active | | | |
| attacks, by enabling incremental deployment of authenticated | | | |
| encryption. | | | |
| | | | |
| The opportunistic security design pattern supports multiple | | | |
| protection levels, while seeking the best protection possible. | | | |
| | | | |
| The determination of which security mechanisms to use can vary from | | | |
| case to case and depends on the properties of the protocol in which | | | |
| OS is applied. In many cases, OS will result in negotiating channels | | | |
| with one of the following security properties: | | | |
| | | | |
| o No encryption (cleartext), which provides no protection against | | | |
| passive or active attacks. | | | |
| | | | |
| o Unauthenticated encryption (definition in Section 2), which | | | |
| protects only against passive attacks. | | | |
| | | | |
| o Authenticated encryption, (definition in Section 2) which protects | | | |
| against both passive and active attacks. | | | |
| | | | |
| An opportunistic security protocol first determines the capabilities | | | |
| of a peer. This might include whether that peer supports | | | |
| authenticated encryption, unauthenticated encryption or perhaps only | | | |
| cleartext. After each peer has determined the capabilities of the | | | |
| other, the most preferred common security capabilities are activated. | | | |
| Peer capabilities can be advertised out-of-band or (negotiated) in- | | | |
| band. | | | |
| | | | |
| An OS protocol may elect to apply more stringent security settings | | | |
| for authenticated encryption than for unauthenticated encryption. | | | |
| For example, the set of enabled TLS cipher-suites might be more | | | |
| restrictive when authentication is required. | | | |
| | | | |
| Security services that "just work" are more likely to be deployed and | | | |
| enabled by default. It is vital that the capabilities advertised for | | | |
| an OS-compatible peer match the deployed reality. Otherwise, OS | | | |
| systems will detect such a broken deployment as an active attack and | | | |
| communication may fail. | | | |
| | | | |
| This might mean that peer capabilities are further filtered to | | | |
| consider only those capabilities that are sufficiently operationally | | | |
| reliable, and any that work only "some of the time" are treated by an | | | |
| opportunistic security protocol as "not present" or "undefined". | | | |
| | | | |
| Opportunistic security does not start with an over-estimate of peer | | | |
| capabilities only to settle for lesser protection when a peer fails | | | |
| to deliver. Rather, opportunistic security sets a minimum protection | | | |
| level expected of all peers, which is raised for peers that are | | | |
| capable of more. | | | |
| | | | |
| Opportunistic security protocols should provide a means to enforce | | | |
| authentication for those peers for which authentication can be | | | |
| expected to succeed based on information advertised by the peer via | | | |
| DANE, TOFU or other means. With DANE, the advertisement that a peer | | | |
| supports authentication is downgrade-resistant. What is | | | |
| "opportunistic" here is the selective use of authentication for | | | |
| certain peers; much in the same way as unauthenticated encryption may | | | |
| be used "opportunistically" with peers capable of more than | | | |
| cleartext. | | | |
| | | | |
| Enforcement of authentication is not incompatible with opportunistic | | | |
| security. If an OS-enabled peer (A) makes available authenticated | | | |
| key material, e.g., via DANE, to peer (B), then B should make use of | | | |
| this material to authenticate A, if B is OS-enabled and supports | | | |
| DANE. | | | |
| | | | |
| With a peer that does not advertise authentication support, to which | | | |
| transmission even in cleartext is permissible, authentication (or the | | | |
| lack thereof) must never downgrade encrypted communication to | | | |
| cleartext. When employing opportunistic unauthenticated encryption, | | | |
| any enabled by default authentication checks need to be disabled or | | | |
| configured to soft-fail, allowing the unauthenticated encrypted | | | |
| session to proceed. | | | |
| | | | |
| Cleartext support is for backwards compatibility with already | | | |
| deployed systems. Even when cleartext needs to be supported, | | | |
| protocol designs based on opportunistic security prefer to encrypt, | | | |
| employing cleartext only with peers that do not appear to be | | | |
| encryption capable. | | | |
| | | | |
|
| 4. Opportunistic Security Design Principles | | 3. Opportunistic Crypto-Security Design Principles | |
| | | | |
|
| Coexist with explicit policy: Explicit security policy preempts | | As noted in Section 1, OCS aims to remove barriers to the | |
| opportunistic security. Administrators or users can elect to | | widespread use of encryption on the Internet. A secondary goal is | |
| disable opportunistic security for some or all peers and set a | | protection against active attacks, by enabling incremental | |
| fixed security policy not based on capabilities advertised or | | deployment of authenticated, encrypted communication. OCS seeks | |
| published by the peer. Alternatively, opportunistic security | | to achieve the best protection possible, based on the capabilities | |
| might be enabled only for specified peers, rather than by default. | | of communicating peers. | |
| Opportunistic security never displaces or preempts explicit | | | |
| policy. Some applications or data may be too sensitive to employ | | | |
| opportunistic security, and more traditional security designs can | | | |
| be more appropriate in such cases. | | | |
| | | | |
|
| Emphasize enabling communication: The primary goal of opportunistic | | 1. Determine Peer Security Capabilities: An OCS protocol first | |
| security is to enable secure communication and maximize | | determines the capabilities of the peer with which it is attempting | |
| deployment. If potential peers are only capable of cleartext, | | to communicate. Peer capabilities may be discovered by out-of-band | |
| then it may be acceptable to employ cleartext when encryption is | | or in-band means. (Inband determination implies negotiation between | |
| not possible. If authentication is only possible for some peers, | | peers. Out-of-band mechanism include the use of DANE records or | |
| then it is likely best to require authentication for only those | | cached keys/credentials acquired via TOFU.) The capability phase | |
| peers and not the rest. Opportunistic security needs to be | | determination may indicate that the peer supports authenticated, | |
| deployable incrementally, with each peer configured independently | | encrypted communication, unauthenticated encrypted communication, | |
| by its administrator or user. Opportunistic security must not get | | or only plaintext communication. (Note that use of out-of-band | |
| in the way of two peers communicating when neither advertises or | | capability determine, e.g., DANE or TOFU, is downgrade resistant, | |
| negotiates security services that are not in fact available or | | and thus preferred over in-band negotiation techniques. The goal | |
| that don't function correctly. | | of this design principle is to maximize the offered security | |
| | | services on a pairwise, peer basis. | |
| | | | |
|
| Maximize security peer by peer: Opportunistic security strives to | | 2. Apply Security Policy: Having determined peer security | |
| maximize security based on the capabilities of the peers. | | capabilities, an OCS protocol next applies any local security polices | |
| Communications traffic should generally be at least encrypted. | | in addition to the default OCS policy (see below). Local policies may | |
| Opportunistic security protocols may refuse to communicate with | | require security services in addition to encryption, e.g., authentication. | |
| peers for which higher security is expected, but for some reason | | A policy might restrict the set of algorithms that are employed (for encryption, | |
| is not achieved. Advertised capabilities must match reality to | | authentication, integrity, etc.) The OCS default policy is simple: establish | |
| ensure that the only condition under which there is a failure of | | encrypted communication if possible; authenticate the peer if the capability | |
| communication is when one or both peers are under an active | | exists; revert to plaintext if encrypted communication is not possible. | |
| attack. | | Reverting to plaintext merely because authentication was not possible is | |
| | | inconsistent with the default policy! However, explicit, local policy | |
| | | overrides the default OCS policy. | |
| | | | |
|
| Employ PFS: Opportunistic Security should employ Perfect Forward | | 3. Employ Perfect Forward Secrecy: OCS protocols SHOULD employ PFS | |
| Secrecy (PFS) to protect previously recorded encrypted | | to protect previously recorded encrypted communication from | |
| communication from decryption even after a compromise of long-term | | decryption even after a compromise of long-term keys. | |
| keys. | | | |
| | | | |
|
| No misrepresentation of security: Unauthenticated encrypted | | 4. No misrepresentation of security: Unauthenticated encrypted | |
| communication must not be misrepresented to users or in | | communication must not be misrepresented to users (or in | |
| application logs of non-interactive applications as equivalent to | | logs) of non-interactive applications as equivalent to | |
| communication over an authenticated encrypted channel. | | communication over an authenticated encrypted channel. This principle | |
| | | is consistent with the goal of not encouraging use of OCS in lieu of | |
| | | protocols that offer additional security services, when such protocols | |
| | | can be employed successfully. | |
| | | | |
|
| 5. Example: Opportunistic TLS in SMTP | | 4. Example: Opportunistic TLS in SMTP | |
| | | | |
| Many Message Transfer Agents (MTAs, [RFC5598]) support the STARTTLS | | Many Message Transfer Agents (MTAs, [RFC5598]) support the STARTTLS | |
| ([RFC3207]) ESMTP extension. MTAs acting as SMTP clients are | | ([RFC3207]) ESMTP extension. MTAs acting as SMTP clients are | |
| generally willing to send email without TLS (and therefore without | | generally willing to send email without TLS (and therefore without | |
| encryption), but will employ TLS (and therefore encryption) when the | | encryption), but will employ TLS (and therefore encryption) when the | |
| SMTP server announces STARTTLS support. Since the initial ESMTP | | SMTP server announces STARTTLS support. Since the initial ESMTP | |
| negotiation is not cryptographically protected, the STARTTLS | | negotiation is not cryptographically protected, the STARTTLS | |
| advertisement is vulnerable to MiTM downgrade attacks. Further, MTAs | | advertisement is vulnerable to MiTM downgrade attacks. Further, MTAs | |
|
| do not generally require peer authentication. Thus opportunistic TLS | | do not generally require peer authentication. Thus the use of STARTTLS | |
| for SMTP only protects against passive attacks. | | for SMTP protects only against passive attacks. | |
| | | | |
|
| Therefore, MTAs that implement opportunistic TLS either employ | | MTAs that implement STARTTLS establish either an authenticated, | |
| unauthenticated encryption or deliver over a cleartext channel. | | encrypted session or deliver messages over a plaintext channel. | |
| Recent reports from a number of large providers suggest that the | | Recent reports [cite?] from a number of large providers suggest | |
| majority of SMTP email transmission on the Internet is now encrypted, | | that the majority of SMTP email transmission on the Internet is now | |
| and the trend is toward increasing adoption. | | encrypted, and the trend is toward increasing adoption. | |
| | | | |
|
| Not only is the STARTTLS advertisement vulnerable to active attacks, | | The STARTTLS advertisement is vulnerable to active attacks and | |
| but also at present some MTAs that advertise STARTTLS exhibit various | | some MTAs that advertise STARTTLS exhibit various interoperability | |
| interoperability problems in their implementations. As a result, it | | problems in their implementations. As a result, it is common for a | |
| is common practice to fall back to cleartext transmission not only | | pair of STARTTLS-enabled MTAs to fall back to plaintext | |
| when STARTTLS is not offered, but also when the TLS handshake fails, | | communication when the TLS handshake fails, or when TLS fails during | |
| or even when TLS fails during message transmission. This is a | | message transmission. This is a reasonable trade-off, consistent with | |
| reasonable trade-off, since STARTTLS protects only against passive | | OCS principles, since STARTTLS protects against only passive | |
| attacks, and absent an active attack TLS failures are simply | | attacks; absent an active attack TLS failures are simply | |
| interoperability problems. | | interoperability problems. | |
| | | | |
|
| Some MTAs employing STARTTLS ([RFC3207]) abandon the TLS handshake | | Some MTAs employing STARTTLS abandon the TLS handshake when the | |
| when the server MTA fails authentication, only to immediately deliver | | peer MTA fails authentication, only to immediately deliver | |
| the same message over a cleartext connection. Other MTAs have been | | the same message over a plaintext connection. Other MTAs have been | |
| observed to tolerate unverified self-signed certificates, but not | | observed to tolerate unverified self-signed certificates, but not | |
|
| expired certificates, again falling back to cleartext. These and | | expired certificates, again falling back to plaintext. These and | |
| similar implementation errors must be avoided. In either case, had | | similar behaviors are NOT consistent with OCS principles, since | |
| these MTAs instead used the OS design pattern, the communication | | they revert to plaintext communication when authentication fails, | |
| would still have been encrypted and therefore protected against | | instead of employing unauthenticated, encryption, communication. | |
| passive attacks. | | | |
| | | | |
|
| Protection against active attacks for SMTP is proposed in | | Protection against active attacks for SMTP is described in | |
| [I-D.ietf-dane-smtp-with-dane]. That draft introduces the terms | | [I-D.ietf-dane-smtp-with-dane]. That draft introduces the terms | |
|
| "Opportunistic TLS" and "Opportunistic DANE TLS", which are for now | | "Opportunistic TLS" and "Opportunistic DANE TLS"; this draft is | |
| informal. | | consistent with the OCS design principles defined in this document. | |
| | | | |
| 6. Security Considerations | | 6. Security Considerations | |
| | | | |
|
| Though opportunistic security potentially supports transmission in | | OCS supports communication that is authenticated and encrypted, | |
| cleartext, unauthenticated encryption, or other cryptographic | | unauthenticated and encrypted, or plaintext. The security services | |
| protection levels short of the strongest potentially applicable, the | | offered to communicating peers is not reduced by the use of OCS. | |
| effective security for peers is not reduced. If a cryptographic | | This is because the default OCS policy employs the best security | |
| capability is neither required by policy nor supported by the peer, | | services available based on the capabilities of the peers, and | |
| nothing is lost by going without. Opportunistic security is strictly | | because local security policies take precedence over the default | |
| stronger than the alternative of providing no security services when | | OCS policy. OCS is an improvement over the status quo; it provides | |
| maximal security is not applicable. | | better security than the alternative of providing no security services | |
| | | when authentication is not possible (and not strictly required) | |
| | | | |
|
| Opportunistic security coexists with and is preempted by any | | OCS coexists with and is preempted by local, non-OCS security polices. | |
| applicable non-opportunistic security policy. However, such non- | | Non-OCS policies may inhibit use of encryption when many peers cannot | |
| opportunistic policy can be counter-productive when it demands more | | offer authenticated, encrypted communication. Unless authenticated, | |
| than many peers can in fact deliver. Non-opportunistic policy should | | encrypted communication is necessary, non-OCS local policies of this | |
| be used with care, lest users find it too restrictive and act to | | sort run counter to the goals established in [RFC7258]. | |
| disable security entirely. | | | |
| | | | |
| 7. Acknowledgements | | 7. Acknowledgements | |
| | | | |
| I would like to thank Steve Kent. Some of the text in this document | | I would like to thank Steve Kent. Some of the text in this document | |
| is based on his earlier draft. I would like to thank Dave Crocker, | | is based on his earlier draft. I would like to thank Dave Crocker, | |
|
| Peter Duchovni, Paul Hoffman, Steve Kent, Scott Kitterman, Martin | | Peter Duchovni, Paul Hoffman, Scott Kitterman, Martin | |
| Thomson, Nico Williams, Paul Wouters and Stephen Farrell for their | | Thomson, Nico Williams, Paul Wouters and Stephen Farrell for their | |
| helpful suggestions and support. | | helpful suggestions and support. | |
| | | | |
| 8. References | | 8. References | |
| | | | |
| 8.1. Normative References | | 8.1. Normative References | |
| | | | |
| [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over | | [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over | |
| Transport Layer Security", RFC 3207, February 2002. | | Transport Layer Security", RFC 3207, February 2002. | |
| | | | |
| | | | |
End of changes. 30 change blocks. |
| 302 lines changed or deleted | | 164 lines changed or added | |
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |