Justification and Implementation of the NP Policy The NP Policy is used to hinder attacks of type “Invention”, as defined below:
· *Impersonation* attacks utilize an existing subdomain of the parent. The domain owner can hinder impersonation attacks using DMARC and SPF policies published on the subdomain, as well as with the SP clause of the parent domain’s DMARC policy. The number of existing subdomains is finite, although it may be a large number in some cases. · *Invention* attacks utilize a non-existent subdomain of the parent. Therefore, no SPF or DMARC policy is available on the subdomain. The domain owner can hinder impersonation attacks by converting them to existing domains, or by publishing a parent domain DMARC policy with SP>none (in the current specification) or NP>none (in the proposed specification.) The number of non-existent subdomains is essentially infinite, limited only by the available character set, the 64-character length of a segment, and the 255-character limit of a full domain. Most recipient systems operate on a default-open basis, meaning that messages which have no negative indicators are allowed through. Attackers using false identity will choose a parent domain with a favorable reputation, so that the parent domain will be unlikely to cause a message to be blocked. However, recipient systems will also learn from messages received, so the feasibility of false-identity attacks will diminish with repeated use of any single identity. Since invention attacks draw from an essentially infinite pool of possible identifiers, the possibility of an invention-based attacks is of significant concern to the recipient. When a DMARC policy uses SP>none, both impersonation and invention attack types are hindered. However, operational reports indicate that SP>none is often the last step in a long DMARC implementation process. Without an NP policy, invention attacks remain viable as long as SP=none. The new NP policy reverses this process. Once all subdomains are considered to exist in DNS, the organization policy can be set to NP>none, hindering invention attacks. Since unused domains have no users, organizational resistance to setting NP=reject should be minimal. Hindering invention attacks can now become one of the first steps in the DMARC rollout process, rather than one of the last. Test Design Considerations One-sided error curve When designing a non-existent test, the test needs to have a one-sided error curve. The test must be trusted to produce no false classifications of existing domains as non-existent, because such errors will lead to an abandonment of the test and a return to infinite possibilities. Operators should be able to accept a test which sometimes accepts a non-existent domain as existent, because such events can be handled by exception as needed. Ambiguous Results – the A/AAAA query type The A and AAAA tests are examples of an ambiguous test. When a result is returned, the result could be one of two things: 1. The first segment represents a host record in a parent domain <hostname>.parentdomain, or 2. The first segment represents a null host name so that the host name is the domain name <null host><subdomain>.parentdomain When the goal is to determine whether a specific identifier represents a DNS domain, the A record must be coupled with another test to resolve the ambiguity. Ambiguous Results - Wildcards Wildcards are another source of ambiguity. If a query for “subdomain.parentdomain” returns a result, it may be appropriate to requery using “*.parentdomain”. If the wildcard does not exist, then the subdomain is confirmed to exist. If a wildcard is confirmed, then the results are ambiguous and disposition must be made based on the unresolved ambiguity. Testing for non-existence: The TXT test One way to test for non-existent domain is to type for type=TXT, query=domainname. If the query returns NXDOMAIN, non-existence is fully confirmed. If the test returns NODATA or result data, then the domain is tentatively confirmed to exist. A wildcard test is recommended to determine whether existence is fully confirmed (no wildcard) or ambiguous (wildcard detected.) The elegance of this test is that it is simple and lightweight, requiring at most 2 DNS lookups. Result possibilities are: · NXDOMAIN – domain does not exist · Confirmed – domain existence is confirmed without wildcard · Ambiguous – domain existence is confirmed with wildcard. · TempError – any DNS error, including DNS SEC failures that cause server error. Testing for non-existence: The Mail Enabled Test An alternative test examines DNS for the presence of MX, A/AAAA, and possibly SPF records. If any of these are found, the domain is assumed to exist, and if none are found, the domain is assumed to not exist. This test is based on the assumption that any domain used in a FROM domain must also have a server infrastructure for receiving messages to that domain. Consequently, the validity of this test depends on the validity of that assumption. Because the Mail Enabled test involves specific content, the level of content checking will affect the results. Since RFC 7505 documents a way to use MX records to indicate non-mail status, results should at minimum be tested for this condition. More thorough testing would verify that each host name resolves to an IP address, and that returned IP addresses are, or at least include, routable addresses. Because this test involves substantially more DNS queries, it is more susceptible to TempError results. Possible test results include: · Confirmed – one of the required queries returned acceptable results · Non-Existent – all queries returned NXDomain, NoData, or a RFC7505-compliant non-mail MX record. · PermError – one or more queries returned non-resolvable host names, or host names that resolved to non-routable IP addresses · TempError – any other DNS error, including DNS SEC failures that cause server error. The Edge Case – Requirements on Domain Owners Assume that the marketing department wants to send messages from a new subdomain, with address nore...@promotions.example.com, using a third-party mailing service. The domain will not be used for any other purpose and does not require a server infrastructure at this time. Requirements to satisfy the TXT test: Before using the new subdomain in a FROM address, the subdomain must be registered in DNS. No assumptions are imposed about DNS content. Requirements to satisfy the Mail Enabled: Before using the new subdomain in a FROM address, the subdomain must either have an actual mail infrastructure implemented and published in DNS, or at least a placeholder set of DNS entries which create the appearance that an actual mail infrastructure exists. However, the use of placeholder data may have unpredictable effects on subdomain reputation. On Fri, May 7, 2021 at 5:43 PM Murray S. Kucherawy <superu...@gmail.com> wrote: > On Thu, May 6, 2021 at 8:14 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> My argument is that that A/AAAA/MX has no useful relevance to determining >> whether the RFC5322.FROM address of a message should be evaluated based on >> SP or NP. NP is described as testing "non-existent", rather than "possibly >> able to receive mail". We need a test that evaluates whether the domain >> exists or not, and is maximally protected from false positives caused by >> host names and wildcards. >> >> If this group is convinced that A/AAAA/MX is meaningful for the distinction >> between SP and NP, I am asking someone to provide the justification and >> define the algorithm. Right now I have seen neither. >> >> > I continue to be unclear on why you think that test suite against a name > is inadequate. Can you demonstrate a live case of a false positive or > false negative? Perhaps an actual example will help to move this from the > abstract to the concrete. > > In the meantime, here's what I think is the justification: If you try to > send me mail apparently from a domain that appears to have no email-related > presence in the DNS, that strikes me as a reasonable situation in which to > bounce such a message, and accordingly, a viable test for DMARC to use. > It's also relatively cheap, given that the DNS is a globally distributed > highly resilient database specifically built to answer such questions. An > "email-related presence" is the three RRTYPEs that SMTP specifically uses > in trying to make use of a reverse path, and since this is an email > application, that also strikes me as reasonable. > > You could (and some have) go one step further and attempt to make a > connection to whatever address that test resolved, on port 25, and see if > something answers. You could go even further and try to interact via SMTP > with the server you find there, and test to see if the RFC5322.From address > responds 250 to RCPT. But those are far more heavyweight tests, which can > add substantial time to DMARC processing, and such tests can get you > blocked from further interaction with those sites as they look like > address harvesting probes. > > Wildcards are a fact of life. We will make no progress asserting that > everyone has to stop using them because they muddy DMARC's waters. DMARC > could confirm on getting a positive MX reply that there is (or is not) a > wildcard MX in play, but I don't know how you would use that information > because the answer is the same both for "real" names and "fake" ones. Is > this the basis for your position that the triple query done today is > inadequate? > > -MSK >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc