Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

["Murray S. Kucherawy" <[e-mail]>]

On Sat, Nov 21, 2020 at 9:02 AM Douglas E. Foster <fosterd=
[e-mail]> wrote:

> 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.
>

That is certainly a defensible assertion, but I would claim it is out of
scope for DMARC.  You're talking about a detail of SPF or perhaps of SMTP
in general, although one could also even argue that this is a local policy
decision and outside the scope of those protocols.  I suspect the SMTP
greybeards would claim that this is not part of SMTP, but rather an
enforcement choice made by implementations.

I believe this falls within the realm of what the IETF calls an
Applicability Statement, which would be a standards track document (if you
could get consensus for it).  You could also include this in the DMARC
usage document, or as non-normative advice in DMARC itself with an
explanation of why it's a good idea, if you can develop consensus to do so.

You also need to account for transient DNS outages.  If your resolver
temporarily thinks "gmail.com" doesn't exist, you will bounce all mail
coming from that domain, and you might seriously piss off your users.
There's a backscatter problem here too: If I send mail to a list you're on
and you temporarily think my domain doesn't exist and you bounce mail
coming from me, the list will unsubscribe you.

    - Unregistered names used as message From header addresses MUST
> generate DMARC FAIL and SHOULD be rejected.
>

This is more in scope for DMARC discussions, though also arguably outside
of the protocol itself, for the same reasons.  I would suggest that it's a
viable discussion for the DMARC usage document, whenever we get around to
working on that again.  But you could certainly test the working group
opinion on this point.

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.
>

These are both probably true statements, but is DMARC the right place to
wage this battle?  For example, isn't it also true for TCP connections for
which PTR records make false claims (or no claim)?

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.
>

I still don't understand what the presence or absence of NS tells you that
the presence or absence of MX/A/AAAA doesn't.  If you have a message that
fails the latter test but passes the former, does that change your handling
decision?  If not, why do it?

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.
>

That seems like a big hammer, and certainly outside of the IETF's purview.
We're not the protocol police.  You might try having this discussion in a
context like M3AAWG though; many large operators congregate there to
discuss stuff like this.

-MSK