Re: [dmarc-ietf] Ticket #111 (and #112) - Proposed language

[Douglas Foster <[e-mail]>]

I am providing two types of examples:
1) A legitimate sender using a non-existent name,
2) An impersonating sender using undefended non-domain names.


Valid Message Example
===================

MailFrom:  [e-mail]
From:         [e-mail]
Signature: None
DMARC Policy:   Not currently configured.
SPF Status:   PASS
FROM Status:  NXDOMAIN

What happens when they implement DMARC?

One possibility is that they create a DKIM signature for
"scope1._domainkey. secure.hiltonheadislandsc.gov"   This ensures DMARC
PASS as long as the signature validates.

But if the message is modified in transit, the signature will no longer
validate.   Which policy should apply?   If the public key was successfully
retrieved, then the name certainly exists, and is used for DKIM signing, so
it should be SP.   But it does not yet meet the MX/A/AAAA/SPF test, so our
draft calls for it to be evaluated as NP.

To meet the MX/A/AAAA/SPF tests, the sender must create one of those four
DNS records.   But which one is relevant?   None of them.


Attack Scenario Examples
====================

Assume:  Example.com has DMARC policy of "p=reject, sp=none, np=none"

Also assume that "spammer.tld" decides it will be profitable to impersonate
example.com, and begins this data collection:

Research:
1. Spammer scans the example.com website, collecting host names.
2. Spammer performs MX and SPF lookups to collect additional host names.
3. Spammer performs DNS lookup on some other commonly-used names to see if
they exist.
4. Spammer notes that while "example.com" is protected by SPF and DMARC
p=reject, individual hosts do not have an SPF policy.

Strategy
Spammer does not want to risk being blocked by DMARC p=reject, so he will
not use "example.com" directly.
Spammer does not want to be blocked by SPF NXDOMAIN, so he will not use a
non-existent MAILFROM domain.
Spammer choses "mail.example.com" as the preferred impersonation domain.


Attack Scenario 1:  Spammer gets lucky, because the MX for "example.com" is
the host "mail.example.com".   Spammer has these options;

a) Pretend to be a mailing service, using spammer.tld as the SPF context:
MAILFROM=[e-mail]
FROM=[e-mail]
Sender authentication evaluates to SPF=PASS and DMARC policy SP applies.

Example.com has these sender-authentication defense options for this attack:
- Changing mail.example.com to a subdomain and creating a subdomain DMARC
P=reject/quarantine policy, or
- Changing the organization policy to sp=reject/quarantine


b) Pretend to be a direct message
MAILFROM=[e-mail]
FROM=[e-mail]
Sender authentication evaluates to SPF=NONE and DMARC policy SP applies.

Example.com has these sender-authentication defense options for this attack:
- Create an SPF "-ALL" policy for "mail.example.com"
- Changing mail.example.com to a subdomain and creating a subdomain DMARC
P=reject/quarantine policy, or
- Changing the organization policy to sp=reject/quarantine


================

Scenario 2:  Spammer notes that "mail.example.com" is not a defined host.
 Spammer has these options:

a) Pretend to be a mailing service, using spammer.tld as the SPF context:
MAILFROM=[e-mail]
FROM=[e-mail]
Sender authentication evaluates to SPF=PASS and DMARC policy NP applies.

Example.com has these sender-authentication defense options for this attack:
- Changing mail.example.com to a subdomain and creating a subdomain DMARC
P=reject/quarantine policy, or
- Changing the organization policy to sp=reject/quarantine


b) Pretend to be a mailing service, sent by a host in the target domain:
MAILFROM=[e-mail]
FROM=[e-mail]
Sender authentication evaluates to SPF=NONE and DMARC policy NP applies.

Example.com has these sender-authentication defense options for this attack:
- Create an SPF "-ALL" policy for "www.example.com", or
- Changing mail.example.com to a subdomain and creating a subdomain DMARC
P=reject/quarantine policy, or
- Changing the organization policy to sp=reject/quarantine, or
- Changing the organization policy to np=reject/quarantine




On Thu, Jun 17, 2021 at 3:57 AM Murray S. Kucherawy <[e-mail]>
wrote:

> I continue to not understand the defect you're highlighting here.
>
> I think you've expressed yourself primarily in the abstract.  Could you
> craft a sample message, sample envelope, and sample DNS context that
> highlights the problem you're talking about?  Maybe then it'll snap into
> focus.
>
> On Wed, Jun 16, 2021 at 2:43 PM Douglas Foster <
> [e-mail]> wrote:
>
>> NXDomain on RFC5322.From is a completely different issue.    It means
>> that the name is only used for service provider messaging, and is therefore
>> not linked to any IP address or other physical infrastructure.  It affects
>> the ability to define a meaningful NP test.   The issue becomes irrelevant
>> to DMARC if and only if we drop the NP policy idea completely.
>>
>> The proposed MX/A/AAAA/SPF test has two significant problems:
>> - It incorrectly classifies some names as NP because they do not need
>> MX/A/AAAA/SPF records because they are not tied to an IP address, and we
>> have provided a very poor mechanism for a domain owner to come into
>> compliance.
>>
>
> There's a workaround here: If I want to use a name that is not represented
> in the DNS according to that test, all I need to do is DKIM sign with my
> parent domain.  That makes "p" apply because now you have an aligned
> "pass", which presumably trumps any "np" that's set.
>
> If you aren't signing with DKIM in that scenario, and you obviously can't
> pass SPF either, then you can't possibly hope to pass DMARC irrespective of
> any test being done on the name's validity.
>
> - It incorrectly classifies some names that are not used for email as not
>> NP, simply because they have an A/AAAA record.   It provides no method for
>> the domain owner to signal that the name is not used for email and
>> therefore should be treated as NP.
>>
>
> If they're not used for email, then they're not in DMARC's problem space.
>
> At any rate, since PSD has been approved, I'm hoping the experiment is
> underway, or will be soon, and then we might have some actual data about
> the severity of this defect and thus also possibly some hints about ways it
> can be mitigated.
>
> -MSK
>