protecting email with dmarc n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Protecting Email with DMARC PowerPoint Presentation
Download Presentation
Protecting Email with DMARC

Loading in 2 Seconds...

play fullscreen
1 / 92

Protecting Email with DMARC - PowerPoint PPT Presentation


  • 127 Views
  • Uploaded on

Protecting Email with DMARC. Tim Draegen, February 26th & 27th 2014. What we’re trying to fix. Introduction. About The Presenter. mid/late- 80’s: Apple IIe programming, FidoNet early 90’s: x86 programming (fractals!) mid 90’s to 2000: intern->employee @ 

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Protecting Email with DMARC' - dandre


Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
protecting email with dmarc

Protecting Email with DMARC

Tim Draegen, February 26th & 27th 2014

about the presenter
About The Presenter
  • mid/late-80’s: Apple IIeprogramming, 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@scalesoftware)
    • dmarcian.com
about the presenter1
About The Presenter
  • mid/late-80’s: Apple IIeprogramming, 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@scalesoftware)
    • dmarcian.com
email s fundamental flaw
Email’s Fundamental Flaw
  • Anyone can pretend to be you.
an insidious situation
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!
what s the worst that can happen
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 spear-phishing 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/

technology that fixes this
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”
lessons learned from spf dkim
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
just how big is email
Just How Big Is Email?

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!

how long to fix

Time

Sender Adoption

Receiver Adoption

How Long To Fix?

2003-2006: building blocks (SPF, DomainKeys, DKIM)

“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

complementary standards
Complementary Standards

SPF

DKIM

Is the messenger (server) permitted?

Is the signature authentic?

Path-based (RFC 4408)

Authorized servers published via simple DNS record

Very low deployment cost

Forwarding breaks SPF

Signature-based (RFC 6376)

Requires cryptographic operation by email gateways

Public keys published via DNS

Can survive forwarding

slide16
SPF

DKIM

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

Is the messenger (server) permitted?

Is the signature authentic?

Path-based (RFC 4408)

Authorized servers published via simple DNS record

Very low deployment cost

Forwarding breaks SPF

Signature-based (RFC 6376)

Requires cryptographic operation by email gateways

Public keys published via DNS

Can survive forwarding

dmarc meets lessons learned
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
dmarc adoption
DMARC Adoption

BIG RECEIVERS:

“ORGANIC” RECEIVERS:

From: https://dmarcian.com/dmarc_adoption/

what dmarc can and cannot do
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
dmarc as phishing prevention
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

fraud post dmarc
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 defensively registered – DMARC reject policy prevents abuse.

dmarc is not just anti phishing

BREAKING NEWS!!

DMARC Is Not Just Anti-Phishing
  • Advanced receivers are finally connecting the dots for email senders:
  • Authentication is required if you’re sending email and expect it to be delivered. This means DMARC-compliant email.
  • 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.
  • 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

domain name system dns basics
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.
the dns is very big
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
        • ROOT SERVER: no problem, talk to ORG-NAME-SERVER
      • 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
        • 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.
simple mail transport protocol smtp basics
Simple Mail Transport Protocol (SMTP) Basics
  • SMTP describes how email moves around the Internet. It goes like this:
  • 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.
  • Server connects to MAIL.EXAMPLE.ORG.
  • ..SMTP conversation now begins..
smtp conversation
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)

email content
Email Content
  • Composed of 2 things:
  • Headers
  • 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

dmarc identifiers
DMARC Identifiers
  • DMARC keys off of:
  • From: domain
  • And looks to reconcile the key with:
  • DKIM “d= domain”
  • SPF results
identifiers in content
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

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

DKIM d= domain

From: domain

identifiers in smtp conversation
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>

250 sender <foe@sample.net> ok

Envelope domain

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)

real world complications
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..
real world complications1
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..
policy key
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
authenticated identifiers
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..
authenticated identifiers1
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

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

Outbound Email Server (smtp.sample.net)

Receiving Server (mail.example.org)

HELO smtp.sample.net

250 mail.example.org

DKIM authenticated identifier

MAIL FROM: <foe@sample.net>

250 sender <foe@sample.net> ok

From: domain

RCPT TO: <friend@example.org>

250 recipient <friend@example.org> ok

DATA

354 go ahead

SPF authenticated identifier

(email content here)

250 ok: Message 17763873 accepted

QUIT

221 mail.example.org

identifier alignment
Identifier Alignment
  • Why? Receivers need simple way to understand if authentication is relevant.
identifier alignment1
Identifier Alignment
  • Why? Receivers need simple way to understand if authentication is relevant.
identifier alignment2
Identifier Alignment
  • Why? Receivers need simple way to understand if authentication is relevant.
identifier alignment3
Identifier Alignment
  • Why? Receivers need simple way to understand if authentication is relevant.
identifier alignment4
Identifier Alignment
  • Why? Receivers need simple way to understand if authentication is relevant.
identifier alignment5
Identifier Alignment
  • Why? Receivers need simple way to understand if authentication is relevant.
identifier alignment6
Identifier Alignment
  • Why? Receivers need simple way to understand if authentication is relevant.
identifier alignment7
Identifier Alignment
  • Why? Receivers need simple way to understand if authentication is relevant.
dmarc record discovery
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:
  • Directly: _dmarc.europe.engineering.example.org
  • 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.
dmarc records
DMARC Records
  • Simple list of tag/values, eg:
  • v=DMARC1; p=none; rua=mailto:reports@example.org
dmarc policy
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%”
feedback types
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
using dmarc outbound
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
using dmarc inbound
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.
spf what it is and how it works
SPF: What It Is And How It Works

Outbound Email Server (smtp.sample.net)

Receiving Server (mail.example.org)

HELO smtp.sample.net

250 mail.example.org

  • 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.

MAIL FROM: <foe@sample.net>

250 sender <foe@sample.net> ok

RCPT TO: <friend@example.org>

250 recipient <friend@example.org> ok

DATA

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)

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

spf records
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 “/”):
  • + / - / ? / ~
spf macros danger
SPF Macros – DANGER!

Avoid using macros, unless you carry one of these:

spf qualifiers
SPF Qualifiers

SPF records almost always end in “-all” or “~all”, which means:

and everything else is not authorized

the right way to write spf records
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?
more on spf records
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.
spf and dmarc
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.
spf exercises
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/
spf deployment
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 --- explicityrecord
  • Create wildcard record for everything else “v=spf1 –all”
how dkim works
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.
dkim signatures
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-Apparently-To:X-Received:X-Received:X-Received:X-Received:X-Received:X-Received:X-Received:X-Received:X-YMail-OSG:X-Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:To:X-Originating-IP:X-eGroups-Msg-Info:From:X-Yahoo-Profile:Sender:MIME-Version:Mailing-List:Delivered-To:List-Id:Precedence:List-Unsubscribe:Date:Subject:Reply-To:X-Yahoo-Newman-Property:Content-Type; b=5KWzHV7YzWaUURDQW/MKelqHkdy8V/ube+c2P8+c4yX+CFKHPsk9j76G3Yt25L7DQLU3djFacfVbdZdxz/Y41TmNcq4FVXZ23ZC42m9Ku6AN3uSxLGJm9KbrQ5/P2+pvaJHCNwecnPm1P+EiYu3qsY1FCywYTJ4GxGpkqBKRFfg=
dkim signatures1
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>
dkim signatures2
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.

dkim public keys
DKIM Public Keys
  • $ dig echoe._domainkey.yahoogroups.comtxt +short
  • "k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDmsJgfzmZfV10FE4jZ9NAX62SchSffsRHR/ng8TfS8YT33pdMMcUgthGXCw+n7xZOYyYvbII2OemMv0quJLUZfJFfJj2QSwI49qO3K04cUv0pNFt3/ugWzKl65Hgx1pLAoux5hdtJAmUJKM+kaaLaG6nR/qJT2iALWAGqoB2UhOQIDAQAB"
authentication results
Authentication-Results
  • Authentication-Results:
  • mail.eudaemon.net;
  • dkim=pass (signature verified) header.i=@yahoogroups.com

In DMARC land:

@yahoogroups.com is the Authenticated Identifier

running dkim in the real world
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.
running dkim in the real world1
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
common dkim mistakes
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
dkim and dmarc
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.
dkim exercise
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.
real world dmarc
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.
  • 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
organizational dmarc
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)
common dmarc issues
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
exercise organizational concerns
Exercise – Organizational Concerns
  • Do you need C-level support at your organization?
  • Does your organization maintain an email usage policy?
  • Is there an internal function that tracks domain registration?
  • Do you know who would perform rollout and maintenance.
exercise create dmarc record
Exercise – Create DMARC Record
  • What is your domain?
  • Do you know where to send feedback?
  • Create your record!
  • v=DMARC1; p=none; rua=mailto:<ADDRESS>
  • Publish it as DNS TXT record at…
  • _dmarc.<DOMAIN>
exercise dmarc xml
Exercise - DMARC XML
  • Break out your DMARC XML.
exercise inspect dmarc records
Exercise – Inspect DMARC Records
  • dmarcian.com/dmarc-inspector/
resources
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)
conclusion
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!
conclusion1
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!
internetdagen 2014
Internetdagen 2014
  • Monday September 15
  • Tivoli hotel
  • 3 tracks:
  • Legal
  • Danish IGF
  • Technical
  • Organized together with Erhvervsstyrelsen
  • info@internetdagen.dk