[dmarc-ietf] Doing a tree walk rather than PSL lookup
Here's a draft about how DMARC might do a tree walk rather than look up an organizational domain in the PSL. https://datatracker.ietf.org/doc/draft-levine-dmarcwalk/ Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP
On Fri, Nov 20, 2020 at 5:57 AM Doug Foster wrote: > > However, spoofing of non-existent subdomains is a potential problem for the > RFC5321.MailFrom domain, which then becomes an attack vector for the > RFC5322.From address as well. The problem exists because because SPF has > no > organizational default. > > We need to think about intermediate nodes, non-mail leaf nodes, and > non-existent subdomains. Assume that a spammer tries to spoof a legitimate > organization by using a non-mail or non-existing node for both the SMTP > MailFrom address and the message From Address. The message will be > evaluated as > - SPF=None, > - DomainAligned=True, and > - (if checked by some unknown algorithm) OrganizationReputation=good. > > Presuming no DKIM signature is involved, SPF=None is not the required "PASS" that DMARC enforces so I don't see the point of your argument. --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP
To return briefly to the muddy waters that I created. John is correct that "mail enabled" is not useful for the RFC5322.From address, and my last note expanded on reasons why that is correct. However, spoofing of non-existent subdomains is a potential problem for the RFC5321.MailFrom domain, which then becomes an attack vector for the RFC5322.From address as well. The problem exists because because SPF has no organizational default. We need to think about intermediate nodes, non-mail leaf nodes, and non-existent subdomains. Assume that a spammer tries to spoof a legitimate organization by using a non-mail or non-existing node for both the SMTP MailFrom address and the message From Address. The message will be evaluated as - SPF=None, - DomainAligned=True, and - (if checked by some unknown algorithm) OrganizationReputation=good. Can we assume that all such messages will be blocked by all recipients? It seems better to have a published policy to say that it should be blocked. Based on existing specifications, the organization has these defenses: - All possibilities are protected if the organization DMARC sp policy is enforceable (p<>none and pct<>0). However, we know that this is problematic for many organizations. - Mail-enabled nodes should have an SPF record, so those domains will be protected. - Existing but non-mail domains are only protected if they have an SPF -ALL policy. This may be difficult and error-prone for the organization to maintain. Conclusions: Assuming that many organizations are still at sp=none, we have an attack surface from non-existent domains. The "must exist" policy provides the only defense for non-existent nodes when the DMARC sp policy is non-enforcing. Assuming that many organizations will have trouble managing deployment of SPF -ALL universally, we have an attack surface for non-mail subdomains. The "must be mail enabled" policy provides a simpler defense mechanism than deploying SPF -ALL to every non-mail node. DF -Original Message- From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Chudow, Eric B CIV NSA DSAW (USA) Sent: Friday, November 20, 2020 6:29 AM To: 'John Levine'; 'dmarc@ietf.org' Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP Thank you, John. I agree that it's an edge case and not worth addressing separately. Eric Chudow DoD Cybersecurity Mitigations -Original Message- From: John Levine Sent: Thursday, November 19, 2020 11:04 PM To: dmarc@ietf.org Cc: Chudow, Eric B CIV NSA DSAW (USA) Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP In article <553d43c8d961c14bb27c614ac48fc03128116...@umechpa7d.easf.csd.disa.mil> you write: >Section 2.7. defines a non-existent domain as "a domain for which there >is an NXDOMAIN or NODATA response for A, , and MX records. This is >a broader definition than that in NXDOMAIN [RFC8020]." This should be sufficient for determining that the domain is not intended to be used and therefore could have a more stringent policy applied. > >The idea of looking for a "mail-enabled domain" based on if an "MX record exists or SPF policy exists" is interesting. >Although there may be domains that send email but not receive email and so may not have an MX record. These days I think you will find that if the domains in your bounce address and your From: headers don't have an MX or A record, very few recipients will accept your mail. This seems like an edge case. In practice I find that the domains caught by the Org domain or I suppose PSD have A records but no mail server because they're actually web hosts rather than mail hosts. We have the Null MX to indicate that a domain receives no mail and SPF plain -all to indicate that it sends no mail so I hope we don't try to reinvent these particular wheels. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP
I fear that I muddied the waters by asking about the RFC5321.MailFrom address. Let's return to the main issue of the RFC5322.From address which DMARC protects. This is not an edge case. If spam filters were already blocking messages with RFC5322.From addresses with non-existent domains, we would not be having this discussion. The RFC5322.From address can be very ethereal. Consider the following situation: The marketing department of Example.com hires a mass mailer to do a campaign from market...@christmassale.example.com. ChristmasSale.Example.Com does not currently exist. The email service provider does its due diligence during account setup: - The client has sent email communication from example.com and account paperwork for the same organization. I have the client identified correctly,. - The client has no DMARC policy on Christmas.Example.com, and an organization or PSD DMARC policy of SP=none, so I do not need to acquire a DKIM signing key. - But the organization or PSD policy does specify NP, so I need the client to prove that ChristmasSale.Example.Com exists. Requiring the client to create a bogus host record with a bogus IP address makes no sense, and is likely to be rejected by the client DNS administrator. Requiring the client to create a name server record to prove domain existence does make sense, and should be easily approved and implemented by the client DNS administrator. Ergo, defining the NP policy based on A, , and MX is not appropriate. Doug Foster From: eric.b.chudow.civ=40mail@dmarc.ietf.org Sent: 11/20/20 6:30 AM To: 'John Levine' , "'dmarc@ietf.org'" Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP Thank you, John. I agree that it's an edge case and not worth addressing separately. Eric Chudow DoD Cybersecurity Mitigations -Original Message- From: John Levine Sent: Thursday, November 19, 2020 11:04 PM To: dmarc@ietf.org Cc: Chudow, Eric B CIV NSA DSAW (USA) Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP In article <553d43c8d961c14bb27c614ac48fc03128116...@umechpa7d.easf.csd.disa.mil> you write: >Section 2.7. defines a non-existent domain as "a domain for which there >is an NXDOMAIN or NODATA response for A, , and MX records. This is >a broader definition than that in NXDOMAIN [RFC8020]." This should be >sufficient for determining that the domain is not intended to be used and >therefore could have a more stringent policy applied. > >The idea of looking for a "mail-enabled domain" based on if an "MX record >exists or SPF policy exists" is interesting. >Although there may be domains that send email but not receive email and so may >not have an MX record. These days I think you will find that if the domains in your bounce address and your From: headers don't have an MX or A record, very few recipients will accept your mail. This seems like an edge case. In practice I find that the domains caught by the Org domain or I suppose PSD have A records but no mail server because they're actually web hosts rather than mail hosts. We have the Null MX to indicate that a domain receives no mail and SPF plain -all to indicate that it sends no mail so I hope we don't try to reinvent these particular wheels. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP
Thank you, John. I agree that it's an edge case and not worth addressing separately. Eric Chudow DoD Cybersecurity Mitigations -Original Message- From: John Levine Sent: Thursday, November 19, 2020 11:04 PM To: dmarc@ietf.org Cc: Chudow, Eric B CIV NSA DSAW (USA) Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP In article <553d43c8d961c14bb27c614ac48fc03128116...@umechpa7d.easf.csd.disa.mil> you write: >Section 2.7. defines a non-existent domain as "a domain for which there >is an NXDOMAIN or NODATA response for A, , and MX records. This is >a broader definition than that in NXDOMAIN [RFC8020]." This should be >sufficient for determining that the domain is not intended to be used and >therefore could have a more stringent policy applied. > >The idea of looking for a "mail-enabled domain" based on if an "MX record >exists or SPF policy exists" is interesting. >Although there may be domains that send email but not receive email and so may >not have an MX record. These days I think you will find that if the domains in your bounce address and your From: headers don't have an MX or A record, very few recipients will accept your mail. This seems like an edge case. In practice I find that the domains caught by the Org domain or I suppose PSD have A records but no mail server because they're actually web hosts rather than mail hosts. We have the Null MX to indicate that a domain receives no mail and SPF plain -all to indicate that it sends no mail so I hope we don't try to reinvent these particular wheels. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] org domain and levine-dbound and dns-perimeter drafts
On 19/11/2020 21:33, Todd Herr wrote: On Thu, Nov 19, 2020 at 7:39 AM Alessandro Vesely wrote: On 18/11/2020 22:33, John R Levine wrote: On 11/18/2020 12:44 PM, John Levine wrote: so I encourage the group to limit the debate to the existing Org/PSL kludge and a tree walk. "and a tree walk" is not a minor 'and'. neither conceptually nor operationally. assurances to the contrary notwithstanding. I didn't say they were equivalent. But I do think they are the only options that are likely to get much interest from the WG. >> I don't think tree walk is a viable option, as it distorts semantics. Forgive me, but I don't know what you mean by the phrase "distorts semantics"; can you please help me understand? The current semantics considers an Organizational Domain to be the expression of the organization itself, the organization's master domain. That's quite nearly what the PSL strive for. Tree walk, instead, discards any organizational boundary. As for the viability of a tree walk, it is possible in complex environments to have something resembling the following: - RFC5322.From domain - a.b.foo.com - _dmarc.a.b.foo.com non-existent - _dmarc.b.foo.com record exists, p=x, rua=r1 - _dmarc.foo.com record exists, p=y, rua=r2 - _dmarc.com record doesn't exist, for the time being. On the other hand, one might infer from the DNS records that are published that their intent was for a.b.foo.com to inherit x for the policy and r1 as the destination for aggregate reports from the b.foo.com record; this would be an error on their part, because DMARC does not currently support discovery of the record at _dmarc.b.foo.com in this case. Without asking them directly, we could also infer that folks at b.foo.com are sneakily trying to divert feedback traffic. The way I see it, we can choose one of three paths here: 1. Keep things as they are, where if there is no policy published for RFC5322.From, the policy is inherited from the org domain, if a policy is published there Easiest and safest option. 2. Change the spec so that the only policy lookup done is for the RFC5322.From domain, and if there's no policy there, then DMARC doesn't exist for that domain SPF experience shows that large domains don't have the ability to maintain a script that defines suitable DNS records for all their subdomains. This would force inconsistent usage of '*' domains. BTW, as of your example, we have: ale@pcale:~$ dig _dmarc.b.foo.com txt ; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> _dmarc.b.foo.com txt ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44418 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: ab33c1fc9c9860b18b1294575fb788126f7a88216eadcab7 (good) ;; QUESTION SECTION: ;_dmarc.b.foo.com. IN TXT ;; ANSWER SECTION: _dmarc.b.foo.com. 600 IN TXT "v=spf1 -all" ;; AUTHORITY SECTION: foo.com.250 IN NS ns2.digimedia.com. foo.com.250 IN NS ns1.digimedia.com. ;; ADDITIONAL SECTION: ns1.digimedia.com. 172450 IN A 23.21.242.88 ns2.digimedia.com. 172450 IN A 23.21.243.119 3. Change the spec so that policies published between the RFC5322.From domain and the organizational domain can be discovered, in order to support the most flexibility across organizations. Besides making a lot of confusion about where policies and feedback addresses might come from, this feature inflates DNS queries more than it is desirable. If you have From: DoS you have to look up each subdomain in the required order. (Maybe you can check if z exists, and in case if m.n.o. ... x.y.z exists, and so on in a dichotomic anti-DoS tactic. Hm...) Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
