This article will first provide some context around the SPF, DKIM, and DMARC protocols for email security, and will establish the reasoning behind the announcement of a new protocol called ARC in 2016. It will then offer an overview of how the ARC protocol works in support of the other three protocols.
SPF: A Screen from the Sun of Scammers
Sender Policy Framework (SPF) is an email authentication protocol allowing domain administrators to define, with a specifically formatted DNS TXT record, an explicit list of mail servers that are authorized to send mail from their domain. This is a significantly valuable protocol because enabling it removes the ability for attackers simply spoof emails from email addresses within the domain. Or, put more strongly, not enabling for a domain (e.g., example.com) gives any interested attacker the option to spoof emails from any email address within that domain (e.g., ceo@example.com), allowing them to potentially leverage and exploit the authority of certain people (e.g., CEOs, directors, presidents, etc.) within an organization to trigger some action such as clicking a link or providing confidential information. Moreover, it’s fairly straightforward to set up, especially with tools like MX Toolbox SPF Record Generator.
Stopping the Bad Guys with DKIM Possible
Since the other protocol that DMARC builds upon is DomainKeys Identified Mail (DKIM), and DKIM is based on the idea of digital signatures for protecting and verifying message integrity, let’s quickly review how digital signatures work. In short, a message sender first hashes their message to produce a message digest, then encrypts that message using their own private key to produce their digital signature, which gets appended to the message before transmission. Upon receiving the message with the appended digital signature, the receiver hashes the received message using the same hash function as the sender, and then uses the public key of the sender to decrypt the digital signature back into a message digest. If the message digest from the digital signature decryption matches the message digest produced by hashing the received message with the same hash function, the receiver can be sure that the message came from the sender and hasn’t been tampered with during transmission.
With that in mind, DKIM works essentially the same way. The sending email server essentially takes an outbound email, hashes it (well, parts of it, e.g., the subject, the from address, the body, etc.) to produce a message digest, encrypts that digest with a private key to create a DKIM signature, then appends that signature to the outbound email before transmitting it. The receiving server, upon receiving the signed email, hashes the email with the same hash function used by the sender to produce a new message digest, then retrieves the sending server’s public key by querying DNS (since the sending server public key is stored publicly in DNS) and uses that public key to decrypt the appended DKIM signature back into a message digest. If the two digests match, the email has not been tampered with and it certainly came from the expected sender. If they don’t, well, different things can happen, which is where DMARC comes in.
DMARC: Demarcating Good Emails from Bad Emails
First published in 2012, the Domain-based Message Authentication, Reporting and Conformance (DMARC) email authentication protocol builds upon the SPF and DKIM protocols to enable email senders and receivers to cooperatively defend against and report on fraudulent emails impersonating a domain. When emails fail to authenticate against SPF or DKIM, we need an explicitly defined way of handling and reporting those failures, whether that means blocking emails entirely or simply flagging them as suspicious and sending them on their merry (or rather, maily) way. DMARC is the protocol that allows domain administrators to define this handling and reporting logic. Setting up DMARC is a matter of first choosing one of three policies: none, quarantine, or reject. The none policy is, as expected, the least restrictive policy that essentially does nothing aside from monitoring for report gathering; the quarantine policy takes the emails that fail authentication and puts them in the recipient’s junk folder rather than their main inbox; lastly, the reject policy is of course the most restrictive in that it completely blocks the delivery of emails that fail authentication. There are also a number of other configurable properties for the DMARC protocol centered on things like aggregate and forensic reporting, subdomain-specific policies, and strict versus relaxed alignment rules as seen pretty clearly in this very simple MX Toolbox DMARC Record Generator tool.
The important thing to note is that DMARC can be enabled with a range of very different behaviors for a domain depending on specific needs, from super simple, non-blocking report generation about fraudulent emails to full-fledged blocking of emails that look even slightly fraudulent — even in cases where they aren’t. This leads us to ARC.
ARC — Keeping Emails Afloat with Strict Security Settings
In defense against rising — rather, “spiking” — threats to email security, an increasing number of domains are adopting strict DMARC policies due to the protection it provides from attackers and the visibility it provides of their activity. But there is a catch. Anyone who works in software surely knows that whenever you start locking a system down to make it more secure, new usability issues are bound to pop up (e.g., locking down east-west traffic in a data center with a firewall to make a local network more secure inherently increases the difficulty of setting up new applications and services within that network).
That doesn’t make the security not worth it, though.
Assume an organization has set up the SPF and DKIM protocols and has also set up DMARC with the reject policy such that any emails failing authentication against SPF and DKIM do not get delivered. Now, also assume that the organization has a communications team that uses a mailing list, or third-party-forwarder, to send out a weekly newsletter to subscribers, or perhaps marketing materials to interested potential customers. Each week, when sending out the mass email, the communications team sends their message to the mailing list server which consumes, processes, slightly changes, and then relays the message onward to the subscribers of the list. Unfortunately, because of the changes made to the message by the mailing list during the processing, the message no longer produces the same digest when hashed, which means DKIM will fail on the receiving end. Also, if the organization hasn’t explicitly included the address of the intermediary mailing list server in the authorized senders list of their domain’s SPF record, SPF will also fail since the receiving mail server will attempt to verify the received message isn’t spoofed by asserting the sender’s address (the address of the mailing list server) is in the list of the domain’s authorized senders (where the domain is pulled from the email’s Return-Path).
In other words, if A sends to B and B forwards to C, C is going to find that B is not authorized to send on behalf of A if A hasn’t set up B as an authorized sender with SPF. Now, if the organization sending out this communication has set up their email security policies to block delivery of these messages failing authentication, they’re not reaching their audience.
As explained by Steven Jones, Executive Director of DMARC.org the Authenticated Received Chain (ARC) protocol announced in 2016 aims to fix this problem. Basically, with this protocol, the authentication results of the original email, whether pass or fail, can be preserved across an arbitrary number of hops to a final destination (no supernatural horror involved, I promise!).
Taking the previous example, the intermediary server B would observe and record the authentication results of SPF and DKIM of the email from the original server A and would append the results to the email before sending it onward to C. It appends these results in the form of a new ARC-Authentication-Results (AAR) header combining the SPF, DKIM, and DMARC results with an instance number i, where i is really a count of intermediary servers in the chain so far. It would also add an ARC-Seal (AS) header, which is a combination of a that same number i, a DKIM-esque signature of previous ARC-Seal headers, and the validity of prior ARC entries. Lastly, it would add an ARC-Message-Signature (AMS) header, which again combines the instance number i with a DKIM-esque signature of the entire email minus the ARC-Seal headers. So, as you move down a chain of intermediary forwarding services of arbitrary length, the instance number i starts at 1 at the first forwarder and continues incrementing until reaching the last forwarder, and each forwarder has to use the ARC-* headers from the previous forwarder to calculate its own new ARC-* headers. At the end of the line, the receiver obtains the preserved authentication results for the original email by 1) verifying that there are no missing ARC-Seal entries and each ARC-Seal entry states that the previous one is valid, and 2) validating the newest AMS (with the highest instance number i), which works similarly to DKIM signature verification discussed previously.
This chain means that even if SPF and DKIM fail for the email at the destination C, C can alternatively choose to validate the email by validating the ARC chain.
That is, assuming C trusts B as an ARC signer, and B signed the authentication results of the original email, then C can trust those signed original results as valid. This same idea, of course, can be arbitrarily extended to an ARC chain of any length if each successive server in the chain trusts the ARC signature of the server before it and the receiver trusts the last one.
Conclusion
With the announcement of the ARC protocol, the trend toward stronger email security via stricter DMARC policies can continue without compromise because ARC will eliminate the common problem of SPF and DKIM failure associated with intermediary email forwarding services. The ARC protocol, at a high level, functions somewhat similarly to a chain of trust used for validating SSL certificates, but it’s specifically geared toward the preservation of trusted email authentication results (from SPF, DKIM, and DMARC) through a multi-hop chain of intermediary services that an email may travel through before reaching its final recipients. As outlined here on DMARCLY in 2019, contrary to the SPF, DKIM, and DMARC protocols, enabling ARC doesn’t require any specific action or DNS updates, as the ARC implementation happens server-side, transparently to senders. Since ARC was published as RFC 8617 in July 2019, its implementation is still in early stages but will certainly speed up, and there are actually already some email services, like Sympa and Google’s Gmail (as one would expect), that are using it.
Please enjoy the following GIF of a chain made of arcs. Yes, I am assuming the edges are directed.
Top comments (0)