Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-ietf-dmarc-psd
On Sat, Nov 21, 2020 at 6:23 PM John Levine wrote: > It is my impression that most real From: domains are pretty short. I > don't think I've ever seen one more than four labels long that wasn't > deliberately contrived. Anyone got data on that? > I'd bet there are some in .gov or .mil, especially the latter, but otherwise I think the longest one I've seen is five, and that was not a host that receives mail. I'm sure we can all scrape our own mail logs for evidence either way. -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
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] tree walk and Org and PSD, Second WGLC for draft-ietf-dmarc-psd
In article you write: >Someone in DNSOP, I think, proposed doing the tree walk in the other >direction. Turns out that won't work because here's what you'd be checking: > _dmarc.paypal.com > _dmarc.baz.paypal.com > _dmarc.bar.baz.paypal.com > _dmarc.foo.bar.baz.paypal.com You can have a NXDOMAIN at _dmarc.paypal.com but a TXT record at _dmarc.bar.baz.paypal.com. You could certainly add heuristics and check plain baz.paypal.com to see if it gives you an NXDOMAIN stop but I have no reason to think that on average it'd actually save queries. It is my impression that most real From: domains are pretty short. I don't think I've ever seen one more than four labels long that wasn't deliberately contrived. Anyone got data on that? R's, John r...@18.183.57.64.in-addr.arpa ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC questions
In article you write: >If I'm a receiver who is going to be making some filtering decisions >based on ARC, I see that it passed by some authenticator along the way >which is fine, but my question is why I should trust that intermediary >in general? The short answer is that you shouldn't, any more than you should trust random DKIM signatures. When people were designing ARC, it seemd overcomplicated to me. Large mail systems know where all the mailing lists are so why not just whitelist them and be done with it? The answer is that legit lists leak a lot of spam and it is common for a formerly well-behaved list to start spewing spam. Most lists do little filtering beyond verifying that the From: address is a subscriber, so when a spambot steals an address book that contains both the list address and some subscribers to that list, a lot of spam leaks through. ARC lets recipient systems do retroactive filtering that the forwarding system didn't. For example, although the overall error rate of rejecting mail due to SPF -all or DMARC p=reject can be high, on incoming mail to mailing lists both are quite reliable since the kind of forwarding that breaks them is rare in that context. If I ever get around to adding ARC checks to my filters, that's the sort of thing I'll be looking for. This also means that ARC isn't useful if you don't have a reputation system to tell you where the lists and other forwarders that might add legit ARC signatures are. There's been some handwaving about how we might come up with shared DNSWLs of mailing list hosts, but it hasn't happened yet. 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
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
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
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
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
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, does that change your handling decision? If not, why do it? Q. How do we get all incoming filters to c
[dmarc-ietf] ARC questions
Hi all, long time. I finally read through the ARC spec after seeing it accidentally in mail headers wondering what it was, especially since it was so DKIM like. My barely informed take is that it allows intermediaries to say "this is what it looked like to me at this point [and before i messed it]". So far, so good. It seems that a receiver can then verify that the ARC signature especially if the "original" DKIM signature is broken. So far, so good again. If I'm a receiver who is going to be making some filtering decisions based on ARC, I see that it passed by some authenticator along the way which is fine, but my question is why I should trust that intermediary in general? I mean, this is easy if it's gmail since I know google has an interest in good email practices out of band, but what if the ARC signer is actually an attacker that I have no idea who they are? Which is to say, how do I go about trusting the ARC signer to not be doing something bad? I don't have a specific attack in mind (still too new to this), but say if spam.com ARC signs a message it adulters to its advantage how do I know that I should disregard its ARC results? Or maybe not so much disregard results per se, but not want to "accept" the changes to the original message? Ok, maybe here is an attack. Suppose this message is scrapped by a spammer since this is a public email list. It has a broken original DKIM signature but a valid ARC signature from ietf.org. The attacker takes the message, adds the Viagra scams in the body to the ARC signed message and reinjects the new message toward the targets of their choice (? mailing list members only? not sure). Or did I miss where ARC resigns the body? Or is there a tie in for ARC with the mailing list's resigned DKIM signature for the new message? Sorry so many questions, and probably misunderstanding what's going on. Mike ___ 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
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
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
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 "must be mail enabled" policy provides a simpler d
