The feds are deploying DMARC

The US National Cybersecurity Assessments & Technical Services Team have issued a mandate on web and email security, including TLS+HSTS for web servers, and STARTTLS+SPF+DKIM+DMARC for email.
It’s … pretty decent for a brief, public requirements doc. It’s compatible with a prudent rollout of email authentication.

  • Set up a centralized reporting repository for DMARC failure and aggregate reports.
  • Within 90 days, turn on opportunistic TLS, deploy SPF records, deploy DKIM and set up DMARC with p=none and an email address for reporting.
  • Within 120 days, disable weak TLS ciphers.
  • Within one year, migrate to p=reject.

The TLS requirements are sensible, and should be easy enough to roll out – and there’s likely enough time to work with vendors when it inevitably turns out that some servers can’t comply.
Best, it allows for a period of up to nine months of sending email with DMARC in monitoring-only mode with p=none. That, combined with a centralized repository for DMARC reports means that they should have enough visibility into issues to be able to resolve them before migrating to p=reject.
It all suggests a more realistic approach to DMARC timescales and issue monitoring during rollout than many organizations have shown.
They also have one of the clearer layman introductions to email authentication I’ve seen at https://cyber.dhs.gov/intro/.
Much of the content is well worth borrowing if you’re planning your own authentication upgrades; it’s all released CC0 / public domain (and the markdown source is at github).
 

Related Posts

A brief history of TXT Records

txt
When the Domain Name System was designed thirty years ago the concept behind it was pretty simple. It’s mostly just a distributed database that lets you map hostname / query-type pairs to values.
If you want to know the IP address of cnn.com, you look up {cnn.com, A} and get back a couple of IP addresses. If you want to know where to send mail for aol.com users, you look up {aol.com, MX} and you get a set of four hostname / preference pairs back. If you want to know the hostname for the IP address 206.190.36.45 you look up {45.36.190.206.in-addr.arpa, PTR} and get a hostname back.
There’s a well-defined meaning to each of those query types  – A is for IP addresses, MX is for mailservers, PTR is for hostnames – and that was always the intent for how DNS should work.
When DNS was first standardized, though, there was one query type that didn’t really have any semantic meaning:

Read More

Tools!

I just added a DMARC validation tool over on tools.wordtothewise.com.

You can give it a domain – such as ebay.com – and it will fetch the DMARC record, then explain and validate it. Or you can paste the DMARC record you’re planning to publish into it,  to validate it before you go live.
If you’ve not seen our tools page before, take a look. As well as DMARC we have a DKIM validator, SPF expander and optimizer, general DNS lookup tools, a bunch of RFCs covering all sorts of protocols, and base64 and quoted-printable decoders.
There’s also a widget that lets you add those little unicode pictures to your subject lines, whether you need a snowman ⛄, a forest ????, or a pig getting closer ???.
The results pages all have easily copyable URLs so they’re pretty good for sharing with co-workers or customers if you need that sort of thing.
(And if you need a cidr calculator, whois, or easy access to abuse.net & Microsoft SNDS check out Al’s xnnd.com.)

Read More

Ask Laura: Can you help me understand no auth / no entry?

AskLaura_Heading3
Dear Laura,
I’m a little confused by the term “no auth / no entry”. Gmail and other major receivers seem to be moving towards requiring authentication before they’ll even consider delivery.
Does this just mean SPF and DKIM, or does this mean the much more stringent DMARC, as well?
Thanks,
No Shirt, No Shoes, No What Now?

Read More