Subject: Re: [dmarc-ietf] Rolling out the experiment

From: Ian Levy <[email-masked]>
Date: Mon, 1 Apr 2019 07:03:34 +0000

*   SPF and ASDP polices can still be published for non-existent domains

Sure, but I can't predict what non-existent subdomains criminals are going to use next. Should I publish a set of TXT records for dougfoster.gov.uk uniquely? Given we've no way of predicting that, we're responding to any query for TXT records  for any undelegated gov.uk subdomain with an SPF and DMARC record. Regardless of how we intend to detect non-existent subdomains (for some value of non-existent), we'll need to stop responding with those default records on gov.uk to do something approaching real world testing of PSD-DMARC.

Ta.

I.

--
Dr Ian Levy
Technical Director
National Cyber Security Centre
[email-masked]<mailto:[email-masked]>

Staff Officer : Kate Atkins, [email-masked]<mailto:[email-masked]>

(I work stupid hours and weird times - that doesn't mean you have to. If this arrives outside your normal working hours, don't feel compelled to respond immediately!)

From: dmarc <[email-masked]> On Behalf Of Douglas E. Foster
Sent: 31 March 2019 22:07
To: [email-masked]
Subject: [dmarc-ietf] Rolling out the experiment

Based on my reading of your draft, the testing process for non-existent domains is as follows:

  1.  Any DMARC policies for non-existent domains must be removed, so that the recipient system can look upward to the PSD DMARC.
  2.  SPF and ASDP polices can still be published for non-existent domains, because a domain is non-existent only when it lacks A, AAAA, and MX records.  SPF and ADSP are TXT records, so they do not affect the evaluation.  What I do not understand is how a device determines that a particular domain has no A, AAAA, or MX records.
  3.  Assuming that #2 iis valid, the test can proceed with no loss of current protections.  SPF and ADSP policies can be used to block a fraudulent message from a non-existent domain.   The behavior varies by device capability.
     *   A non-DMARC device would stop after blocking the message because of SPF or ADSP policy violation.
     *   An organization-DMARC device would look for a DMARC policy and fail, so no feedback would be sent.  It would still block the message based on SPF and DMARC policy violations.
     *   A PSD-DMARC device could block the message by either of two methods:
        *   It detects the domain as non-existent, and looks immediately for a PSD-DMARC policy.
        *   It blocks the message based on SPF or DMARC, then looks for feedback instructions, following the tree upward until it finds a PSD DMARC policy with feedback instructions.
SPF is widely deployed, so dropping SPF policies will affect recipients not participating in the test.    That is why I am alarmed..

I do not understand why that should be necessary, but I suppose that the answer hangs on the mechanism for detecting non-existent domains in a manner compliant with section 2.6

Doug Foster

________________________________
From: "Ian Levy" <[email-masked]>
Sent: Sunday, March 31, 2019 3:07 PM
To: "[email-masked]" <[email-masked]>, "ScottKitterman" <[email-masked]>, "IETF DMARC WG" <[email-masked]>, "Ian Levy" <ian.levy=[email-masked]>
Subject: Re: [dmarc-ietf] Working group next steps

The existing defences aren't 100% even before the evil kludge we've put up for non existent subdomains, which certainly is not working everywhere. The PSD draft, when implemented, will help scale existing defences to make evolution of criminal behaviour harder and do it in a standardised way so that it's more likely to be consistently implemented.  That's worth us collectively doing some work and me taking some risk to help early testing.

Nothing is 100% in security. Except possibly the existence of a preponderance of marketing hype :-).

Ta.

I.

-
Dr Ian Levy
Technical Director
National Cyber Security Centre
[email-masked]

(I work stupid hours and weird times - that doesn't mean you have to. If this arrives outside your normal working hours, don't feel compelled to respond immediately!)
________________________________
From: dmarc <[email-masked]> on behalf of Douglas E. Foster <[email-masked]>
Sent: Sunday, March 31, 2019 7:31 pm
To: Scott Kitterman; IETF DMARC WG; Ian Levy
Subject: Re: [dmarc-ietf] Working group next steps

Certainly not.

You cannot drop existing defenses until the new standard is 100% deployed on the Internet, which means probably never.    Your experimental implementation will need to prioritize the new test over the SPF test, to prove that it is working and to show that it is good at intercepting any subdomains that have been newly imagined by the attackers

To speed up the deployment process for existing or new standards, IETF would meed to embrace the idea of defining required features of a spam filter.

Doug Fosterd

________________________________
From: "Ian Levy" <ian.levy=[email-masked]>
Sent: Sunday, March 31, 2019 6:18 AM
To: "Scott Kitterman" <[email-masked]>, "IETF DMARC WG" <[email-masked]>
Subject: Re: [dmarc-ietf] Working group next steps

>> I'll also offer gov.uk as an experimental ground (within reason!).

> Excellent. I've listed it in the experimental registry at psddmarc.org...
> Since you already had a live DMARC record for that domain, people can experiment with this now.

I guess at some point we'll have to stop generating SPF and DMARC records for the non-existent subdomains of gov.uk so we can test the new stuff properly. When we're at that point, let me know.

Ta.

I.

--
Dr Ian Levy
Technical Director
National Cyber Security Centre
[email-masked]

Staff Officer : Kate Atkins, [email-masked]

(I work stupid hours and weird times - that doesn't mean you have to. If this arrives outside your normal working hours, don't feel compelled to respond immediately!)

This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to [email-masked]
_______________________________________________
dmarc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dmarc

This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to [email-masked]
This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to [email-masked]

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 3 Apr 2019 11:32:44 +0200

On Mon 01/Apr/2019 09:03:34 +0200 Ian Levy wrote:

> Sure, but I can’t predict what non-existent subdomains criminals are going to
> use next. Should I publish a set of TXT records for dougfoster.gov.uk uniquely?
> Given we’ve no way of predicting that, we’re responding to any query for TXT
> records  for any undelegated gov.uk subdomain with an SPF and DMARC record.
> Regardless of how we intend to detect non-existent subdomains (for some value
> of non-existent), we’ll need to stop responding with those default records on
> gov.uk to do something approaching real world testing of PSD-DMARC.

This argument is utterly confusing to me.  When I read Scott's draft, I
understood he was talking about _existing_ domains.  Indeed, that sounded
somewhat strange, since the higher level domain's owner should have a say on
the policies that subdomains have to follow, but IANAL.

DMARC had reject-on-nxdomain, but then reduced it to appendix A.4.  ADSP
(historic) left it to undefined.  Yet, it's the only (deprecated) auth-method
having a "nxdomain" code.  If we are seeking a spec that enables parent domains
to specify reject-on-nxdomain for their subdomains, it doesn't seem to be
necessarily related to DMARC.  (I mean DMARC as a spec, not the dmarc WG.)

    ale@pcale:~/tmp$ dig +short dougfoster.gov.uk txt
    "v=DMARC1;p=reject;rua=mailto:[email-masked]"
    "v=spf1 ?all"

I agree that's an evil kludge.  (Why ?all?)  Dave just posted a draft about DNS
perimeter, which might possibly evolve so as to allow only the _dmarc label to
return the above record (can it?), while dougfoster.gov.uk perhaps returns the
spf1 stuff.  It is still overly complicated w.r.t. such a simple task as
reject-on-nxdomain.

Best
Ale
--