Protecting Email with
DMARC
Tim Draegen, February 26th & 27th 2014
What we’re trying to fix.
INTRODUCTION
2
About The Presenter
•
•
•
•
•
•
•
•
mid/late-80’s: Apple IIe programming, FidoNet
early 90’s: x86 programming (fractals!)
mid 90’s to 2000: intern->employee @
2000-2004: three 1-year stints at startups (BSD)
2004-2008: IronPort/Cisco (email security)
2009-2010: Nominum (large DNS software)
2010-2012: Co-founded email intel company
2013-now:
• Message Bus (email@scale software)
• dmarcian.com
3
About The Presenter
•
•
•
•
•
•
•
•
mid/late-80’s: Apple IIe programming, FidoNet
early 90’s: x86 programming (fractals!)
mid 90’s to 2000: intern->employee @
2000-2004: three 1-year stints at startups (BSD)
2004-2008: IronPort/Cisco (email security)
2009-2010: Nominum (large DNS software)
2010-2012: Co-founded email intel company
2013-now:
• Message Bus (email@scale software)
• dmarcian.com
4
Email’s Fundamental Flaw
Anyone can pretend to be you.
5
Let The Receivers Figure It Out?
6
An Insidious Situation
Blocking legitimate email is really bad:
• Support costs = ouch!
• Heads might roll depending on recipient
• In ISP-world, users go somewhere else
There is a terribly thin line between the sloppiest legitimate email
and expertly crafted phishing.
∴ the most effective fraud gets through..
..and criminals are incentivized to get better!
7
Whoops!
8
What’s The Worst That Can Happen?
A sample of spear-phishing: RSA Hack
RSA supplies most of the world with 2-factor authentication systems (“SecurID”)
to protect sensitive data.
Attackers targeted EMC (parent company of RSA) HR teams and used spearphishing to successfully install malware within RSA.
Result?
• $66m RSA loss,
• Stolen SecurID data
• Used to attack:
http://www.f-secure.com/weblog/archives/00002226.html
http://www.theregister.co.uk/2011/07/27/rsa_security_breach/
9
Can The Flaw Be Fixed?
Yes!
10
Technology That Fixes This..
..is called email authentication. Two forms:
SPF (Sender Policy Framework)
• Allows receivers to determine legitimacy based on
where the email comes from.
• “path based”
DKIM (DomainKeys Identified Mail)
• Allows receivers to determine legitimacy based on
content of email.
• “signature based”
11
Lessons Learned From SPF & DKIM
• No consistency to how DKIM and SPF are deployed.
•
•
Receivers used whatever was deployed/available.
Senders tried hard to check the box.
• Receivers couldn’t rely on accuracy of Sender’s auth.
•
As a rule, Senders failed to cover all email, significantly reducing utility.
• Senders had no visibility into email domains usage.
•
Impossible to discover usage through auditing process.
• ROI or “email authentication” didn’t add up
12
Just How Big Is Email?
Facebook
Twitter
Email
Websites
Google+
Total
Accounts
750 million 300 million 2.9 billion
463 million 10 million
Daily
Activity
60 million
updates
3.3 billion
searches
140 million 188 billion
tweets
messages
1 billion
items
shared
http://blogs.smartertools.com/2011/08/29/the-value-of-email/
Email is really big. No centralized control, used by everyone all the time.
Lots of people have been trying to fix this thing for a long time.
..and it’s actually changing!
13
Time
Sender Adoption
Receiver Adoption
2003-2006: building blocks (SPF, DomainKeys, DKIM)
How Long To Fix?
“I’ve heard this helps”
Nice to have as anti-spam input, not reliable
2007-2009: prototype authenticated email model
PayPal innovates, Financial Services publishes recommendations
Yahoo & Gmail reject fake PayPal email, other big providers take note
2010-2011: make it work at internet scale
PayPal funds/organizes effort to standardize the model
Big webmail providers commit to support and implement
2012-2013: early adopters
Senders with fraud and clean infrastructures deploy
Big consumer mailboxes and those that can roll their own deploy
2014: ???
More at: http://forums.dmarcian.com/discussion/25/brief-history
14
14
Complementary Standards
SPF
Path-based (RFC 4408)
Authorized servers published via
simple DNS record
Very low deployment cost
Forwarding breaks SPF
Is the messenger (server) permitted?
DKIM
Signature-based (RFC 6376)
Requires cryptographic operation
by email gateways
Public keys published via DNS
Can survive forwarding
Is the signature authentic?
15
DMARC
• Overlay – Leverages SPF and DKIM as authentication mechanisms
▫ Describes how to deploy SPF and DKIM… consistency
• Visibility – Describes new feedback mechanism
▫ Gives senders visibility into how receivers process their email
• Protection – Senders can declare how to process auth-failing email
▫ Specifies a DNS-based policy model that incorporating SPF + DKIM results
SPF
Path-based (RFC 4408)
Authorized servers published via
simple DNS record
Very low deployment cost
Forwarding breaks SPF
Is the messenger (server) permitted?
DKIM
Signature-based (RFC 6376)
Requires cryptographic operation
by email gateways
Public keys published via DNS
Can survive forwarding
Is the signature authentic?
16
DMARC Meets “Lessons Learned”
• No Consistency to how DKIM and SPF are deployed.
•
•
Receivers used whatever was deployed/available.
Senders tried hard to check the box.
• Receivers couldn’t rely on accuracy of Sender’s auth.
•
As a rule, Senders failed to cover all email, significantly reducing utility.
• Senders had no visibility into email domains usage.
•
Possible to discover usage through auditing process.
• ROI or “email authentication” adds up
17
DMARC Adoption
BIG RECEIVERS:
“ORGANIC” RECEIVERS:
From: https://dmarcian.com/dmarc_adoption/
18
What DMARC Can (and Cannot) Do
DMARC fixes a fundamental flaw:
•
Is this email really from where it says it’s from?
DMARC makes Domain Identifiers a reality:
•
This email really does come from EXAMPLE.ORG!
So what:
•
Strong exact-domain anti-phishing (“Reject the fakers”)
• + telemetry that powers “take down” services (“mitigation providers”)
• Domain reputation, finally! (“Do my users want this email?”)
• Build on it. EG: webmail clients with “Meta inbox” for customer notifications only
19
DMARC As Phishing Prevention
Less malicious email being delivered:
PayPal: customer reports of suspicious email dropped in US by > 70% in 2013
Microsoft: Outlook.com customer reports of phishing dropped > 50% in 2013
Blocked When It Matters:
PayPal: DMARC stopped ~25 million attacks during holiday buying season
Google: reduction of 5000% in spoofing of major corporation during their busiest
season.
Twitter: 45 days monitoring = 2.5 billion spoofing emails. Now all rejected.
Adoption:
December 2013, Google reported > 90% of email received by Gmail users is
now authenticated by DKIM or SPF. > 80,000 domains publishing DMARC
allowing reject.
http://dmarc.org/news/press_release_20140218.html
20
Fraud post-DMARC
When DMARC controls are put into place, criminals move away from your
protected domains. Fraud moves to:
•
•
•
Look-a-like domains*
Cousin domains*
Softer targets
Some have argued that this diminishes the value of DMARC, that investing
heavily into exact-domain anti-phishing is not worth it if criminals will simply
move on to other targets or exploit look-a-like or cousin domains.
These are valid arguments if DMARC is only an exact-domain anti-phishing
measure. (If so, run “p=none” forever and collect fraud intel for analysis,
shutdown, and prosecution.)
* Check with your organization to see if domains have been 21
defensively registered – DMARC reject policy prevents abuse.
BREAKING NEWS!!
DMARC Is Not Just Anti-Phishing
Advanced receivers are finally connecting the dots for email senders:
1. Authentication is required if you’re sending email and expect it to be delivered. This
means DMARC-compliant email.
2. The From:-domain is the reputation building block for the post-anti-spam world. From:domain cannot be trusted unless authenticated, and this means DMARC-compliant email.
3. Goal is email authentication for all email. This means delivery of unauthenticated email
will only continue to get more difficult, with the solution being “authenticate your email”.
Invest heavily in exact-domain anti-phishing via DMARC? Maybe not.
Invest in sending DMARC-compliant email? If you want your email to be delivered!
(and get exact-domain anti-phishing anyway)
https://support.google.com/mail/answer/81126?hl=en
22
BREAK
23
Internet primers for the rest of us.
BASICS
24
Domain Name System (DNS) Basics
Giant distributed key/value store:
• You ask for specific type of resource for key(label)
• “give me X resource for Y label… get back Z answer”
Resources can be:
• A, AAAA, MX, TXT…
Labels can be:
• Dot-separated chunks of 64-byte strings
•
EG: this.is.a.label.com
Answers are based on resource.
25
The DNS Is Very Big
•
Where can I find server for site.com?
•
•
Enormous amount of traffic
X # of root servers. They tell you where to go for answers, EG: dk.example.org:
•
Dear Root Server, please tell me which server answers for DK.EXAMPLE.ORG
•
•
Dear ORG-NAME-SERVER, please tell me which servers answers for DK.EXAMPLE.ORG
•
•
ORG-NAME-SERVER: I can’t tell you about DK.EXAMPLE.ORG, but I can tell you which server is responsible for
EXAMPLE.ORG. That would be…. EXAMPLE-NAME-SERVER
Dear EXAMPLE-NAME-SERVER: please tell me which servers answers for DK.EXAMPLE.ORG
•
•
•
•
ROOT SERVER: no problem, talk to ORG-NAME-SERVER
EXAMPLE-NAME-SERVER: sure thing, DK.EXAMPLE.ORG can be found at 1.2.3.4
The thing asking questions is called a resolver. Usually libraries, found everywhere.
The things providing answers are called name servers. Some are authoritative.
Because traffic volumes can be enormous, resolvers cache results to avoid
hammering name servers. Tradeoff with ability to rapidly change DNS entries.
26
Simple Mail Transport Protocol (SMTP) Basics
SMTP describes how email moves around the Internet. It goes like this:
1.
2.
3.
4.
•
User writes a piece of email to friend@example.org, hits SEND.
Email client connects to outbound server (smtp.sample.net).
Outbound server agrees to deliver email for user.
Server determines where email is going -> the recipient’s domain.
Server issues MX query for EXAMPLE.ORG, gets back list of accepting servers.
5. Server connects to MAIL.EXAMPLE.ORG.
..SMTP conversation now begins..
27
SMTP Conversation
Outbound Email Server (smtp.sample.net)
Receiving Server (mail.example.org)
HELO smtp.sample.net
250 mail.example.org
MAIL FROM: <foe@sample.net>
250 sender <foe@sample.net> ok
RCPT TO: <friend@example.org>
250 recipient <friend@example.org> ok
DATA
354 go ahead
(email content here)
250 ok: Message 17763873 accepted
QUIT
221 mail.example.org
(email now subject to anti-spam and then delivery) 28
Email Content
Composed of 2 things:
1. Headers
2. Body
Return-Path: <foe@sample.net>
Delivered-To: friend@example.org
Authentication-Results: mail.example.org; spf=pass (example.org: domain
of foe@sample.net designates 1.2.3.4 as permitted sender)
smtp.mail=foe@sample.net; dkim=pass header.i=@sample.net
Received: from ..
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=sample.net;
s=february_2014; i=@sample.net; q=dns/txt; h= .. ; bh= .. ; b= ..
Date: Wed, 19 Feb 2014 12:39:06 -0500
From: “Fred“ <foe@sample.net>
To: “Frank Riend” <friend@example.org>
Subject: REMINDER – don’t mess this up, Frank!
Hi, please don’t forget about the meeting.
It’s very important!
Your friend,
Fred
29
DMARC Identifiers
DMARC keys off of:
• From: domain
And looks to reconcile the key with:
• DKIM “d= domain”
• SPF results
30
Identifiers In Content
Return-Path: <foe@sample.net>
Delivered-To: friend@example.org
Authentication-Results: mail.example.org; spf=pass (example.org: domain
of foe@sample.net designates 1.2.3.4 as permitted sender)
smtp.mail=foe@sample.net; dkim=pass header.i=@sample.net
Received: from ..
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=sample.net;
s=february_2014; i=@sample.net; q=dns/txt; h= .. ; bh= .. ; b= ..
Date: Wed, 19 Feb 2014 12:39:06 -0500
DKIM d= domain
From: “Fred“ <foe@sample.net>
To: “Frank Riend” <friend@example.org>
From:
domain
Subject: REMINDER
– don’t
mess this up, Frank!
Hi, please don’t forget about the meeting.
It’s very important!
Your friend,
Fred
31
Identifiers in SMTP Conversation
Outbound Email Server (smtp.sample.net)
Receiving Server (mail.example.org)
HELO smtp.sample.net
250 mail.example.org
MAIL FROM: <foe@sample.net>
Envelope domain 250 sender <foe@sample.net> ok
RCPT TO: <friend@example.org>
250 recipient <friend@example.org> ok
DATA
354 go ahead
(email content here)
250 ok: Message 17763873 accepted
QUIT
221 mail.example.org
(email now subject to anti-spam and then delivery) 32
Real World Complications
Email flows from the user straight to the destination, right?
Unfortunately, no.
• Forwarders..
• Mailing lists..
• Forwarding from old accounts to new
•
•
•
•
•
(perhaps to take advantage of newer UIs)
Fraud..
Anti-spam engines..
Destination down..
Transient errors..
33
Real World Complications
Email flows from the user straight to the destination, right?
Unfortunately, no.
• Forwarders..
• Mailing lists..
• Forwarding from old accounts to new
•
•
•
•
•
(perhaps to take advantage of newer UIs)
Fraud..
Anti-spam engines..
Destination down..
Transient errors..
34
BREAK
35
Domain-based Message Authentication, Reporting & Conformance
DMARC
36
Policy Key
An email’s “From:-header” domain is the policy key for DMARC.
•
•
Lots going on when email is delivered.
Only thing that should be present in email all the time.
•
•
(data shows that it is, when it is not, its malformed junk)
What about Sender: ?
•
•
•
•
Ignored by DMARC.
Multiple policy keys is a broken concept.
No way to give control to domain owner otherwise.
From: = most stable thing around
•
..and as close to user-visible as possible
37
Authenticated Identifiers
•
SPF and DKIM return stable domain-level identifiers.
•
Not all email uses these technologies today, but they are readily
available.
•
SPF and DKIM checks are easy to perform.
•
When checks have been made and results are available to inspect..
38
Authenticated Identifiers
Return-Path: <foe@sample.net>
Delivered-To: friend@example.org
Authentication-Results: mail.example.org; spf=pass (example.org: domain
of foe@sample.net designates 1.2.3.4 as permitted sender)
smtp.mail=foe@sample.net; dkim=pass header.i=@sample.net
Received: from ..
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=sample.net;
s=february_2014; i=@sample.net; q=dns/txt; h= .. ; bh= .. ; b= ..
Date: Wed, 19 Feb 2014 12:39:06 -0500
DKIM authenticated
From: “Fred“ <foe@sample.net>
identifier
To: “Frank Riend” <friend@example.org>
Subject: REMINDERFrom:
– don’t
mess this up, Frank!
domain
Hi, please don’t forget about the meeting.
Your friend,
Fred
It’s very important!
Outbound Email Server (smtp.sample.net)
Receiving Server (mail.example.org)
HELO smtp.sample.net
250 mail.example.org
MAIL FROM: <foe@sample.net>
250 sender <foe@sample.net> ok
SPF authenticated identifier
RCPT TO: <friend@example.org>
250 recipient <friend@example.org> ok
DATA
354 go ahead
(email content here)
250 ok: Message 17763873 accepted
QUIT
221 mail.example.org
39
Identifier Alignment
Why? Receivers need simple way to understand if authentication is relevant.
From:
SPF
DKIM
bank.com
bank.com
(none)
40
Identifier Alignment
Why? Receivers need simple way to understand if authentication is relevant.
From:
SPF
DKIM
bank.com
bank.com
(none)
bank.com
mail.bank.com
(none)
41
Identifier Alignment
Why? Receivers need simple way to understand if authentication is relevant.
From:
SPF
DKIM
bank.com
bank.com
(none)
bank.com
mail.bank.com
(none)
bank.com
banknewsletter.com
(none)
42
Identifier Alignment
Why? Receivers need simple way to understand if authentication is relevant.
From:
SPF
DKIM
bank.com
bank.com
(none)
bank.com
mail.bank.com
(none)
bank.com
banknewsletter.com
(none)
bank.com
banknewsletter.com
bank.com
43
Identifier Alignment
Why? Receivers need simple way to understand if authentication is relevant.
From:
SPF
DKIM
bank.com
bank.com
(none)
bank.com
mail.bank.com
(none)
bank.com
banknewsletter.com
(none)
bank.com
banknewsletter.com
bank.com
bank.com
bank.com
bank.com
44
Identifier Alignment
Why? Receivers need simple way to understand if authentication is relevant.
From:
SPF
DKIM
bank.com
bank.com
(none)
bank.com
mail.bank.com
(none)
bank.com
banknewsletter.com
(none)
bank.com
banknewsletter.com
bank.com
bank.com
bank.com
bank.com
bank.com
news.bank.com
news.bank.com
45
Identifier Alignment
Why? Receivers need simple way to understand if authentication is relevant.
From:
SPF
DKIM
bank.com
bank.com
(none)
bank.com
mail.bank.com
(none)
bank.com
banknewsletter.com
(none)
bank.com
banknewsletter.com
bank.com
bank.com
bank.com
bank.com
bank.com
news.bank.com
news.bank.com
bank.com
crime.net
badguys.com
46
Identifier Alignment
Why? Receivers need simple way to understand if authentication is relevant.
From:
SPF
DKIM
bank.com
bank.com
(none)
bank.com
mail.bank.com
(none)
bank.com
banknewsletter.com
(none)
bank.com
banknewsletter.com
bank.com
bank.com
bank.com
bank.com
bank.com
news.bank.com
news.bank.com
bank.com
crime.net
badguys.com
bank.com
bark.com
(none)
47
DMARC Record Discovery
Receiver gets piece of email, From:-domain = EXAMPLE.ORG. Receiver makes
DNS query for TXT record at label:
_dmarc.example.org
DMARC records are discovered in 1 of 2 ways:
1. Directly: _dmarc.europe.engineering.example.org
2. If no DMARC record at _dmarc.europe.engineering.example.org:
•
•
Check the Organizational Domain:
_dmarc.example.org
No more than 2 DNS queries to determine DMARC records, even if label is huge.
48
DMARC Records
Simple list of tag/values, eg:
v=DMARC1; p=none; rua=mailto:reports@example.org
49
DMARC Record Options
Option
Purpose
Example
Default
v
Protocol version
v=DMARC1
n/a
p
Policy for the domain
p=quarantine
(required)
sp
Policy for subdomains
sp=reject
p= value
% of messages subjected to
policy
pct=20
100
adkim
Alignment mode for DKIM
adkim=s
r
aspf
Alignment mode for SPF
aspf=r
r
rua
Reporting URI of aggregate
reports
rua=mailto:aggrep@example.org
n/a
ruf
Reporting URI for forensic
reports
ruf=mailto:fails@example.org
n/a
rf
Forensic reporting format
rf=afrf
afrf
ri
Aggregate reporting interval
ri=14400
86400
fo
Forensic options
fo={0,1,d,s}
0
pct
50
DMARC Policy
Receivers will enforce policy against unauthenticated email, in 1 of 3 ways:
•
•
•
none
quarantine
reject
The “pct” tag allows for slow rollout.
•
“pct=10” means “enforce policy against only 10% of unauthenticated email”.
•
•
For example: if random number between 1-100 is <= pct, enforce.
If policy is NOT applied due to pct tag, the “next lesser” policy is applied:
•
•
“pct=10; p=reject” means “apply REJECT to 10% of unauth email, QUARANTINE to remaining 90%”
“pct=50; p=quarantine” means “apply QUARANTINE to 50% of unauth email, NONE to remaining 50%”
51
Feedback Types
Aggregate Reports
•
•
•
•
•
XML-based
Daily
Comprehensive view
1 report per receiver
Thousands of rows
Forensic Reports
•
•
•
•
•
MARF-based
Real-time
Only authentication failures
1 per failure @ receiver
Millions/day possible
52
Using DMARC: Outbound
Based on DMARC feedback, senders (domain-owners) can quickly locate and
remediate legitimate sources of email.
•
(this used to be a major problem)
When all domain email is flowing over DMARC, and p=reject is in place, a
new sort of domain-based channel is in place.
•
•
•
Resilient to phishing
Requires authorization (at some point) to send
Can be protected
Domain-based channels are used to segment traffic:
•
•
Send different types of email using different domains/sub-domains
From:-domain is what receivers build email reputation on
53
Using DMARC: Inbound
When processing DMARC-compliant email, decision making becomes very
simple:
Do my recipients want this domain’s email?
DMARC provides the domain-based model that gives receivers something
stable to build on.
When day to day traffic is all DMARC, new stuff (phishing?) can be scrutinized
insanely. Partners can be fast-tracked to prevent false-positives.
Legitimate senders are incentivized to make themselves easy to identify.
54
LUNCH
55
Sender Policy Framework
SPF
56
SPF: What It Is And How It Works
Sender Policy Framework describes how to publish a list of servers that are
authorized to send on behalf of a server.
Receivers check the list of authorized servers against the IP address of the
server that is currently attempting to deliver email. If the connecting IP
address is found in the list of authorized servers, a “pass” results is
returned.
During SMTP time, receivers issue DNS
query for TXT record of domain found in
MAIL FROM command. (If no MAIL
FROM, then HELO domain is used)
Outbound Email Server
(smtp.sample.net)
HELO smtp.sample.net
Receiving Server
(mail.example.org)
250 mail.example.org
MAIL FROM: <foe@sample.net>
250 sender <foe@sample.net> ok
RCPT TO: <friend@example.org>
250 recipient <friend@example.org> ok
DATA
If SPF record is found in returned TXT
resources, then SPF is possible!
354 go ahead
(email content here)
250 ok: Message 17763873 accepted
QUIT
221 mail.example.org
57
SPF Records
SPF records look like:
v=spf1 ip4:1.2.3.4 ip4:6.7.8.0/24 a ~all
“ip4”, “a”, and “all” are called mechanisms: things that yield IP addresses that can
used to match against the connecting IP address.
ip4 / ip6 / a / mx / ptr / all / include / exists
The “~” thing in front of “~all” is called a qualifier: it changes the result of a match.
The default qualifier is “+”, I.E.:
v=spf1 +ip4:1.2.3.4 +ip4:6.7.8.0/24 +a ~all
Qualifiers can be (not including “/”):
+ / - / ? / ~
58
SPF Mechanisms
Mechanism
Purpose
Example
ip4
Explicit IPv4 address / netblock
ip4:192.168.1.1 or
ip4:192.168.0.1/16
ip6
Explicit IPv6 address / netblock
ip6:1080::8:800:
200C:417A/96
a
Lookup A resource for domain
a or a:example.org
mx
Lookup MX for domain, then A for each
mx or mx:examp.org
ptr
ptr
(deprecated)
Lookup PTR for connecting IP address, then A for each
result, then match returned IPs against connecting IP
all
Matches everything
all
include
Authorize servers from different domain include:vendor.com
exists
Match if A record exists for domain
exists:{ir}.rbl.net
59
SPF Macros – DANGER!
Macro
s
Expands to..
The MAIL FROM (or HELO) identity
l (ell) The local-part of the <s> macro
o
The domain-part of the <s> macro
d
The domain where current SPF record comes from
i
The connecting IP address
p
The validated domain of <i> (A -> IP -> PTR -> A, where A matches)
v
“in-addr” if connection over IPv4, “ip6” if IPv6
h
HELO/EHLO domain
Avoid using macros, unless you carry one of these:
60
SPF Qualifiers
Qualifier
Meaning
+
Pass - The matched source is authorized
-
Fail - The matched source is really not authorized
?
Neutral - The matched source is ambiguous
~
SoftFail - The matched source is not authorized
SPF records almost always end in “-all” or “~all”, which means:
and everything else is not authorized
61
The Right Way To Write SPF Records
•
Receivers evaluate SPF records from left to right. Put all of your explicit
mechanisms first, followed by DNS-inducing mechanisms, with includes last.
•
DNS-inducing mechanisms (a, mx, ptr, include) are limited – only 10 mechanisms per
soup-to-nuts SPF lookup.. including any mechanisms listed in “include:”
mechanisms.
•
Use “~all” instead of “-all”, because some people on the internet will drop email if
SPF fails and “-all” is in place. Avoid asbestos-like irritation.
•
If possible, try to list highest-volume sources first, while minimizing DNS queries
•
No need to kill yourself, though, as what’s a DNS query here or there?
62
More on SPF Records
•
Record length can oddly matter. Try to fit SPF into a UDP packet (~500 bytes).
•
DNS time-to-live (TTL) will effect how quickly changes can be made. If you’re
planning on making changes, reduce your TTL so that you’ll be able to make
changes while experimenting. You can turn TTL back up when stable.
•
Publish SPF records for sub-domains. SPF does not “auto discover” SPF
records if they’re not present.
•
Use tools to check your SPF record.
•
•
•
Tools separate humans from most other creatures.
Safe to say: Smart creatures use tools.
You might include other records that are broken.
63
SPF and DMARC
DMARC is shining a light on SPF, both in terms of visibility and by using SPF in
very specific ways.
After ~7 years as “EXPERIMENTAL”, SPF now a real IETF specification.
After years of email nerd wars, SenderID (so-called SPFv2) is dead technology.
If you operate infrastructure that sends on behalf of other domains, segment
that infrastructure and make it easy to be included by those domains.
Not a lot of operators have experience with SPF. If you’re into it, considering
meeting up with like-minded folks and hammering out guidance.
64
SPF Exercises
•
Does your organization publish an SPF record?
•
What servers are authorized to send on behalf of your organization?
•
Pick 3 popular domains and investigate their SPF practice
•
What would you change?
Tools to help:
• dig: “dig example.org TXT +short”
• kitterman.com/spf/validate.html
• dmarcian.com/spf-survey/
65
SPF Deployment
•
fels.dk
•
om.fels.dk
•
wanttodisallowthis.fels.dk
•
fels.dk has a wildcarded TXT record
TRY:
• fels.dk --- explicity record
• om.fels.dk --- explicity record
• Create wildcard record for everything else “v=spf1 –all”
66
BREAK
67
DomainKeys Identified Mail
DKIM
68
How DKIM Works
DKIM describes a way to insert cryptographic signatures into email that link the
email to a domain.
•
Sender processes a piece of email, uses public-key cryptography to create a
signature, and signature is inserted into email as a DKIM-Signature: header.
Everything needed to check the signature is included in header.
•
Receiver detects presence of DKIM-Signature header, processes the piece
of email, and uses public-key cryptography to check if signature matches. If
signature matches, the email was processed (in some form) by the domain.
DKIM provides a stable domain-level identifier that travels with the email.
69
DKIM-Signatures
Here’s a real life DKIM-Signature:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=yahoogroups.com; s=echoe; t=1393079384;
bh=kmukFXBXZ2LCalggiEXX2pc4h9ESv+STtGxZ/NFuN+k=;
h=Received:Received:X-Yahoo-Newman-Id:X-Sender:X-ApparentlyTo:X-Received:X-Received:X-Received:X-Received:X-Received:XReceived:X-Received:X-Received:X-YMail-OSG:X-Received:XRocket-MIMEInfo:X-Mailer:Message-ID:To:X-Originating-IP:XeGroups-Msg-Info:From:X-Yahoo-Profile:Sender:MIMEVersion:Mailing-List:Delivered-To:List-Id:Precedence:ListUnsubscribe:Date:Subject:Reply-To:X-Yahoo-NewmanProperty:Content-Type;
b=5KWzHV7YzWaUURDQW/MKelqHkdy8V/ube+c2P8+c4yX+CFKHPsk9j76G3Y
t25L7DQLU3djFacfVbdZdxz/Y41TmNcq4FVXZ23ZC42m9Ku6AN3uSxLGJm9K
brQ5/P2+pvaJHCNwecnPm1P+EiYu3qsY1FCywYTJ4GxGpkqBKRFfg=
70
DKIM-Signatures
DKIM-Signature:
v=1;
a=rsa-sha256;
c=relaxed/relaxed;
d=yahoogroups.com;
s=echoe;
t=1393079384;
bh=<BLOB>;
h=<list of headers>;
b=<BLOB>
71
DKIM-Signatures
DKIM-Signature:
v=1;
a=rsa-sha256;
c=relaxed/relaxed;
d=yahoogroups.com;
s=echoe;
t=1393079384;
bh=<BLOB>;
h=<list of headers>;
b=<BLOB>
Find the public key!
Issue DNS TXT query to:
<s=>._domainkey.<d=>
Hopefully get back blob of key data.
72
DKIM Public Keys
$ dig echoe._domainkey.yahoogroups.com txt +short
"k=rsa\;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDmsJgfzmZfV10FE4jZ9N
AX62SchSffsRHR/ng8TfS8YT33pdMMcUgthGXCw+n7xZOYyYvbII2OemMv0q
uJLUZfJFfJj2QSwI49qO3K04cUv0pNFt3/ugWzKl65Hgx1pLAoux5hdtJAmU
JKM+kaaLaG6nR/qJT2iALWAGqoB2UhOQIDAQAB"
73
Authentication-Results
Authentication-Results:
mail.eudaemon.net;
dkim=pass (signature verified)
header.i=@yahoogroups.com
In DMARC land:
@yahoogroups.com is the Authenticated Identifier
74
Running DKIM In The Real World
How to allow others to send on your behalf. Several ways:
•
You generate private/public keys, and give other private key. You then
publish the public key in the DNS.
•
Other generates private/public keys, gives you public key to publish in
the DNS.
•
Delegate a subdomain to other to manage.
Please do not use the same keys across your entire organization.
75
Running DKIM In The Real World
•
Key strength: less than 1024 bits is not good enough.
•
Key rotation: you can and should periodically change keys. Selectors
allow organization to sign in parallel, so you can introduce new keys
while waiting for existing key usage to finish up. Then remove old key
after a week.
•
•
See “M3AAWG DKIM Key Rotation BCP”
When building out DKIM, consider TOTAL AUTOMATION as the goal.
•
•
Far less chance of errors.
Push a button to rotate keys if keys get compromised.
•
•
Way better with automation while alarms are going off.
Automate everything including:
•
•
•
Key generation
Key publication
Key rotation
76
Common DKIM Mistakes
•
Using weak crypto. Google will create Auth-Result headers that tell you
if you’re doing this wrong.
•
The “l=“ (ell equals) tag is dangerous.
•
Syntax errors are common in public keys, largely due to cut and paste
introducing unwanted characters.
•
Signing headers that should not be signed.
•
Return-Path
77
DKIM and DMARC
•
DKIM has been used to build reputation. DMARC allows that
reputation to transfer to “From:-domain”.
•
DMARC feedback shows that DKIM is not 100% reliable, sometimes
due to bugs in DKIM stacks.
78
DKIM Exercise
•
Does your organization create DKIM-Signatures?
•
Find a reflector at:
•
•
http://testing.dkim.org/reflector.html
Send your reflector of choice an email.
•
You can also use a webmail account to easily test.
79
BREAK
80
OK, let’s do this.
DMARC IMPLEMENTATION
81
Real World DMARC
Publish DMARC with “p=none”, collect feedback.
Analyze feedback.
Tune SPF, DKIM, Identifier Alignment.
ADVANCED: segment traffic along domains/sub-domains.
Steady-state: Monitor results, periodically review.
1.
2.
3.
4.
5.
Decision point: Can you move to quarantine or reject without impacting your email?
•
How much impact are you willing to tolerate?
Tools:
• DMARC.ORG for resources (stuff to read, links to more)
• Open Source
• Hosted (free, trial, freemium, paid)
• Some commercial exact-domain anti-phishing services
82
Organizational DMARC
Larger organizations might require political support to deploy DMARC.
• (sometimes difficult to get things done across administrative borders)
Does your organization maintain a policy on how to send email?
• (consider inventing one to instill consistency)
Is anyone responsible for the procurement and tracking of domains?
• (might be legal department)
•
•
Production domains? (including websites and other not-email services)
Defensively-registered (aka “parked”) domains?
Who would perform monitoring and periodic review?
• (builds institutional memory, reduces risk of brittle process)
83
Common DMARC Issues
•
•
•
Forwarders
Mailing lists
Services/tools that send on behalf of your domains:
•
•
HR/Talent providers
SAAS-based services
•
•
EG salesforce.com
Services that send on your behalf outside of your domains:
•
•
EG yourdomain.external-service.com
Difficult to find and remediate
•
Check your abuse desk submissions/logs
84
Exercise – Organizational Concerns
1. Do you need C-level support at your organization?
1. Does your organization maintain an email usage policy?
2. Is there an internal function that tracks domain registration?
3. Do you know who would perform rollout and maintenance.
85
Exercise – Create DMARC Record
1. What is your domain?
2. Do you know where to send feedback?
3. Create your record!
v=DMARC1; p=none; rua=mailto:<ADDRESS>
4. Publish it as DNS TXT record at…
_dmarc.<DOMAIN>
86
Exercise - DMARC XML
Break out your DMARC XML.
87
Exercise – Inspect DMARC Records
dmarcian.com/dmarc-inspector/
88
Resources
http://dmarc.org/resources.html
http://www.trusteddomain.org/opendmarc/
http://www.opendkim.org/
http://www.openspf.org/
(REPUTE working group, domain reputation and research)
89
Conclusion
DMARC is a living technology, where the competitive advantage is less fraud
and more trust for everyone.
DMARC is a technical specification, and not a product. Products are supported
by companies, whereas technical specifications are supported by communities.
Feel free to reach out with any questions.
Feel free to reach out to peers for support.
Dig in!
90
Conclusion
DMARC is a living technology, where the competitive advantage is less fraud
and more trust for everyone.
DMARC is a technical specification, and not a product. Products are supported
by companies, whereas technical specifications are supported by communities.
Feel free to reach out with any questions.
Feel free to reach out to peers for support.
Dig in!
91
Internetdagen 2014
Monday September 15
Tivoli hotel
3 tracks:
• Legal
• Danish IGF
• Technical
Organized together with Erhvervsstyrelsen
info@internetdagen.dk
92