Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Douglas Foster <[e-mail]>]

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 [e-mail], 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 <[e-mail]>
wrote:

> On Thu, May 6, 2021 at 8:14 PM Douglas Foster <
> [e-mail]> 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
>