Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 01 Nov 2014 18:09:54 +0900

Douglas Otis writes:

 > As such, using the terms authenticates and authentication should
 > not be used when referring to DKIM or SPF results.  Nothing is
 > being authenticated.

I'm confused.  The sending domain is being authenticated, as well as
as much content as is signed (none for SPF, at least the From and
DKIM-Signature fields for DKIM).  Otherwise there's no point to either
protocol.  Of course, DKIM does NOT ensure that the use of the Author
Domain is *authorized* (unless the author domain is the signing
domain, it which case it seems reasonable to presume authorization),
but it is *authentic* in the sense of being used as the sending domain
intended.

Or are you referring to the fact that these protocols don't put any
requirements on the security of the DNS?

 > The real function is verification of an authorization.

I think you are overcomplicating things here, and I don't understand
why.

We *identify* a terminal of a channel (here by using the IP address
for SPF and the DKIM-Signature for DKIM), then *authenticate* that
identity, and finally accept its communications as *authorized* when
accompanied by an appropriate (secure) token from an "authority".  In
many cases the identity is the token (as when a user is authorized to
access a file because she is the owner).

In the case of a domain publishing an SPF "policy", the nature of the
protocol is essentially that "anything from these hosts is authentic
and authorized" (the identity == sending IP is the authorization
token).  If you don't want to say that, don't publish any hosts with
your restrictive SPF policy.

Analogously for DKIM, as far as I can see.  The signed part of a
message is similarly self-authorizing if the signature is valid, and
if you don't like that, don't sign anything and use some other
protocol.  I suppose here you also need DMARC or other policy protocol
to actually announce that you aren't sending any authentic mail with
DKIM signatures.

Agreed, there are good reasons to demand From alignment.  This can be
is authenticated by DKIM (assuming the DNS and MTA have not been
subverted), and I suppose SPF (but in a world of virtualization and
shared resources I'm not so sure about SPF).

Again agreed, these don't identify users.  But nobody in the mailbox
provider game seems to care about that anyway.

 > Section 2,
 > 
 > Was:
 >    However, there has been
 >    no single widely accepted or publicly available mechanism to
 >    communicate domain-specific message authentication policies, or to
 >    request reporting of authentication and disposition of received mail.
 > 
 > Should be:
 >    However, there has been
 >    no single widely accepted or publicly available mechanism to
 >    communicate domain-specific message verification policies, or to
 >    request reporting of verification and disposition of received mail.

This is also inaccurate, however.  Nothing about the message is
verified by any of these protocols, except the sending domain (and in
the case of DKIM, the integrity of the signed portion of message can
be verified).  If you want to be more specific, you could write
"authentication of the sending domain and the signed portion of the
message, if any."  (Again, unless you want to question the use of the
DNS as a source of authentication information.  But I think that is
outside of the scope of these protocol documents, let alone of the WG.)

 > Was:
 >    As a result, senders who have implemented email authentication have
 >    had difficulty determining how effective their authentication is, and
 >    use of authentication failures to filter mail has not been a success
 > 
 > Should be:
 >    As a result, senders implementing email authorization schemes have
 >    had difficulty determining how effective their authorization is, and
 >    use of authorization failures to filter mail has not been a success.

I think this is exactly correct as "was".  I think that in the case
where *authentic* communications are *authorized* implicitly, we
should use the weaker term.

 > Section 2.2
 >  Was:
 >  o  authentication of entities other than domains, since DMARC is
 >     built upon SPF and DKIM which authenticate domains; and
 > Should be:
 >  o authorizations of entities other than domains, since DMARC is
 >    built upon SPF and DKIM which authorizes domains; and 

These and following changes are clearly incorrect, because
"authorization of domains" is done by domain registrars, not by the
domains.  Do you mean "authentication" -> "verification" as above?  (I
still think this is better as "was", but I'm trying to understand your
intent here.)

Regards,
Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 2 Nov 2014 01:42:49 -0700

>    request reporting of verification and disposition of received mail.

This is dangerously misleading, because the message (as a whole) is most
assuredly not being verified by any of the three mechanisms in play here.

At this late stage in this document's life cycle, I would rather refer to
or even copy Section 1.5.2 of RFC7001 if this is actually a point of
confusion, but I don't have any evidence in hand that it is.

>  Although DMARC requires subsequent format checks of the From header
> field, it does not do this with the Subject line which often permits
> injectable clickable URLs.
>

The base document is not open for dealing new technical issues.  The only
edits being considered at this point are purely editorial or presentation
improvements, or minor corrections to existing technical stuff.

If the working group wants to take a run at reopening the base document
later and possibly put that version on the Standards Track, it is chartered
to do so (Phase III), but that milestone is a long way off.  Tim said back
in August that such issues can be collected in the WG's tracker and
revisited at that time.  If you wish to have this listed in that way, let
him know.

As was done with the DKIM deployment RFCs, the same has been done for
DMARC. It seems neither DKIM nor DMARC follow the path of least
astonishment.
>
> If history is any sort of predictor, DMARC will be gamed whenever receivers follow the path of least resistance and trust the *Authentication* results contained within messages.
>
> It seems unfortunate that Internet Identified Mail was not adopted because it passed the public key within the message which was seen as causing too much message overhead.  Now, rather than correcting the DKIM validation process, domains are now expected to list all the headers used twice in each and every message.  As such, it seems IIM would now have been the better choice.
>
> It is very dangerous to over sell the function of SPF and DKIM.  Both of these mechanisms are experiencing increased exploitation in highly critical areas.  It is unfortunate it took until May of 2014 for a major provider to finally acknowledge the nature of these exploits, although they had been explained much earlier in appeals and magazine articles.
>
> Unless DKIM is repaired, both the DKIM Deployment and DMARC BCPs drafts are sorely lacking much needed guidance.  Guidance many are likely to find astonishing.
>
>
I suggest that this is an entirely inappropriate time and venue to be
resurrecting these same old claims, especially the ones about breakage in
other protocols as "fixing" them is nowhere near our charter.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 02 Nov 2014 09:28:58 -0500

On Sunday, November 02, 2014 01:42:49 Murray S. Kucherawy wrote:
...
> DMARC. It seems neither DKIM nor DMARC follow the path of least

Not quite.  There was an actual DKIM working group that produced standards 
track documents that, due to an actual technical issue they found, broke 
backward compatibility with existing DK key records.  DMARC was developed 
outside the IETF and submitted via the ISE.  Not at all the same (nor the 
least astonishing from my PoV).

Not that it's going to change at this point, but let's not overdo the claims 
of business as usual.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Mon, 3 Nov 2014 12:04:09 -0800

> requirements on the security of the DNS?

Dear Stephen,

With SPF, it is fairly common to find authorizations from hundreds or even thousands of different domains.  Nothing based on SPF confirms a purported domain is not being spoofed by one of the other authorized IP addresses of other domains.  A Botnet spoofing technique seeing increased use, such as by the Kelios Botnet.  After all, DMARC permits the weakest authorization as a basis for acceptance, so it would be misleading to describe DMARC results as having been *authenticated*.  It seems this is the motivation for attempting to promote SPF as being an Authentication method when in fact it is clearly only Authorization, especially with EHLO confirmation described as a null return path fallback.  With a high percentage of compromised systems, overstating authorization as authentication only benefits malefactors with this document's effort to oversell DMARC's functionality.

While DKIM should be able to actually authenticate a signing domain, it does not authenticate either the actual sending domain nor intended recipient.  In addition, the Authentication-Results header fields can not be trusted on the basis of DKIM and SPF alone.  Valid results are premised on unreported checks of the From header structure, while ignoring others, such as that of the Subject which is able to include clickable links and carry enticing messages.  It seems few domains bother to implement DKIM's Section 8.15 fixes intended to compensate for an oversight of not checking the header stack structure within DKIM's signature algorithm that must traverse the entire header stack in reverse.

Your comments offer convincing support for changing the DMARC acronym to mean Domain-based Message Authorization, Reporting and Compliance (DMARC),
 
> I think you are overcomplicating things here, and I don't understand

Both recipients and administrators are being misled into accepting malicious content while forgoing other safety checks!

> access a file because she is the owner).

It is not using SPF AND DKIM, it is using SPF OR DKIM.  SPF can't identify the domain owner (without using unscalable and unused macros).  When based on header results as suggested by the DKIM deployment RFC and perhaps soon the DMARC BCP draft, nor can DKIM.  Both SPF and DKIM still permit significant security exposures.  The intent of DMARC is to block a large portion of abuse to better retain email as a transactional signaling media.  Since neither of these mechanisms identify the domain involved, it would be safer to describe them as an authorization process to better convey DMARC's underlying limitations.

> your restrictive SPF policy.

Any message emitted by an authorized IP address is SPF authorized.  SPF says nothing about the use of a domain being authentic, as would DNSsec and to a lesser degree DNS for example.

> to actually announce that you aren't sending any authentic mail with

DKIM indicates the signing domain handled the signed portion of the message.  DKIM failed to provide a practical means to signal its results, especially when modified by receiving MTAs. Domain alignment permits assumptions about the authorization intent of either SPF or DKIM.  Neither DKIM nor DMARC have been able to fully protect underlying reliability which still accepts the weakest method.  The intent of DMARC was to increase delivery reliability at the expense of security.  As such it seems far safer to describe both SPF and DKIM as an Authorization mechanism, and not as an Authentication mechanism as the name's acronym implies. 

> shared resources I'm not so sure about SPF).

This view continues to overlook security gaps present within DKIM while at the same time ignoring DKIM might be supplanted by SPF.  

> provider game seems to care about that anyway.

Mailbox providers exclude non-authorized and known malicious domains.  This is not the same as providers identifying specific domains.   

> outside of the scope of these protocol documents, let alone of the WG.)

Concerns related to DNS and BGP aside, the sending domain is never verified by DKIM.  A message that most might consider undesired can be sent from anywhere to anyone and still have a valid DKIM signature.  From anywhere to anywhere is a feature of DKIM.  With that in mind, the most that can be safely said, is the DKIM signature acts as a message authorization, in much the same manner as that offered by SPF.  Neither SPF nor DKIM should be considered to offer domain assurances beyond Authorization.   

> still think this is better as "was", but I'm trying to understand your

You are conflating the use of a domain name itself with that of an email message authorized to purport having a domain's return path (SPF) or signed content purporting having been seen by the signing domain (DKIM).  DMARC permits the weaker of these assertions as a basis for acceptance.  Nor does DKIM ensure results are properly conveyed while leaving both ends of the message path wide open, nor does DKIM or DMARC protect the entirety of the message.

Regards,
Douglas Otis

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 3 Nov 2014 15:09:57 -0800

> Not that it's going to change at this point, but let's not overdo the

Just to get the citation right, it was Doug who said this, not me.

-MSK

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 04 Nov 2014 14:04:49 +0900

Douglas Otis writes:

 > After all, DMARC permits the weakest authorization as a basis for
 > acceptance, so it would be misleading to describe DMARC results as
 > having been *authenticated*.

Well, no, it isn't necessarily misleading.  According to RFC 4949,
authentication = identification + verification, while authorization is
a permission to do something.  For example, in DKIM "d=" identifies
the Signing Domain and "b=" + a DNS lookup provides the data needed
for verification.  At that point you have in fact authenticated the
Signing Domain, and with From alignment (and the additional
assumptions that the key is available only to the Author/Signing
Domain and that the Author Domain authenticates users) you have
authenticated the "authorization to use that mailbox in From."  (You
could add a lot more caveats -- there is a lot of attack surface in
email. :-( )  Some similar statement is true for SPF (at least under
favorable conditions :-).  AFAICS authenticating that particular
authorization is precisely what DMARC claims to do, although the I-D
uses different words to say that.

Anyway, AIUI, the question we're trying to address in Milestone One is
how does that affect third parties on the assumptions that (1) mail
receivers are satisfied that DMARC does what they think it does and
(2) such mail receivers respect "p=reject".

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 4 Nov 2014 15:34:16 -0800

> uses different words to say that.

Maybe I'm the only one, but I think that while the RFC4949 definitions are
fairly cut-and-dry when one talks about pure cryptography and authorization
systems, they seem more murky when applied to the email space.  For
example, one might argue that in the "permission to do something"
definition you gave, the "do something" in our case is the use of a
particular domain name in the From field.  Hence, the term "authorization"
applies.  However, the definitions of "verification" and "identification"
also apply, hence so does "authentication".  They're all arguably correct.

Also, Section 1 of -05 already contains this:

   For the purposes of discussion, this document defines the word
   "authentication" to include techniques used to verify message
   integrity and/or sending-entity authorization.

Accordingly, I don't see any evidence that, within the email space and
hence our target audience, our use of "authentication" to date has been
dangerously misleading or that anything really needs to change.

-MSK

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 05 Nov 2014 10:59:45 +0900

Murray S. Kucherawy writes:

 > Maybe I'm the only one, but I think that while the RFC4949
 > definitions are fairly cut-and-dry when one talks about pure
 > cryptography and authorization systems, they seem more murky when
 > applied to the email space.

I think this is going to be true of the use of these words in any
application where they refer to real security issues.

 > For example, one might argue that in the "permission to do
 > something" definition you gave, the "do something" in our case is
 > the use of a particular domain name in the From field.  Hence, the
 > term "authorization" applies.  However, the definitions of
 > "verification" and "identification" also apply, hence so does
 > "authentication".  They're all arguably correct.

If you say that they're all arguably correct, I'd say they're all
definitely wrong in that context. :-)  My point is that there are at
least two agents involved in each activity (a credentials provider and
a credentials verifier), and there may be more.  Eg, in the case of
DKIM you could argue that the From mailbox is provided by the
originating author while the public key used to verify it is provided
by the author domain, and with third-party auth*, it's more
complicated yet -- and we haven't yet started on the issues of
transitive trust with third party auth*.  If we want to use these
words accurately, we need explicit references to the subjects and
objects of the verbs, at least somewhere in the immediate context.

I don't have a problem with the I-D because I think it's the
responsibility of readers to *read* it, at the algorithm level, and
not try to interpret the verbal discussion as a precise specification.

But in this WG, where we're engaged in meta-discussion of the spec and
its effects, I think we need to be a lot more precise in use of these
words, and far more frequently mention the subjects and objects of the
verbs "identify", "authenticate", "verify", and "authorize", and
typically avoid the noun forms, especially "authentication" and
"authorization".  Also, we face yet another layer of complexity (which
Douglas Otis have referred to several times), and that is that I can
say that people *ought* to refer to protocol algorithms as the
authoritative definition all I like (and that has some validity) but
Doug is right that many users and admins do and think something else,
and the consequent deviation of belief from reality is often an attack
vector.

Regards,
Steve

---

From: Douglas Otis <[email-masked]>
Date: Wed, 5 Nov 2014 10:20:40 -0800

On Nov 3, 2014, at 9:04 PM, Stephen J. Turnbull <[email-masked]> wrote:

> a permission to do something.

Dear Stephen,

Since SPF authorizes an often _shared_ outbound IP address, it has been accurately described as an authorization method.  DMaRC permits a DKIM signature to be spoofed and still allow a message to be accepted solely on the basis of SPF.  What magic turns authorization into authentication???  Describing authorization as authentication has been an exaggeration that started with SenderID.  Large attack surfaces provided by often overly broad SPF is increasingly being exploited by botnets.

Calling DMaRC Authentication threatens victims of malefactors that gain access by way of SPF's fairly insecure authorization scheme which might also employ reverse DNS handily exploited by compromised systems.  This misrepresentation injures recipients misled into believing DMaRC authenticated the From email address, as well as senders blocked because an administrator believed DMaRC authenticated the identity in question, the From email address.  It has not, nor can it.

In addition, incorrectly defining DMARC as an authentication scheme tends to exclude many possible adjustments needed to safely lessen DMARC's disruptive impact on otherwise legitimate and desired third-party services relied upon for decades.  Don't let the erroneous term authentication stand in the way of less disruptive authorization extensions.

> For example, in DKIM "d=" identifies
> favorable conditions :-).
> 
> AFAICS authenticating that particular

Authenticating an Authorization?  Does that then make an Authorization authentication?

> (2) such mail receivers respect "p=reject".

Removing DMaRC's disruption can be done by enabling the authorization of necessary exceptions.  Perhaps by way of authorizing specific domains or or authorizing a specific From header field group syntax.  The DMaRC WG should not attempt to define new From header fields as a means to enable policy exceptions.  This would be sweeping DMaRC problems under the rug, as any new header field used to replace the From header field will be eventually displayed to users for obvious reasons.  Such expected change would provide the effect of re-arranging deck chairs on the Titanic.

draft-kucherawy-dmarc-base is not ready, as its definitions remain seriously flawed.

Regards,
Douglas Otis

---

From: Terry Zink <[email-masked]>
Date: Wed, 5 Nov 2014 18:35:32 +0000

> Since SPF authorizes an often _shared_ outbound IP address, it has been accurately described 
> as an authorization method.  DMaRC permits a DKIM signature to be spoofed and still allow 
> a message to be accepted solely on the basis of SPF.  What magic turns authorization into 
> authentication???  

This is a good point and I can share some of our own experiences in Microsoft's Office 365.

We have a hosted service. Companies/users can either have hosted email accounts wherein they login to the portal and send/receive email, or connect to it via IMAP/POP3. The second option is an on-premise environment wherein their email passes through us and we relay it to their on-premise machines. They can send outbound email through us by connecting to the service by specifying their outbound IP in a "Connector".

We ask customers to add our service's SPF record to their own SPF records. When they send outbound email through us, it will authenticate at the destination. However, if Customer A ever spoofs Customer B, it will also authenticate via SPF. This is a very real problem.

So how are we fixing it?

First, hosted email accounts cannot spoof another customer. If you login to the portal, or connect via IMAP/POP3, you can't specify your MAIL FROM domain. You have to set it up in the portal and put a key into your TXT record. That's not changeable.

Second, for on-premise machines, they *can* spoof another customer. If they connect over their IP, if the domain they connect with is not provisioned with them, it is attributed to a "safe tenant" (a misnomer in my opinion). It is here that they could spoof someone else. To get around this, we will check DMARC on outbound mail before we relay it out. If a domain fails DMARC when it connects to us, and it is an outbound email intended for the rest of the Internet, we will reject the message so it cannot be sent out to an unsuspecting third party that might pass SPF since it came from our service's outbound IPs.

This is not a perfect solution, but it does close a gap. The existing DMARC specification lets us do this without making any changes to it.

-- Terry

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Douglas Otis
Sent: Wednesday, November 5, 2014 10:21 AM
To: Stephen J. Turnbull
Cc: [email-masked]; Murray S. Kucherawy; Douglas Otis
Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base

Dear Stephen,

Regards,
Douglas Otis

_______________________________________________
dmarc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dmarc

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 5 Nov 2014 12:50:32 -0800

On Wed, Nov 5, 2014 at 10:35 AM, Terry Zink <[email-masked]>
wrote:

> [...]

Terry,

In terms of the base draft's content, I think the salient question is:

Does the base draft's use of the term "authentication" mislead you or your
customers in any way?

-MSK

---

From: Douglas Otis <[email-masked]>
Date: Wed, 5 Nov 2014 12:54:40 -0800

On Nov 5, 2014, at 10:35 AM, Terry Zink <[email-masked]> wrote:

> Second, for on-premise machines, they *can* spoof another customer. If they connect over their IP, if the domain they connect with is not provisioned with them, it is attributed to a "safe tenant" (a misnomer in my opinion). It is here that they could spoof someone else. To get around this, we will check DMARC on outbound mail before we relay it out.

Dear Terry,

What role does DMaRC play in a scheme that relies on the special TXT key you mentioned?  If so, is this really even describing DMaRC?

> If a domain fails DMARC when it connects to us, and it is an outbound email intended for the rest of the Internet, we will reject the message so it cannot be sent out to an unsuspecting third party that might pass SPF since it came from our service's outbound IPs.

Could this satisfy Intuit should their customers make use your services and assert p=reject?

> This is not a perfect solution, but it does close a gap. The existing DMARC specification lets us do this without making any changes to it.

How would this help resolve third-party issues the WG should be attempting to address?  While these efforts in your service are commendable, how does this help address the fact that the base draft is misleading and is using definitions that will be problematic when resolving third-party issues through use of hopefully open protocol extensions.

Regards,
Douglas Otis

---

From: Terry Zink <[email-masked]>
Date: Wed, 5 Nov 2014 21:37:01 +0000

> Does the base draft's use of the term "authentication" mislead you or your customers
> in any way?
No, everything is clear enough. I use the term to refer to passing either SPF or DKIM.

As an aside, I should have mentioned that we are working on DMARC but it is not yet complete. But the way I described it is how it will work.

-- Terry

From: Murray S. Kucherawy [mailto:[email-masked]]
Sent: Wednesday, November 5, 2014 12:51 PM
To: Terry Zink
Cc: [email-masked]
Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base

Terry,
In terms of the base draft's content, I think the salient question is:
Does the base draft's use of the term "authentication" mislead you or your customers in any way?
-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 05 Nov 2014 16:54:01 -0500

On Wednesday, November 05, 2014 06:35:32 PM Terry Zink wrote:
> > Since SPF authorizes an often _shared_ outbound IP address, it has been
> > accurately described as an authorization method.  DMaRC permits a DKIM
> > signature to be spoofed and still allow a message to be accepted solely
> > on the basis of SPF.  What magic turns authorization into
> > authentication???
> 
> We have a hosted service. Companies/users can either have hosted email
> accounts wherein they login to the portal and send/receive email, or
> connect to it via IMAP/POP3. The second option is an on-premise environment
> wherein their email passes through us and we relay it to their on-premise
> machines. They can send outbound email through us by connecting to the
> service by specifying their outbound IP in a "Connector".
> 
> We ask customers to add our service's SPF record to their own SPF records.
> When they send outbound email through us, it will authenticate at the
> destination. However, if Customer A ever spoofs Customer B, it will also
> authenticate via SPF. This is a very real problem.
> 
> So how are we fixing it?
> 
> First, hosted email accounts cannot spoof another customer. If you login to
> the portal, or connect via IMAP/POP3, you can't specify your MAIL FROM
> domain. You have to set it up in the portal and put a key into your TXT
> record. That's not changeable.
> 
> Second, for on-premise machines, they *can* spoof another customer. If they
> connect over their IP, if the domain they connect with is not provisioned
> with them, it is attributed to a "safe tenant" (a misnomer in my opinion).
> It is here that they could spoof someone else. To get around this, we will
> check DMARC on outbound mail before we relay it out. If a domain fails
> DMARC when it connects to us, and it is an outbound email intended for the
> rest of the Internet, we will reject the message so it cannot be sent out
> to an unsuspecting third party that might pass SPF since it came from our
> service's outbound IPs.
> 
> This is not a perfect solution, but it does close a gap. The existing DMARC
> specification lets us do this without making any changes to it.

If all your customers add your SPF to theirs, then if they forge each other's 
mail, it'll pass DMARC.  BTW, this has long been cited in the security 
considerations for the SPF RFCs (RFC 4408, 10.4 and RFC 7208 11.1).

I don't think you're fixing it at all, at least not as described.

Scott K

---

From: Terry Zink <[email-masked]>
Date: Wed, 5 Nov 2014 23:26:55 +0000

> mail, it'll pass DMARC. I don't think you're fixing it at all, at least not as 
> described.

For hosted customers, they cannot forge each others' email. So that part is fine.

For on-premise customers (whose mail servers connect to us and then we relay it out to the Internet), suppose that Customer1.com publishes a DMARC record of p=reject, and an SPF record of "v=spf1 ip4:1.2.3.4 include:office365_IPs.com". They similarly connect to us over the IP 1.2.3.4 in order to relay outbound email. Customer2.com publishes an SPF record of "v=spf1 ip4:5.6.7.8 include:office365_IPs.com" and connects to our service through the IP 5.6.7.8.

Customer2.com then sends email as Customer1.com from the IP 5.6.7.8. When our mail server scans it, it will see that the mail comes from customer1.com, but from the IP 5.6.7.8. Since 5.6.7.8 is not in Customer1.com's SPF record, it will fail SPF. This forged message will also not have a DKIM signature. Because it doesn't pass SPF or DKIM, and publishes a DMARC record, it fails DMARC.

Because this message fails DMARC, and because customer1.com (who was spoofed) publishes a DMARC record of p=reject, Office 365 will reject the message and not relay it outbound to the rest of the Internet.

-- Terry

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Scott Kitterman
Sent: Wednesday, November 5, 2014 1:54 PM
To: [email-masked]
Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base

Scott K

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Thu, 06 Nov 2014 17:27:41 +0900

Douglas Otis writes:

 > Since SPF authorizes an often _shared_ outbound IP address,

Not on my host, not ever -- I only have one IP address, and it *is*
mine (at least until my employer takes it away from me, but I trust
them to tell me if and when they do).  What's your problem with that?

 > been accurately described as an authorization method. 

Well, no -- obviously if X authorizes Y, it's an authorization method.
Circularity rules -- at least if you want to avoid the real question.

Here you're describing a practice (ie, use with a shared address), not
the protocol definition.  If doug.example.com and steve.example.com
are separate (virtual) Author Domains sharing a single IP address,
who's doing that SPF authorization and since when is that a good idea,
may I ask?

If you want to deprecate SPF because it is frequently misused in such
a way that *no* security verbs can properly be used to describe what
it does, fine, deprecate it.  But don't deprecate it by saying
"existing practice is broken and doesn't authenticate what I think it
should authenticate so I don't want you ever to say the protocol
authenticates anything".  That's not useful because I may disagree
with you about what I need authenticated.

 > Describing authorization as authentication has been an exaggeration
 > that started with SenderID.  Large attack surfaces provided by
 > often overly broad SPF is increasingly being exploited by botnets.

You wrote that already, I read it and I understand it.  What I *don't*
understand is your definitions of "identification", "verification",
"authorization" and "authentication" as applied to these protocols.

 > > AFAICS authenticating that particular authorization is precisely
 > > what DMARC claims to do, although the I-D uses different words to
 > > say that.
 > 

No.  Read what I wrote, I wrote what I meant, and I didn't write "an
authorization is an authentication" because that's not what I meant.

 > draft-kucherawy-dmarc-base is not ready, as its definitions remain

So far you have provided no evidence of incorrect definition.  You
have claimed that the draft's usage of security verbs is incorrect,
but as far as I can tell they basically conform to RFC 4949.