Restating what we all know: - The Internet is dependent on the reliable operation of the DNS name system. - The DNS name system is dependent on the reliable operation of the name registration processes. - The registrars are given ownership of all unregistered domain names within their portion of the hierarchy. - The public evidence of registration is the existence of a DNS entry, and a NS record is always the first one configured.
Conclusions - Unregistered use of any domain name is an attack on the architecture of the Internet. - PSD for DMARC is asking us to give public suffix operators what they are supposed to already have: control over unregistered names. - We should implement new and universal policies:- Unregistered names used as SMTP addresses MUST generate SPF FAIL and SHOULD be rejected.- Unregistered names used as message From header addresses MUST generate DMARC FAIL and SHOULD be rejected. Protecting the integrity of the name registration system is not an optional activity to be implemented by a few organizations with the most sophisticated implementations of the DMARC specification. It should be a mandatory duty of every legitimate participant on the network. Starting from the assumption that unregistered domains might be allowable creates many problems when trying to design solutions for protecting the names that are registered. This assumption needs to be rejected. Addressing some straw-man questions: Q: The idea is fine for public suffixes, but my organization doesn't need to do that for subdomains under its control. A: Every level of the DNS tree needs coordination of name usage. Publishing an NS record for an organization subdomain proves that the organization's process has been followed. Besides, the boundary between public suffixes and organizational domains is imprecise, so recipients cannot be expected to apply differential expectations. Q: My business partner and I exchange information using unregistered subdomains, and it is working fine. Leave me alone. A: Of course, senders can register with recipients, to obtain a filtering exception, as an alternative to registering in the public DNS. But the default behavior should be to block messages. Note that private use of unregistered subdomains may cause subsequent conflicts if the organization assigns the name to another purpose. Q. How do we get all incoming filters to change to default block for unregistered domain names? A. I would suggest using the CVE/CCE process. Q. What does this mean for the PSD for DMARC process? A. I think it becomes unnecessary. Getting all participants to block all unregistered domains is a better goal, and can probably be achieved more easily. It should involve relatively simple software changes, minimal DNS load, and minimal evaluation-time overhead. Doug Foster ---------------------------------------- From: fosterd=40bayviewphysicians....@dmarc.ietf.org Sent: 11/20/20 8:58 AM To: <dmarc@ietf.org> Subject: 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 <jo...@taugh.com> Sent: Thursday, November 19, 2020 11:04 PM To: dmarc@ietf.org Cc: Chudow, Eric B CIV NSA DSAW (USA) <eric.b.chudow....@mail.mil> 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, AAAA, 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
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
