[dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM

Terry Zink <tzink@exchange.microsoft.com> Mon, 01 April 2013 21:15 UTC

Return-Path: <tzink@exchange.microsoft.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55CD21E80A5 for <dmarc@ietfa.amsl.com>; Mon, 1 Apr 2013 14:15:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.399
X-Spam-Level:
X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_41=0.6, J_CHICKENPOX_42=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8z2ukpCzWwz for <dmarc@ietfa.amsl.com>; Mon, 1 Apr 2013 14:15:18 -0700 (PDT)
Received: from na01-sn2-obe.outbound.o365filtering.com (na01-sn2-obe.ptr.o365filtering.com [157.55.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCD221E803C for <dmarc@ietf.org>; Mon, 1 Apr 2013 14:15:18 -0700 (PDT)
Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB604.namsdf01.sdf.exchangelabs.com (10.255.109.166) with Microsoft SMTP Server (TLS) id 15.0.670.5; Mon, 1 Apr 2013 21:15:17 +0000
Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.123]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.123]) with mapi id 15.00.0670.000; Mon, 1 Apr 2013 21:15:16 +0000
From: Terry Zink <tzink@exchange.microsoft.com>
To: "dmarc@ietf.org" <dmarc@ietf.org>
Thread-Topic: Proposing an extension to DMARC to optionally require SPF and DKIM
Thread-Index: Ac4vHeGtF3P4hm3YSDmZ3O/llvHH6g==
Date: Mon, 01 Apr 2013 21:15:15 +0000
Message-ID: <55b1222360ab4215a09a54da800d261b@BL2SR01MB605.namsdf01.sdf.exchangelabs.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.255.124.132]
x-forefront-antispam-report: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BL2SR01MB604; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: DuplicateDomain-6c178e33-aecb-4786-8220-9afceeddbaf3.exchange.microsoft.com
Subject: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmarc>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2013 21:15:20 -0000

Hi, everyone,

I am proposing an extension to DMARC. Whereas today DMARC requires one of a DKIM pass or SPF pass, I propose we extend DMARC so that is has the *option* to require both.

This is going to be a long post (sorry), but here's why:

My company (Microsoft Forefront) runs a shared service. Other companies like GoDaddy and MessageLabs would have similar issues. Because we are a shared service, a larger set of customers use our limited set of outbound IPs to relay email to the rest of the world. We scan this email for spam and take action appropriately if we find a company or user is sending too much of it.

Here's what it looks like with a set of fictional names if they were all our customers and were using us for outbound mail:

1. example.com ----+
                   |
2. BigBank.com ----+----> Microsoft Forefront IPs ----> Internet
                   |
3. Learning.edu ---+

Each of these customers would put the following into their SPF records:

"v=spf1 ip4:<their own IPs> ip4:<Microsoft IPs>"

This means that a message going from bob@example.com to joe@hotmail.com would undergo two SPF checks:

1. The first is when example.com sends the message to us for relaying to the Internet. We look up the SPF record for example.com, see it is coming from example.com's IP range, and it passes the check.
2. The second is when the message arrives at joe@hotmail.com. Hotmail looks up the SPF record for example.com, sees it is coming from Microsoft Forefront's IP range, and it passes the check.

In this scenario, everything is well and good.

We know every IP that is associated with each of our customers. However, we do not know every single domain associated with them. For example, BigBank.com might have the following sending domains:

- bigbank.com
- email.bigbank.com
- security.bigbank.com
- littlebank.com
- us.bigbank.com
- uk.bigbank.com
- cn.bigbank.com
- partner.com

And so forth. We may only know about bigbank.com (the customer goes into the admin portal and manually enters them in). Sometimes, bigbank.com will send email from communications@uk.bigbank.com. This is an acceptable scenario. We don't know about all their domains, but we scan the message and it is clean and so we relay it to the Internet. They've even set up their SPF record properly. This is not the only valid case when this occurs (sending mail from domains they have not told us about previously), but it is one of them.

In this scenario, everything is well and good. (As an aside, our internal data indicates that the majority of this type of "unattributed" mail is non-spam. I have to explain this to executives every time they want to shut it down every two years; this capability is very popular with customers).

Let's assume that BigBank.com has been dutiful and has published a DMARC record. The problem occurs when Learning.edu gets compromised and starts sending out spam. If a user starts sending out spam from joe@learning.edu, we can detect this and shut it down. But what happens if they start sending out mail as security@bigbank.com? 

example.com ------------+
                        |
BigBank.com ------------+----> Microsoft Forefront IPs ----> Internet
                        |
Learning.edu            |
 security@bigbank.com --+
 
If this is a zero-day attack, when the message hits Microsoft, we may not detect it as spam and it gets relayed to the outside world (perhaps BigBank.com uses a ~all in their SPF record). What happens when it hits Hotmail? Well, Hotmail performs a DMARC check.

There's no DKIM record, so Hotmail performs an SPF check on BigBank.com. It sees that the mail came from Microsoft Forefront's IPs, and lo-and-behold, Microsoft Forefront's IPs are listed in BigBank's SPF record! Therefore, this passes a DMARC check.

But it shouldn't have passed! Not only should this have failed, it's worse than failing because Hotmail believes that this message *is* from BigBank.com but it's a spoofed message! Shared services are susceptible to this problem.

And this is why I propose an optional extension to DMARC. Rather than DMARC requiring SPF or DKIM, what if DMARC let a domain specify SPF *and* DKIM? Let's look through what would happen in my above example:

1. Hotmail performs an SPF validation on BigBank.com and it passes, even though it really came through a compromised account from learning.edu.
2. Hotmail performs a DKIM validation on BigBank.com and it fails because learning.edu does not know BigBank's private DKIM key.

However, since BigBank.com says both SPF and DKIM must pass, this will fail a DMARC validation. This is the case we want to catch - spoofing of users behind shared IP space.

I propose we extend the DMARC specification by extending the syntax. From http://dmarc.org/draft-dmarc-base-00-02.txt, section 6.2:

   adkim:  (plain-text; OPTIONAL, default is "r".)  Indicates whether or
      not strict DKIM identifier alignment is required by the Domain
      Owner.  If and only if the value of the string is "s", strict mode
      is in use.  See Section 4.2.1 for details.

   aspf:  (plain-text; OPTIONAL, default is "r".)  Indicates whether or
      not strict SPF identifier alignment is required by the Domain
      Owner.  If and only if the value of the string is "s", strict mode
      is in use.  See Section 4.2.2 for details.

We could do something like add the letter "p" which means that the mechanism *must* pass. So, if BigBank.com had the following:

adkim=p aspf=p

It would mean that the domain BigBank.com requires both DKIM and SPF to pass, and they are both in relaxed mode since it defaults to r. Or we could make this explicit:

adkim=rp aspf=rp

...where the first letter is strict vs. relaxed identifier alignment and the second is whether or not it must pass.

Extending DMARC this way lets brands/domains protect their outbound reputation behind a shared service without worrying whether or not some other customer will spoof them.

Make sense?


-- Terry Zink | Program Manager - Antispam | My Antispam Blog