Based on my reading of your draft, the testing process for non-existent domains
is as follows:
Any DMARC policies for non-existent domains must be removed, so that
the recipient system can look upward to the PSD DMARC. 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.
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 protected]>
Sent: Sunday, March 31, 2019 3:07 PM
To: "[email protected]" <[email protected]>,
"ScottKitterman" <[email protected]>, "IETF DMARC WG" <[email protected]>, "Ian
Levy" <[email protected]>
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 protected]
(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 protected]> on behalf of Douglas E. Foster
<[email protected]>
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" <[email protected]>
Sent: Sunday, March 31, 2019 6:18 AM
To: "Scott Kitterman" <[email protected]>, "IETF DMARC WG" <[email protected]>
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 protected]
Staff Officer : Kate Atkins, [email protected]
(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 protected]
_______________________________________________
dmarc mailing list
[email protected]
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 protected]
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
