| dmarc | D. Otis |
| Internet-Draft | Trend Micro |
| Intended status: Experimental | March 3, 2015 |
| Expires: September 4, 2015 |
DMARC Author Align
draft-otis-dmarc-author-align-00
Deals with DMARC acceptance failures disrupting legitimate and valid message distribution affecting millions while attempting to exclude From header field domains not aligned with email acceptance methods in a manner incompatible with normal email conventions. DMARC does not accommodate recent message structure underscoring the erroneous premise of a store-and-forward transport enforcing non-negotiable message structure. Active exploitation of DMARC dependency on flawed acceptance practices are further aggravated when its feedback is sent to malefactors. Risks prevented by careful accommodation of legitimate and valid messages also better ensures economic, social, and civic benefits derived from an open exchange of email.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 4, 2015.
Copyright (c) 2015 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.
SMTP security via opportunistic DANE TLS [I-D.ietf-dane-smtp-with-dane] should soon offer a secure global host identity scheme for email. DNSSEC/DANE overcomes security weaknesses found in both routing and message exchange. While some claim DNSSEC/DANE is not practical they also misrepresent weaker methods based on IP address authorization or signed message fragments as representing domain authentication. IP address based authorization or potentially malformed message fragments can not safely verify a domain is bound with a message. DMARC even offers malefactors feedback which can enhance the exploit effectiveness or leak relationship information used to facilitate deceptions. Misleading use of the term "authentication" which conflicts with [RFC3552] and [RFC4949] occurs with [RFC7001] and [I-D.kucherawy-dmarc-base].
The domain referenced by SPF [RFC7208] or the domain of a DKIM [RFC6376] signature has not been a problem since seldom was acceptance based on From header field Domain Alignment with those used by these two methods. However, when acceptance is based on From header field alignment in the case of [I-D.kucherawy-dmarc-base] using either SPF or DKIM related domains, this now disrupts many Third-Party Services and deprecates the use of the From header field of being able to retain the role of Author. The disruption becomes egregious when messages from the domain's own users are rejected based on the erroneous level of this domain's asserted alignment practices. At the strictest alignment level, erroneous assertions not only disrupt messages from their users, it also affects subscriptions or services for other users of the Third-Party Service.
SPF normally provides a form of authorization by listing IP addresses of authorized outbound servers. In many cases, these servers represent a shared resource used by perhaps thousands of domains. SPF is unable to verify an IP address represents the actions of a claimed domain which does not meet the definition of "$ authentication" in [RFC4949].
DKIM intended to establish increased levels of trust based upon verified DKIM signatures controlling acceptance and what a user sees within the FROM header field. But DKIM failed to guard against pre-pended header fields to ensure acceptance is not based on verified DKIM signatures that don't prevent header field spoofing, especially that of the FROM. This weakness allows malefactors to exploit DKIM signature acceptance established by high-volume DKIM domains to spoof ANY other domain, even when prohibited within the Signer's network.
Some argued a requirement that DKIM validation include assurances the signed header fields are not invalidly repeated represents a protocol layer violation. Reporting a signature verified by a process that MUST examine the entire header field stack as needing such a recommended validation be made by a prior unreported and unknown process suggests a greater violation, if not in protocol, in trust. It took several years for one of the largest service providers to notice this oversight long after arguments were made about this risk. Ignoring essential header field stack validation that MUST occur represents an oversight in the DKIM deployment specifications that at one time had been partially addressed by the earlier DMARC specifications. It seems even this validation has been removed by what might be described as a misguided insistence such processing remains the responsibility of the transport.
[RFC5321] Section 3.3 clearly indicates messages SHOULD NOT be rejected based on perceived defects in [RFC5322] message structure. Section 7.1 also warns against preventing spoofing within the SMTP transport and suggests much safer PGP or S/MIME, both of which benefit by deployment of DANE. DMARC was developed to curtail phishing attempts leading to user attrition with high volume transactional services. Unfortunately, DMARC is being (ab)used to lessen phishing attempts related to general user accounts where there seems little interest at finding a solution for the problems this creates.
A few large domains have had a high percentage of user accounts compromised. These events gave malefactors access to prior private exchanges and contact lists. Even after accounts were reclaimed, malefactors continue sending convincing spoofed messages from other sources. To mitigate harm, some domains have asserted DMARC Alignment policies similar to those used by domains that only emit transactional messaging where a DMARC recommendation of restricted use is normally heeded. In addition, some domains also recommended "reject" rather than "quarantine" as a misalignment response. In conjunction with misleading DMARC alignment assertions, rejection becomes a highly disruptive choice.
Currently, the least disruptive adjustment made by receivers faced with Third-Party services used by a RFC5322.From domain is to override their policy of "reject" with "quarantine" to allow delivery of the message causing users to search through their "quarantine" folder for otherwise lost messages. Alternatively, the From header field may replace the Author role with that of the Sender. Some have suggested the From header field contents could be retained in the Reply-To header. Others suggested creating an X-Original-From header field which could be given the name Author.
During the development of Sender-ID, some Mail User Agents combined the Sender header field with that of the From header field when alignment matched the Sender rather than the From. The synthesized header became "sender address" on behalf of "from address". A more understandable approach would be to always display the Sender header field when present and not matching the domain of the From header field. This change would include policy following that of the Sender, which is the domain really being trusted and most likely in alignment with the acceptance mechanisms. This change would eliminate most of the disruptions now resulting from DMARC while also improving security.
DMARC could include an alignment assertion permitting policy to be based on the Sender header. Those domains that failed to ensure against the use of Third party services, could have their policy altered by the receivers to permit Sender alignment. In most cases, this would remove the need of users to risk recovering messages from their "quarantine" folder.
It is unfair to place a large burden on receivers and expect them to remain cooperative. Prior to making alignment assertions likely to disrupt services handling legitimate messages, it is possible for RFC5322.From domains to make assertions which allow compliance with normal email handling. When RFC5322.From domains proactively guard against disrupting legitimate messages, receivers are more likely to cooperate with their recommendations. When the asserted policies prove disruptive over time, DMARC should offer receivers reasonable overrides.
Deterrents based upon reputation and/or path based scoring strategies that utilize a variety of originating header fields has proved ineffective. These header fields often remain invisible to recipients, and contain domains exploited for periods measured in hours, to avoid any Whack-A-Mole like response. Even long term reputations have issues due to an intermix of messages from compromised accounts. Content filtering is unable to keep up with the polymorphic abuse. Few recipients will inspect the stack of message header fields, or be able to draw useful conclusions from a profusion of unfriendly information. As a result, many recipients deal with abuse by sorting messages into groups based on assumed sources found in a few originating header fields.
DMARC represents an open registry that offers domain specific guidance for DKIM/SPF alignment sending practices to determine whether messages should be delivered, quarantined, or refused. However, appropriate actions become unclear whenever Third-Party Services are involved. Although DMARC warns of a potential for disruption, the specific handling requested by DMARC is very limited. DMARC expects receivers to devise their own special handling to mitigate disruptions that DMARC assertions might cause for legitimate messaging. This is unfortunate, since the necessary feedback is given to the DMARC asserting domain and not to the cooperating receivers.
When a Third Party domain does not employ DKIM or SPF or does not include Authentication-Results header fields [RFC7001] or perhaps [I-D.kucherawy-original-authres] (OAR) or its "X-" version could allow authorizations to be exploited. For Third Party domains not applying DMARC but capture the OAR, past compliance with DMARC based on the OAR can be made a requirement for authorization.
While conceivably Domain Alignment might just rely on the content of the Original-Authentication-Results header, whether to trust this, or any other message content can not be based on the mere acceptance of the message alone. Whether false content even effects message acceptance would be difficult to determine. Only the DMARC asserting domain is able to make this type of determination based on their knowledge of outbound messages and corrections needed based on DMARC feedback.
Unless all valid Third-Party Domains have been authorized or allowed a suitable From header field alternative, personally identifiable information will be exchanged within the DMARC feedback. This feedback can unintentionally expose private exchanges made on behalf of the RFC5322.From domain's users. To the greatest extent possible, this feedback information should not be shared with other domains not offering the information. This feedback can even identify mailing-list subscribers that never sent any message to the list, or invoices made on behalf of an accountant's client.
This draft extends Domain Alignment validation practices that depend on DKIM [RFC6376] or SPF [RFC7208]. Most related security matters are discussed in those specifications. Additional considerations are also included in [RFC6377]. Some receivers mistakenly bypass validation of the [RFC5322] header fields because a signature from a Trusted Domain had been confirmed as perhaps suggested in [RFC5863]. Validation of the header stack MUST NOT be omitted unless the message is not accepted for other reasons.
Services that depend only upon path authorizations might permit the RFC5322.From domain to be spoofed and obtain acceptance. During such events, the RFC5322.From domain might need to retract its authorization from the service. For this reason, path related validation based on IP addresses should only be used as a carefully monitored interim solution.