Cost of authentication

At the end of last year, Steve wrote a post about the different types of authentication. I thought I’d build on that and write about the costs associated with each type. While I know a lot of my readers are actually on the sending side, I’m also going to talk about the costs associated with the receiving side and a little bit about the costs for intermediaries such as CRM systems or ESPs.

Icon of an eye looking around

SPF

Overall, SPF is a cheap technology to deploy for almost everyone. The type of authentication is prone to breakage from standard email processing, including forwarding.

Sending

SPF is very cheap to implement for senders. A couple hours, tops, for someone to identify what domains are used in the 5321.from address, what IPs they send from and to write a SPF record to cover them. The cost of maintaining SPF is minimal, with records only needing to be revisited when servers and domains change.

Receiving

For receivers, there’s a little more cost involved in deployement but still reasonably cheap. The receiving system has to add code to do a DNS TXT lookup on the domain in the 5321.from and compare that to the IP address sending the mail. They then have to implement a decision pathway and email handling. But, overall, it’s not that expensive to do. The cost of maintaining this is minimal.

SPF requires at least one, sometimes more, DNS lookups incurring a small cost in computing resources.

Intermediary

In this case, the intermediaries may have the most expensive deployment process. Even then, the expense is mostly in documentation and publishing ranges for their customers to use. The cost of maintaining SPF is minimal.

DKIM

The cost of deployment for DKIM increases over that of SPF although for most groups it’s not that much more. At the same time it provides a less fragile authentication than SPF.

Sending

Whether a sender runs their own MTA or is using a 3rd party deployment costs are pretty similar. The sender needs to generate a public/private key pair, install the private key on the sending server and publish the public key in DNS. The cost to doing this is low for senders using a MTA that understands DKIM.

For senders needing to upgrade their MTA, the cost is more, but really, DKIM has been around for more than a decade, it’s probably time to upgrade anyway. If a sender rotates their keys regularly (a recommended best practice (RFC5863, DMARC working group, MAAWG) this does incur a small cost.

DKIM requires a cryptographic hash to be computed for each email sent, which does incur a small cost in computing resources.

Receiving

The cost to a receiver to deploy DKIM checking is similar to that of deploying SPF checking. There needs to be a way to check a DKIM signature at, or close to, the time of delivery. Then they need to have a clear idea of what happens when a signature passes or when it fails.

DKIM requires a DNS lookup for the public key and a cryptographic hash to be computed for each email received, incurring a small cost in computing resources.

Intermediaries

As with SPF, intermediaries may actually have the most expensive deployment costs. They have all the same costs as a regular sender implementing signing including enabling DKIM signing, generating keys and publishing DNS records.

In addition to these costs, many intermediaries are expected to allow their own customers to sign with custom d= domains. This means creating processes for accepting private keys from customers, enabling signing with many different domains (and ensuring that the right key signs for the right customer), and having the ability to sign with their own domain as well. Furthermore, they need to have documentation and support for customers who want to do this.

Ongoing costs are minimal.

DMARC

DMARC can be an expensive technology to deploy, for all parties.

Sending

In order for senders to deploy DMARC across their entire organisation, they need to do, at a minimum, the following:

  1. Identify every outgoing source of email from their organisation;
  2. Check to see if SPF or DKIM authentication uses the organisational domain for authentication;
  3. Update any authentication that does not align to authentication that aligns;
  4. Configure a reporting address to receive reports about email that fails DMARC;
  5. Create processes to handle DMARC failure reports;
  6. Publish a DMARC record;
  7. Regularly review DMARC failure reports to identify legitimate sources of email failing DMARC.

If, for whatever reasons, the whole organisation can’t or won’t go to full DMARC protection, there is an abbreviated deployment. This involves using a subdomain for the DMARC authenticated mailstream separate from the domain used for email from the rest of the organisation. In this case, the steps are as follows:

  1. Create a specific subdomain for DMARC authenticated email to use;
  2. Set up SPF and DKIM authentication for that specific domain;
  3. Configure a reporting address to receive reports about email that fails DMARC;
  4. Create processes to handle DMARC failure reports;
  5. Publish a DMARC record;
  6. Regularly review DMARC failures to ensure legitimate mail is not failing DMARC.

DMARC deployment can be very expensive although it’s slightly less expensive to do a partial deployment on a subdomain.

Ongoing costs, even when everything is going fine, can also be substantial, particularly if the reporting scheme is simply paying one of the third parties to handle reports for you.

Receiving

Companies receiving mail who want to participate in DMARC need to create a process where they evaluate incoming mail for alignment and act on it according to how that ISP interprets DMARC policy statements. This can involve significant costs.

If a company wants to provide DMARC reports back to senders, then they also need a way to generate the reports and send email based on the DMARC policy statements. Again, deployment can be expensive.

Ongoing costs vary, but are unlikely to be excessive.

Intermediaries

Companies sending mail on behalf of other companies, have costs as well, but in the case of DMARC their costs aren’t higher than other groups. They simply need to ensure that their system is able to send customer mail that is aligned. Some intermediaries built in the ability to support custom SPF and DKIM when they initially deployed the technology. These companies had no extra costs when it came to supporting DMARC. Other companies did not, and had to build the systems and processes to support custom SPF and DKIM in order to support DMARC

Conclusion

When we look at the evolution of authentication, we see an increase in costs for each new type of authentication. One of the challenges with DMARC adoption is the cost. Overall, SPF and DKIM were cost effective for most companies to implement and they don’t cost too much to maintain. DMARC, though, is expensive and complicated to implement. A lot of the slow adoption is due to the cost and the lack of a clear and persistent benefit.

The next “stage” of authentication is BIMI, which is building on DMARC. BIMI is another technology that will be expensive to deploy, both for sending organisations and receiving organisations. Whether or not the benefits outweigh the costs remains to be seen.

Related Posts

Ask Laura: Confused about Authentication

AskLaura_Heading3

Read More

What to expect in 2016

WttWColorEye_forBlogI don’t always do predictions posts, even though they’re  popular. Most years I skip them because I don’t see major changes in the email space. And, I’m not the type to just write a prediction post just to post a prediction.
This year, though, I do see changes for everyone in the email space. Most of them center on finally having to deal with the technical debt that’s been accumulating over the past few years. I see ISPs and ESPs spending a lot of development effort to cope with the ongoing evolution authentication requirements.
When people started seriously looking at how to authenticate email, the first goal was getting organizations to implement the protocols. This was a practical concession; in order for a new protocol to be used it needs to be widely implemented. Phase one of authenticating email was simply about publishing protocols and getting organizations to use them.
During phase one, the organization that authenticated a mail hasn’t been important. In fact, the SPF spec almost guarantees that the ESP domain is the authenticated domain. In DKIM, the spec says any domain could sign as long as they could publish a public key in that domain’s domainkeys record.
ESPs took full advantage of this and lowered their own development overhead by taking most of the authentication responsibility on themselves. Their domains were in the 5321.from and they published the SPF records. Domains they control were in the d= and they generated and published the DKIM keys. Mail was authenticated without ESP customers having to do much.
We’ve hit the end of phase one. Most of the major players in the email space are authenticating outbound email. Many of the major players are checking authentication on the inbound. Phase one was a success.
We’re now entering phase two, and that changes thing. In phase two, SPF and DKIM are used as the foundation for user visible authentication. Neither SPF nor DKIM were designed to be user visible protocols. To understand what they’re authenticating you have to understand SMTP and email. Even now there are days when I begin talking about one of them and have to take a step back and think hard about what is being authenticated. And I use these things every day!
DMARC is the first of these end user visible protocols built on SPF and DKIM. It uses the established and widespread authentication to validate the user visible from address. This authentication requires that the d= value or the 5321.from address belong belong to the same domain in the visible from address. While you can pick whether the alignment between the visible from and the authentication is “strict” or “relaxed” you have no choice about the alignment.
Prior to DMARC no one really paid much attention to the domain doing the authentication. Authentication was a yes or a no question. If the answer was yes, then receivers could use the authenticated domain to build a reputation. But they weren’t really checking much in the way of who was doing the authentication.
In the push to deploy authentication, ESPs assumed the responsibility for authentication deployed ESPs took the responsibility and did most of the work. For many or most customers, authentication was as simple as clicking a checkbox during deployment. Some ESPs do currently let customers authenticate the mail themselves, but there’s enough overhead in getting that deployed that they often charged extra to cover the costs.
DMARC is rapidly becoming an expectation or even a full on requirement for inbox delivery. In order to authenticate with DMARC, the authenticating domain must be in the same domain space as the visible from. If senders want to use their own domain in the visible from, DNS records have to be present in that domain space. Whether it’s a SPF TXT record or a domainkeys record the email sender customer needs to publish the correct information in DNS. Even now, if you try to authenticate with DKIM through google apps, they require you to publish DNS records.
ESPs aren’t in a situation where they can effectively manage authentication alignment for all their customers. Hosting companies are in even worse shape when it comes to letting customers authenticate email. Developers are facing the fact they need to go back and rework their authentication code. Businesses are facing the fact they need to change their processes so customers can authenticate with DMARC.
It’s not just the infrastructure providers that are facing challenges with authentication. Senders are going to discover they can no longer hand authentication off to their ESPs and not worry about it. They’re going to have to get DNS records published by their own staff.
Getting DNS updates through some big companies is sometimes more difficult than it should be. I had one client a few years ago where getting rDNS changed to something non-generic took over a month. From an IT standpoint, changing DNS should require approvals and proper channels. Marketers may find this new process challenging.
And, if organizations want to publish reject policies for their domains, then they will have to publish records for every outside provider they use. Some of those providers can’t support DMARC alignment right now.
In 2016 a lot of companies will discover their current infrastructure can’t cope with modern authentication requirements. A lot of effort, both in terms of product development and software development, will need to be spent to meet current needs. This means a lot of user visible features will be displaced while the technical debt is paid.
These changes will improve the security and safety of email for everyone. It won’t be very user visible, which will give the impression this was a slow year for email development. Don’t let that fool you, this will be a pivotal year in email.

Read More

Spam, Phish or Malware?

Some mornings I check mail from my phone. This showed up this morning.
PizzaHutMail
My first thought was “oh, no, Pizza Hut is spamming, wonder who sold them my address.”
Then I remembered that iOS is horrible and won’t show you anything other than the Friendly From and maybe it was some weird phishing scheme.
When I got to my real mail client I checked headers, and sure enough, it wasn’t really from Pizza Hut. I’m guessing actually malware, but I don’t have a forensics machine to click the link and I’m not doing it on anything I can’t wipe (and have isolated from the rest of my network).
The frustrating thing for me is that this is an authenticated email. It not from Pizza Hut, the address belongs to some company in France. Apparently, that company has had their systems cracked and malware sent through them. Fully authenticated malware, pretending to be Pizza Hut, and passing authentication on various devices.
Pizza Hut isn’t currently publishing a DMARC record, but in this case, a DMARC record for Pizza Hut wouldn’t matter. None of the email addresses in the headers point to Pizza Hut.
I spent last week listening to a lot of people discussing DMARC and authentication and protecting people from scams and headers. But those all the protocols in the world won’t protect against this kind of thing. Phishing and malware can’t be fixed by technology alone. Even if every domain on the planet published a p=reject policy, mail like this would still get through.
 
 
 

Read More