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

[Doug Foster]

I was misinterpretation the language to require detection whether any host 
existed in the zone, rather than checking whether there is a host name which 
matches the domain name.  Thank you to Murray for straightening me out.

 

That aside, we still have a problem.   The specification is applying SPF-type 
logic to an address that has no necessary connection to SPF.   A typical 
advertising message, sent be a third party, will pass SPF using the third-party 
sender’s domain.The message From address becomes a label to identify the 
client organization in some manner, and possibly to identify the identity of 
the marketing campaign.  The domain name used for that purpose may not exist 
anywhere else, often does not accept replies, and may not exist as a mail 
server domain anywhere.Consequently, these may very well be unregistered 
domains, but it may be reasonable to insist that domain owners get them 
registered to avoid false positives from the test.   The least disruptive test 
will be for NS.   Anything stricter will produce false positives.

 

The logic that seems to work is:

-  Check SPF and DKIM for domain alignment.   If the DMARC criteria are 
satisfied by either method, the message domain does not need to exist, because 
it has been validated.

-  If the message does not pass DMARC alignment, then we need to look 
for a DMARC policy to see if P/SP/NP applies.  If NP applies, and NS does not 
exist, the NP policy is applied.

 

Using the example domain from the document, I am assuming that we are trying to 
block all three of these non-existent domains:

-  T4x.gov.example

-  Spammer.t4x.gov.example

-  Spammer.tax.gov.example

If the goal is only to block t4x.gov.example, then the current NP algorithm is 
slightly less problematic.

 

Doug Foster

 

 

From: Tim Wicinski [mailto:tjw.i...@gmail.com] 
Sent: Thursday, November 19, 2020 11:04 PM
To: fost...@bayviewphysicians.com
Cc: IETF DMARC WG
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

 

Doug

 

In looking for domain presence most folks will look at the domain itself.  
There are a few web tools to enumerate

such as https://dnschecker.org/ 

 

Some examples

https://dnschecker.org/#MX/dmarc.org

https://dnschecker.org/#TXT/dmarc.org

https://dnschecker.org/#TXT/_dmarc.dmarc.org

 

There are unix tools - such as 'dig' - which are also quite useful.

 

hope this helps

tim

 

 

On Thu, Nov 19, 2020 at 10:44 PM Douglas E. Foster 
 wrote:

Time to show my ignorance again.

 

How do I check a domain for presence or absence of A, , or MX records?

I thought most domains were protected from enumeration, so one had to know a 
name to find out if it is defined

 

DF

 

 


  _  


From: "Douglas E. Foster" 
Sent: 11/19/20 9:27 PM
To: "IETF DMARC WG" 
Subject: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

 

Thank you for the pointer Eric.

 

Can someone explain why the chosen algorithm, which requires testing multiple 
conditions, is preferable to a single query for a name server record?   
Minimizing DNS traffic has been part of our recent discussion, and minimizing 
software complexity is always a good thing.

 

Can someone also explain why the DMARC appendix takes such a strong stance 
against all queries for non-existent domains, regardless of technique?  It 
seems like the philosophical incompatibilities need to be addressed before both 
documents advance.

 

DMARC is specified only as a test for the RFC5322.From domain.   
RFC5321.MailFrom domains may also be non-existent.  They will return SPF NONE, 
but that is an ambiguous result, and SPF has no organization default mechanism. 
  

*   Is there data to indicate whether evaluators have found that checking 
the RFC5321.MailFrom for non-existence is useful?   
*   Suppose that the NP policy becomes generalized, and a domain has 
asserted a "must-exist" DMARC policy.   Should a non-existent subdomain used in 
the RFC5321.MailFrom address be treated skeptically?

I can imagine a scenario where a spammer uses a bogus subdomain of a legitimate 
organization, in an attempt to get whitelisted by spam filters which primarily 
evaluate the RFC5321.MailFrom address.   This attack could be paired with an 
unrelated and non-DMARC RFC5322.From address which is newly minted or otherwise 
not generally known to be suspicious,   So my instinct is that some extension 
of DMARC to the SMTP address will be beneficial.

 

Doug Foster

 

 

 

 


  _  


From: "Chudow, Eric B CIV NSA DSAW (USA)" 
Sent: 11/19/20 5:31 PM
To: 'Doug Foster' , 'IETF DMARC WG' 

Cc: "'dmarc-cha...@ietf.org'" 
Subject: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

 

Section 2.7. defines a non-existent domain as "a domain for which there is an 
NXDOMAIN or NODATA res

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

[Murray S. Kucherawy]

On Sat, Nov 21, 2020 at 5:32 PM Douglas E. Foster  wrote:

> On tree walk, I was working from John Levine's proposal, which assumes
> that a tree walk has to be distance limited for performance reasons.   He
> tentatively proposed four levels.   If you walk up the tree and find no
> DMARC entry, the walk stops with the conclusion that no policy has been
> issued.   This approach works if (and only if) the tree exists, so that the
> organization can place a policy at every fourth level.   The approach
> cannot work if the tree can be extended with non-existent domains.It
> also conflicts with the PSD proposal which requires checking the top of the
> tree structure.
>

What does "extended with non-existent domains" mean in the context of a
tree walk?  You're going to have to give an example.

I had considered the top-down approach also, for the same reasons as you
> mentioned.   I assumed that it would be rejected because of the load placed
> on upper levels of the DNS hierarchy.
>

It strikes me that the infrastructure near the root of the tree is likely
very robust compared to that at many leaf nodes.

For the moment, it is a DMARC issue to me because DMARC has accepted the
> notion that unregistered domains are acceptable by default.   If that can
> be changed, I agree that there are other documents that need to be updated
> as well.
>

I think that assertion goes too far.  As I recall, DMARC doesn't claim that
unregistered domains are acceptable by default.  Rather, it cannot make an
assertion about a domain for which a policy cannot be found.  That's
certainly true of an unregistered domain.  DMARC follows DKIM and SPF in
this regard; they can only make assertions about a message when the parts
fall into place.  When they don't, none of those protocols can form a
conclusion.  That's different from deciding something is "acceptable".

In any case, it's unclear to me whether "bounce/discard anything from a
domain that appears not to exist" fits inside DMARC.  If you believe the
entire ecosystem should be doing this, not just DMARC-aware operators, then
I suggest these are the wrong documents in which to push for it.

-MSK
___
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

[Douglas E. Foster]

I am arguing for the position that all unregistered domains are inherently 
invalid, because they are not registered.

PSD for DMARC proposes that non-existent domains should be blocked.In their 
discussions, I remember the UK government reporting that they had registered 
27,000 domains simply so they could publish SPF -ALL, in an attempt to block 
spammers from spoofing their government agencies.   I have a problem with the 
definition they chose in their document, but I fully agree that this is a 
problem that should be fixed.

They have also suggested that their "np" policy has general applicability, an 
argument which I find compelling.   By "general", I mean non-existent TLDs, 
non-existent public suffixes below the TLD, non-existent organizations, and 
non-existent subdomains of organizations.

Their experience demonstrates that an undefined domain is very difficult to 
protect.


On tree walk, I was working from John Levine's proposal, which assumes that a 
tree walk has to be distance limited for performance reasons.   He tentatively 
proposed four levels.   If you walk up the tree and find no DMARC entry, the 
walk stops with the conclusion that no policy has been issued.   This approach 
works if (and only if) the tree exists, so that the organization can place a 
policy at every fourth level.   The approach cannot work if the tree can be 
extended with non-existent domains.It also conflicts with the PSD proposal 
which requires checking the top of the tree structure.

I had considered the top-down approach also, for the same reasons as you 
mentioned.   I assumed that it would be rejected because of the load placed on 
upper levels of the DNS hierarchy.

But when mulling the PSD problem with the tree-walk problem, I realized the 
unifying problem in all of these scenarios was unregistered domains.   
Eventually the problem became further defined as, "Why should unregistered 
domains be considered acceptable by default, despite a network-wide requirement 
for all domains to be registered."

For the moment, it is a DMARC issue to me because DMARC has accepted the notion 
that unregistered domains are acceptable by default.   If that can be changed, 
I agree that there are other documents that need to be updated as well.

DF



From: "Murray S. Kucherawy" 
Sent: 11/21/20 8:05 PM
To: Doug Foster 
Cc: "dmarc@ietf.org" 
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

On Sat, Nov 21, 2020 at 5:02 PM Murray S. Kucherawy  wrote:

On Sat, Nov 21, 2020 at 3:12 PM Douglas E. Foster 
 wrote:

- If unregistered domains are tolerated, PSD for DMARC helps address the 
problem of a unauthorized domains underneath a public suffix, such as 
"example.uk".  But what DMARC policy will solve the problem of an invalid TLD, 
such as "example.q"?

Why is this a DMARC problem that needs solving?

- If unregistered domains are tolerated, then a limited-scope tree walk becomes 
unusable.   A spammer would be able to  fabricate a few levels of non-existent 
subdomains, and suddenly PayPal.com becomes a domain tree with no detectable 
DMARC policy.

You're going to have to give us an example of what you're imagining here.  
Presumably fabricating a few levels of non-existent subdomains of paypal.com 
would look like foo.bar.baz.paypal.com; a simple tree walk then would be to 
look for records in these places:

foo.bar.baz.paypal.com
bar.baz.paypal.com
baz.paypal.com
paypal.com

I would expect a policy to be present at least at "paypal.com", so the walk 
stops there.  How is that "unusable"?

Someone in DNSOP, I think, proposed doing the tree walk in the other direction. 
 The reason: If you're going to get an NXDOMAIN, it is more likely to come 
earlier, and it's dispositive that way.  For instance, if the above sequence is 
reversed, you would probably get an NXDOMAIN at the second query 
("baz.paypal.com") and then you know you don't need to look any further.

-MSK
___
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

[Murray S. Kucherawy]

On Sat, Nov 21, 2020 at 5:02 PM Murray S. Kucherawy 
wrote:

> On Sat, Nov 21, 2020 at 3:12 PM Douglas E. Foster  40bayviewphysicians@dmarc.ietf.org> wrote:
>
>> - If unregistered domains are tolerated, PSD for DMARC helps address the
>> problem of a unauthorized domains underneath a public suffix, such as "
>> example.uk".  But what DMARC policy will solve the problem of an invalid
>> TLD, such as "example.q"?
>>
>
> Why is this a DMARC problem that needs solving?
>
> - If unregistered domains are tolerated, then a limited-scope tree walk
>> becomes unusable.   A spammer would be able to  fabricate a few levels of
>> non-existent subdomains, and suddenly PayPal.com becomes a domain tree with
>> no detectable DMARC policy.
>>
>
> You're going to have to give us an example of what you're imagining here.
> Presumably fabricating a few levels of non-existent subdomains of
> paypal.com would look like foo.bar.baz.paypal.com; a simple tree walk
> then would be to look for records in these places:
>
> foo.bar.baz.paypal.com
> bar.baz.paypal.com
> baz.paypal.com
> paypal.com
>
> I would expect a policy to be present at least at "paypal.com", so the
> walk stops there.  How is that "unusable"?
>

Someone in DNSOP, I think, proposed doing the tree walk in the other
direction.  The reason: If you're going to get an NXDOMAIN, it is more
likely to come earlier, and it's dispositive that way.  For instance, if
the above sequence is reversed, you would probably get an NXDOMAIN at the
second query ("baz.paypal.com") and then you know you don't need to look
any further.

-MSK
___
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

[Murray S. Kucherawy]

On Sat, Nov 21, 2020 at 3:12 PM Douglas E. Foster  wrote:

> - If unregistered domains are tolerated, PSD for DMARC helps address the
> problem of a unauthorized domains underneath a public suffix, such as "
> example.uk".  But what DMARC policy will solve the problem of an invalid
> TLD, such as "example.q"?
>

Why is this a DMARC problem that needs solving?

- If unregistered domains are tolerated, then a limited-scope tree walk
> becomes unusable.   A spammer would be able to  fabricate a few levels of
> non-existent subdomains, and suddenly PayPal.com becomes a domain tree with
> no detectable DMARC policy.
>

You're going to have to give us an example of what you're imagining here.
Presumably fabricating a few levels of non-existent subdomains of paypal.com
would look like foo.bar.baz.paypal.com; a simple tree walk then would be to
look for records in these places:

foo.bar.baz.paypal.com
bar.baz.paypal.com
baz.paypal.com
paypal.com

I would expect a policy to be present at least at "paypal.com", so the walk
stops there.  How is that "unusable"?

The PSL mechanism is a heuristic allowing a short-cut from the top one to
the bottom one, so there are only two lookups, based on the PSL which
provides a hint about where to jump after the first query.  But the PSL has
aspects of its management that are not desirable, and the tree walk is an
alternative.

Besides, a scope-limited tree walk conflicts with the requirements of PSD
> for DMARC.
>

Well sure; as I understand it, a tree walk would obviate the need for PSD.

An unlimited-scope tree walk has performance risks to both the evaluator
> and the DNS infrastructure.
>

So the theory goes.  I believe what John is saying is that he's asked the
DNS community, and they no longer think it's a concern, which means we
don't need to worry at least about the latter, and the former is probably
at least partially resolved by caching.

-MSK
___
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

[Murray S. Kucherawy]

On Sat, Nov 21, 2020 at 11:26 AM Douglas E. Foster <
fost...@bayviewphysicians.com> wrote:

> Does a transient outage report NXDOMAIN, or a different status?
>

Depends on the nature of the outage, I suppose.  An unreachable nameserver
should typically result in a SERVFAIL, but I can imagine misconfigurations
that result in an errant NXDOMAIN.

-MSK
___
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

[Douglas E. Foster]

What are the complications to DMARC of tolerating unregistered domains?

- If unregistered domains are tolerated, PSD for DMARC helps address the 
problem of a unauthorized domains underneath a public suffix, such as 
"example.uk".  But what DMARC policy will solve the problem of an invalid TLD, 
such as "example.q"?

- If unregistered domains are tolerated, then a limited-scope tree walk becomes 
unusable.   A spammer would be able to  fabricate a few levels of non-existent 
subdomains, and suddenly PayPal.com becomes a domain tree with no detectable 
DMARC policy.   Besides, a scope-limited tree walk conflicts with the 
requirements of PSD for DMARC.   An unlimited-scope tree walk has performance 
risks to both the evaluator and the DNS infrastructure.

Doug Foster



From: "Murray S. Kucherawy" 
Sent: 11/21/20 2:12 PM
To: Doug Foster 
Cc: Doug Foster , IETF DMARC WG 

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

On Sat, Nov 21, 2020 at 9:02 AM Douglas E. Foster 
 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/ doesn't.  If you have a message that fails the 
latter test but passes the former, doe

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

[Douglas E. Foster]

Does a transient outage report NXDOMAIN, or a different status?

 Original message 
From: "Murray S. Kucherawy"  
Date: 11/21/20  2:12 PM  (GMT-05:00) To: Doug Foster 
 Cc: Doug Foster 
, IETF DMARC WG 
 Subject: Re: [dmarc-ietf] Second WGLC for 
draft-ietf-dmarc-psd: Definition of NP 
On Sat, Nov 21, 2020 at 9:02 AM Douglas E. Foster  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/ 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

___
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

[Murray S. Kucherawy]

On Sat, Nov 21, 2020 at 9:02 AM Douglas E. Foster  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/ 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
___
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

[Douglas E. Foster]

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: 
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 "

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

[Kurt Andersen (b)]

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

[Doug Foster]

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

[Douglas E. Foster]

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

[Chudow, Eric B CIV NSA DSAW (USA)]

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] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

[Murray S. Kucherawy]

On Thu, Nov 19, 2020 at 7:44 PM Douglas E. Foster  wrote:

> How do I check a domain for presence or absence of A, , or MX records?
> I thought most domains were protected from enumeration, so one had to know
> a name to find out if it is defined
>

Do you mean what does the DNS question look like?  Or what tool can you use
to make the query yourself?  Or something else?

-MSK
___
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

[Tim Wicinski]

Doug

In looking for domain presence most folks will look at the domain itself.
There are a few web tools to enumerate
such as https://dnschecker.org/

Some examples
https://dnschecker.org/#MX/dmarc.org
https://dnschecker.org/#TXT/dmarc.org
https://dnschecker.org/#TXT/_dmarc.dmarc.org

There are unix tools - such as 'dig' - which are also quite useful.

hope this helps
tim


On Thu, Nov 19, 2020 at 10:44 PM Douglas E. Foster  wrote:

> Time to show my ignorance again.
>
> How do I check a domain for presence or absence of A, , or MX records?
> I thought most domains were protected from enumeration, so one had to know
> a name to find out if it is defined
>
> DF
>
>
> --
> *From*: "Douglas E. Foster" 
> *Sent*: 11/19/20 9:27 PM
> *To*: "IETF DMARC WG" 
> *Subject*: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd:
> Definition of NP
>
> Thank you for the pointer Eric.
>
> Can someone explain why the chosen algorithm, which requires testing
> multiple conditions, is preferable to a single query for a name server
> record?   Minimizing DNS traffic has been part of our recent discussion,
> and minimizing software complexity is always a good thing.
>
> Can someone also explain why the DMARC appendix takes such a strong stance
> against all queries for non-existent domains, regardless of technique?  It
> seems like the philosophical incompatibilities need to be addressed before
> both documents advance.
>
> DMARC is specified only as a test for the RFC5322.From domain.
> RFC5321.MailFrom domains may also be non-existent.  They will return SPF
> NONE, but that is an ambiguous result, and SPF has no organization default
> mechanism.
>
>- Is there data to indicate whether evaluators have found that
>checking the RFC5321.MailFrom for non-existence is useful?
>- Suppose that the NP policy becomes generalized, and a domain has
>asserted a "must-exist" DMARC policy.   Should a non-existent subdomain
>used in the RFC5321.MailFrom address be treated skeptically?
>
> I can imagine a scenario where a spammer uses a bogus subdomain of a
> legitimate organization, in an attempt to get whitelisted by spam filters
> which primarily evaluate the RFC5321.MailFrom address.   This attack could
> be paired with an unrelated and non-DMARC RFC5322.From address which is
> newly minted or otherwise not generally known to be suspicious,   So my
> instinct is that some extension of DMARC to the SMTP address will be
> beneficial.
>
> Doug Foster
>
>
>
>
> ------
> *From*: "Chudow, Eric B CIV NSA DSAW (USA)" 
> *Sent*: 11/19/20 5:31 PM
> *To*: 'Doug Foster' , 'IETF DMARC WG' <
> dmarc@ietf.org>
> *Cc*: "'dmarc-cha...@ietf.org'" 
> *Subject*: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd:
> Definition of NP
>
> 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.
> Also, even if there is no SPF record, the domain may still send email, but
> then it might be held to a more stringent DMARC policy that would further
> penalize it for not having an SPF record.
>
> Also, for the revision of the document I like the way that the three parts
> of the experiment are now laid out more clearly. My only comment is that
> the title of Appendix A is overly specific to just one of the experiments
> and so should be broader.
>
> Thanks,
>
> Eric Chudow
> DoD Cybersecurity Mitigations
>
> From: Doug Foster 
> Sent: Tuesday, November 17, 2020 9:46 AM
> To: 'IETF DMARC WG' 
> Cc: dmarc-cha...@ietf.org
> Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition
> of NP
>
> I did not see a definition of a "non-existent domain" (the np policy).   A
> definition is needed.
>
> To my thinking, the obvious rule should be to query for a NS record for
> the domain.  If the record exists, then the domain owner could create a
> DMARC record for that domain, or could create a default entry for the
> domain at the organizational level.  If no record exists, it is because the
> domain owner chose to not create on

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

[John Levine]

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] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

[Douglas E. Foster]

Time to show my ignorance again.

How do I check a domain for presence or absence of A, , or MX records?
I thought most domains were protected from enumeration, so one had to know a 
name to find out if it is defined

DF



From: "Douglas E. Foster" 
Sent: 11/19/20 9:27 PM
To: "IETF DMARC WG" 
Subject: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

Thank you for the pointer Eric.

Can someone explain why the chosen algorithm, which requires testing multiple 
conditions, is preferable to a single query for a name server record?   
Minimizing DNS traffic has been part of our recent discussion, and minimizing 
software complexity is always a good thing.

Can someone also explain why the DMARC appendix takes such a strong stance 
against all queries for non-existent domains, regardless of technique?  It 
seems like the philosophical incompatibilities need to be addressed before both 
documents advance.

DMARC is specified only as a test for the RFC5322.From domain.   
RFC5321.MailFrom domains may also be non-existent.  They will return SPF NONE, 
but that is an ambiguous result, and SPF has no organization default mechanism. 
 

- Is there data to indicate whether evaluators have found that checking the 
RFC5321.MailFrom for non-existence is useful?
- Suppose that the NP policy becomes generalized, and a domain has asserted a 
"must-exist" DMARC policy.   Should a non-existent subdomain used in the 
RFC5321.MailFrom address be treated skeptically?

I can imagine a scenario where a spammer uses a bogus subdomain of a legitimate 
organization, in an attempt to get whitelisted by spam filters which primarily 
evaluate the RFC5321.MailFrom address.   This attack could be paired with an 
unrelated and non-DMARC RFC5322.From address which is newly minted or otherwise 
not generally known to be suspicious,   So my instinct is that some extension 
of DMARC to the SMTP address will be beneficial.

Doug Foster



From: "Chudow, Eric B CIV NSA DSAW (USA)" 
Sent: 11/19/20 5:31 PM
To: 'Doug Foster' , 'IETF DMARC WG' 

Cc: "'dmarc-cha...@ietf.org'" 
Subject: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

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. Also, even 
if there is no SPF record, the domain may still send email, but then it might 
be held to a more stringent DMARC policy that would further penalize it for not 
having an SPF record.

Also, for the revision of the document I like the way that the three parts of 
the experiment are now laid out more clearly. My only comment is that the title 
of Appendix A is overly specific to just one of the experiments and so should 
be broader.

Thanks,

Eric Chudow
DoD Cybersecurity Mitigations

From: Doug Foster 
Sent: Tuesday, November 17, 2020 9:46 AM
To: 'IETF DMARC WG' 
Cc: dmarc-cha...@ietf.org
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

I did not see a definition of a "non-existent domain" (the np policy).   A 
definition is needed.

To my thinking, the obvious rule should be to query for a NS record for the 
domain.  If the record exists, then the domain owner could create a DMARC 
record for that domain, or could create a default entry for the domain at the 
organizational level.  If no record exists, it is because the domain owner 
chose to not create one.

However, the DMARC Bis document conflicts strongly with this.  In section A.4, 
it suggest several ways to do a test of this type, then repudiates all of them. 
 NS lookup is not one of the mentioned options.

There is a possible second-level policy test for a "mail-enabled domain".  I 
would define that test as "MX record exists or SPF policy exists".That 
could be an additional option to NP, but should not be a replacement for it.

PSD for DMARC clearly intends for the NP policy to be a general solution to a 
general problem.If there are still objections to it becoming a general 
solution, this should be addressed soon.

Doug Foster

From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Tim Wicinski
Sent: Friday, November 13, 2020 1:42 PM
To: IETF DMARC WG
Cc: dmarc-cha...@ietf.org
Subject: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd

All

During the IESG re

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

[Douglas E. Foster]

Thank you for the pointer Eric.

Can someone explain why the chosen algorithm, which requires testing multiple 
conditions, is preferable to a single query for a name server record?   
Minimizing DNS traffic has been part of our recent discussion, and minimizing 
software complexity is always a good thing.

Can someone also explain why the DMARC appendix takes such a strong stance 
against all queries for non-existent domains, regardless of technique?  It 
seems like the philosophical incompatibilities need to be addressed before both 
documents advance.

DMARC is specified only as a test for the RFC5322.From domain.   
RFC5321.MailFrom domains may also be non-existent.  They will return SPF NONE, 
but that is an ambiguous result, and SPF has no organization default mechanism. 
 

- Is there data to indicate whether evaluators have found that checking the 
RFC5321.MailFrom for non-existence is useful?
- Suppose that the NP policy becomes generalized, and a domain has asserted a 
"must-exist" DMARC policy.   Should a non-existent subdomain used in the 
RFC5321.MailFrom address be treated skeptically?

I can imagine a scenario where a spammer uses a bogus subdomain of a legitimate 
organization, in an attempt to get whitelisted by spam filters which primarily 
evaluate the RFC5321.MailFrom address.   This attack could be paired with an 
unrelated and non-DMARC RFC5322.From address which is newly minted or otherwise 
not generally known to be suspicious,   So my instinct is that some extension 
of DMARC to the SMTP address will be beneficial.

Doug Foster



From: "Chudow, Eric B CIV NSA DSAW (USA)" 
Sent: 11/19/20 5:31 PM
To: 'Doug Foster' , 'IETF DMARC WG' 

Cc: "'dmarc-cha...@ietf.org'" 
Subject: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

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. Also, even 
if there is no SPF record, the domain may still send email, but then it might 
be held to a more stringent DMARC policy that would further penalize it for not 
having an SPF record.

Also, for the revision of the document I like the way that the three parts of 
the experiment are now laid out more clearly. My only comment is that the title 
of Appendix A is overly specific to just one of the experiments and so should 
be broader.

Thanks,

Eric Chudow
DoD Cybersecurity Mitigations

From: Doug Foster 
Sent: Tuesday, November 17, 2020 9:46 AM
To: 'IETF DMARC WG' 
Cc: dmarc-cha...@ietf.org
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

I did not see a definition of a "non-existent domain" (the np policy).   A 
definition is needed.

To my thinking, the obvious rule should be to query for a NS record for the 
domain.  If the record exists, then the domain owner could create a DMARC 
record for that domain, or could create a default entry for the domain at the 
organizational level.  If no record exists, it is because the domain owner 
chose to not create one.

However, the DMARC Bis document conflicts strongly with this.  In section A.4, 
it suggest several ways to do a test of this type, then repudiates all of them. 
 NS lookup is not one of the mentioned options.

There is a possible second-level policy test for a "mail-enabled domain".  I 
would define that test as "MX record exists or SPF policy exists".That 
could be an additional option to NP, but should not be a replacement for it.

PSD for DMARC clearly intends for the NP policy to be a general solution to a 
general problem.If there are still objections to it becoming a general 
solution, this should be addressed soon.

Doug Foster

From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Tim Wicinski
Sent: Friday, November 13, 2020 1:42 PM
To: IETF DMARC WG
Cc: dmarc-cha...@ietf.org
Subject: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd

All

During the IESG reviews of draft-ietf-dmarc-psd, there were several issues 
raised with some of the document.   Most of them are editorial but the one big 
item was the description of the Experiment.   The chairs sat down and broke out 
the experiment section into three separate experiments, and included language 
on how to capture the data to confirm how the experiment worked.

It's enough of a change that we wanted to do a second working group last c

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

[Chudow, Eric B CIV NSA DSAW (USA)]

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. Also, even 
if there is no SPF record, the domain may still send email, but then it might 
be held to a more stringent DMARC policy that would further penalize it for not 
having an SPF record. 

Also, for the revision of the document I like the way that the three parts of 
the experiment are now laid out more clearly.  My only comment is that the 
title of Appendix A is overly specific to just one of the experiments and so 
should be broader.

Thanks,

Eric Chudow
DoD Cybersecurity Mitigations

From: Doug Foster  
Sent: Tuesday, November 17, 2020 9:46 AM
To: 'IETF DMARC WG' 
Cc: dmarc-cha...@ietf.org
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

I did not see a definition of a “non-existent domain” (the np policy).   A 
definition is needed.

To my thinking, the obvious rule should be to query for a NS record for the 
domain.  If the record exists, then the domain owner could create a DMARC 
record for that domain, or could create a default entry for the domain at the 
organizational level.  If no record exists, it is because the domain owner 
chose to not create one.

However, the DMARC Bis document conflicts strongly with this.  In section A.4, 
it suggest several ways to do a test of this type, then repudiates all of them. 
 NS lookup is not one of the mentioned options.

There is a possible second-level policy test for a “mail-enabled domain”.  I 
would define that test as “MX record exists or SPF policy exists”.    That 
could be an additional option to NP, but should not be a replacement for it.

PSD for DMARC clearly intends for the NP policy to be a general solution to a 
general problem.    If there are still objections to it becoming a general 
solution, this should be addressed soon.

Doug Foster


From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Tim Wicinski
Sent: Friday, November 13, 2020 1:42 PM
To: IETF DMARC WG
Cc: dmarc-cha...@ietf.org
Subject: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd


All

During the IESG reviews of draft-ietf-dmarc-psd, there were several issues 
raised with some of the document.   Most of them are editorial but the one big 
item was the description of the Experiment.   The chairs sat down and broke out 
the experiment section into three separate experiments, and included language 
on how to capture the data to confirm how the experiment worked.  

It's enough of a change that we wanted to do a second working group last call 
to make sure the working group agrees with our changes. The diff of the current 
version with the previous version is here: 

https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08&url2=draft-ietf-dmarc-psd-09

This starts a *one* week second working group last call for  
draft-ietf-dmarc-psd
Please review the changes and offer up comments to the working group.

This working group last call 20 November 2020

Thanks,

___
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

[Doug Foster]

I did not see a definition of a “non-existent domain” (the np policy).   A 
definition is needed.

 

To my thinking, the obvious rule should be to query for a NS record for the 
domain.  If the record exists, then the domain owner could create a DMARC 
record for that domain, or could create a default entry for the domain at the 
organizational level.  If no record exists, it is because the domain owner 
chose to not create one.

 

However, the DMARC Bis document conflicts strongly with this.  In section A.4, 
it suggest several ways to do a test of this type, then repudiates all of them. 
 NS lookup is not one of the mentioned options.

 

There is a possible second-level policy test for a “mail-enabled domain”.  I 
would define that test as “MX record exists or SPF policy exists”.That 
could be an additional option to NP, but should not be a replacement for it.

 

PSD for DMARC clearly intends for the NP policy to be a general solution to a 
general problem.If there are still objections to it becoming a general 
solution, this should be addressed soon.

 

Doug Foster

 

 

From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Tim Wicinski
Sent: Friday, November 13, 2020 1:42 PM
To: IETF DMARC WG
Cc: dmarc-cha...@ietf.org
Subject: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd

 

 

All

 

During the IESG reviews of draft-ietf-dmarc-psd, there were several issues 
raised with some of the document.   Most of them are editorial but the one big 
item was the description of the Experiment.   The chairs sat down and broke out 
the experiment section into three separate experiments, and included language 
on how to capture the data to confirm how the experiment worked.  

 

It's enough of a change that we wanted to do a second working group last call 
to make sure the working group agrees with our changes. The diff of the current 
version with the previous version is here: 

 

https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08 

 &url2=draft-ietf-dmarc-psd-09

 

This starts a *one* week second working group last call for  
draft-ietf-dmarc-psd

Please review the changes and offer up comments to the working group.


This working group last call 20 November 2020

 

Thanks,

 

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc