Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
On Tue 19/Mar/2024 12:33:07 +0100 Scott Kitterman wrote: On Tuesday, March 19, 2024 5:23:52 AM EDT Alessandro Vesely wrote: On Mon 18/Mar/2024 21:37:02 +0100 Scott Kitterman wrote: > On March 18, 2024 6:40:54 PM UTC, Alessandro Vesely wrote: On Mon 18/Mar/2024 09:14:26 +0100 Dotzero wrote: On Mon, Mar 18, 2024 at 2:38 AM John R Levine wrote: On Sun, 17 Mar 2024, Dotzero wrote: Whenever mail is sent, there is a risk that an overly permissive source may send mail which will receive a DMARC pass result that was not, in fact, authorized by the Domain Owner. These false positives may lead to issues when systems interpret DMARC pass results to indicate a message is in some way authentic. They also allow such unauthorized senders to evade the Domain Owner's requested message handling for authentication failures. I have a problem with this 2nd paragraph and believe it is factually incorrect. The Domain Owner has in fact authorized the message(s) as a result of an overly permissive approach. I would suggest that in fact any resulting DMARC pass is technically NOT a false positive because it is authorized by the overly permissive approach. Seems to me we it depends on what you think "authorized" means. My sense is I told you it's OK to send the message, yours seme to be that any host on an IP in the SPF record or anyone who steals your DKIM key is authorized by definition. Is there some other wording that can make the difference clear? Here's a quick stab at some modified wording for the second paragraph: Whenever mail is sent, there is a risk that an overly permissive source may send mail which will receive a DMARC pass result that was not, in fact, intended by the Domain Owner. These results may lead to issues when systems interpret DMARC pass results to indicate a message is in some way authentic. They also allow such unauthorized senders to evade the Domain Owner's intended message handling for authentication failures. That's better. At least it's formally correct. Still, it is rather obscure for an average reader. The attempt to make this issue general, in the sense that it is valid for SPF and DKIM alike, makes no sense. Stealing a DKIM key is not comparable to an overly permissive SPF record. The text should be terser and clearer, possibly with an example. No one said anything about stealing a DKIM key. "anyone who steals your DKIM key is authorized by definition" https://mailarchive.ietf.org/arch/msg/dmarc/h_ytb51KHHkQTyCMfGMs9NPXmQo OK. That's not what I described. Here's a more detailed exposition. Let's take a case where a provider sends mail on behalf of multiple customers, for whatever reason. Customer A uses example.biz and customer B uses example.com. When the provider receives an email for transmission on behalf of a customer it has to determine if it should send it or not, so it has controls in place. First, it determines if the mail was submitted by a customer and in our example it is, but it is Customer A sending the message, but the 5322.From in the message is in example.com. At this point a well managed provider would exercise another control and determine that while Customer A is a customer and example.com is a domain for which they send mail, Customer A is not authorized to use example.com and decline to send the mail. In the cases people have described seeing, the provider does not have such a control and sends the mail. Since Customer B has listed the provider's MTAs in their SPF record, if the provider sends the mail, it passes SPF (and DMARC), which is bad. Let's take that a step further: Customer B, realizing that this provider is not so well ordered uses the "?" qualifier in example.com's SPF record, so the mail doesn't pass SPF (and DMARC) any more. This is great, except: Let's look at the case where this provider also does DKIM signing for their customer's mail and have arranged to have secret keys for signing mail for both example.biz and example.com and both Customer A and Customer B have published DKIM key records in DNS for their domains. Is this a common pattern? So, again, Customer A is sending mail through the provider with 5322.From of example.com. We've already established that the provider does not have a control in place to prevent this. The provider has an appropriate secret key available to sign the mail (no one stole anything). If the provider signs the mail and sends it, it has a valid signature and passes DKIM (and DMARC), which is bad. How does the provider sign? * apply multiple signatures, one for each key it has, * match the From: domain, or * match the SMTP AUTH domain? Does the provider generate their own keys and have clients put a CNAME? This is all about internal controls that appear to be missing on an unfortunately common basis. The SPF part of the above is pretty simple and is a problem today for domains that haven't bothered with DKIM because it's "too hard
Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
On Tuesday, March 19, 2024 5:23:52 AM EDT Alessandro Vesely wrote: > On Mon 18/Mar/2024 21:37:02 +0100 Scott Kitterman wrote: > > On March 18, 2024 6:40:54 PM UTC, Alessandro Vesely wrote: > >>On Mon 18/Mar/2024 09:14:26 +0100 Dotzero wrote: > >>> On Mon, Mar 18, 2024 at 2:38 AM John R Levine wrote: > On Sun, 17 Mar 2024, Dotzero wrote: > >> Whenever mail is sent, there is a risk that an overly permissive > >> source > >> may send mail which will receive a DMARC pass result that was not, in > >> fact, authorized by the Domain Owner. These false positives may lead > >> to issues when systems interpret DMARC pass results to indicate > >> a message is in some way authentic. They also allow such unauthorized > >> senders to evade the Domain Owner's requested message handling for > >> authentication failures. > > > > I have a problem with this 2nd paragraph and believe it is factually > > incorrect. The Domain Owner has in fact authorized the message(s) as > > a result of an overly permissive approach. I would suggest that in > > fact any resulting DMARC pass is technically NOT a false positive > > because it is authorized by the overly permissive approach.. > Seems to me we it depends on what you think "authorized" means. My > sense is I told you it's OK to send the message, yours seme to be that > any host on an IP in the SPF record or anyone who steals your DKIM key > is authorized by definition. > > Is there some other wording that can make the difference clear? > >>> > >>> Here's a quick stab at some modified wording for the second paragraph: > >>> > >>> Whenever mail is sent, there is a risk that an overly permissive source > >>> may send mail which will receive a DMARC pass result that was not, in > >>> fact, intended by the Domain Owner. These results may lead > >>> to issues when systems interpret DMARC pass results to indicate > >>> a message is in some way authentic. They also allow such unauthorized > >>> senders to evade the Domain Owner's intended message handling for > >>> authentication failures. > >> > >>That's better. At least it's formally correct. Still, it is rather > >>obscure for an average reader. > >> > >>The attempt to make this issue general, in the sense that it is valid for > >>SPF and DKIM alike, makes no sense. Stealing a DKIM key is not > >>comparable to an overly permissive SPF record. > >> > >>The text should be terser and clearer, possibly with an example. > >> > > No one said anything about stealing a DKIM key. > > "anyone who steals your DKIM key is authorized by definition" > https://mailarchive.ietf.org/arch/msg/dmarc/h_ytb51KHHkQTyCMfGMs9NPXmQo OK. That's not what I described. Here's a more detailed exposition. Let's take a case where a provider sends mail on behalf of multiple customers, for whatever reason. Customer A uses example.biz and customer B uses example.com. When the provider receives an email for transmission on behalf of a customer it has to determine if it should send it or not, so it has controls in place. First, it determines if the mail was submitted by a customer and in our example it is, but it is Customer A sending the message, but the 5322.From in the message is in example.com. At this point a well managed provider would exercise another control and determine that while Customer A is a customer and example.com is a domain for which they send mail, Customer A is not authorized to use example.com and decline to send the mail. In the cases people have described seeing, the provider does not have such a control and sends the mail. Since Customer B has listed the provider's MTAs in their SPF record, if the provider sends the mail, it passes SPF (and DMARC), which is bad. Let's take that a step further: Customer B, realizing that this provider is not so well ordered uses the "?" qualifier in example.com's SPF record, so the mail doesn't pass SPF (and DMARC) any more. This is great, except: Let's look at the case where this provider also does DKIM signing for their customer's mail and have arranged to have secret keys for signing mail for both example.biz and example.com and both Customer A and Customer B have published DKIM key records in DNS for their domains. So, again, Customer A is sending mail through the provider with 5322.From of example.com. We've already established that the provider does not have a control in place to prevent this. The provider has an appropriate secret key available to sign the mail (no one stole anything). If the provider signs the mail and sends it, it has a valid signature and passes DKIM (and DMARC), which is bad. This is all about internal controls that appear to be missing on an unfortunately common basis. The SPF part of the above is pretty simple and is a problem today for domains that haven't bothered with DKIM because it's "too hard". Once they do bother with DKIM, then
Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
On Mon 18/Mar/2024 21:37:02 +0100 Scott Kitterman wrote: On March 18, 2024 6:40:54 PM UTC, Alessandro Vesely wrote: On Mon 18/Mar/2024 09:14:26 +0100 Dotzero wrote: On Mon, Mar 18, 2024 at 2:38 AM John R Levine wrote: On Sun, 17 Mar 2024, Dotzero wrote: Whenever mail is sent, there is a risk that an overly permissive source may send mail which will receive a DMARC pass result that was not, in fact, authorized by the Domain Owner. These false positives may lead to issues when systems interpret DMARC pass results to indicate a message is in some way authentic. They also allow such unauthorized senders to evade the Domain Owner's requested message handling for authentication failures. I have a problem with this 2nd paragraph and believe it is factually incorrect. The Domain Owner has in fact authorized the message(s) as a result of an overly permissive approach. I would suggest that in fact any resulting DMARC pass is technically NOT a false positive because it is authorized by the overly permissive approach.. Seems to me we it depends on what you think "authorized" means. My sense is I told you it's OK to send the message, yours seme to be that any host on an IP in the SPF record or anyone who steals your DKIM key is authorized by definition. Is there some other wording that can make the difference clear? Here's a quick stab at some modified wording for the second paragraph: Whenever mail is sent, there is a risk that an overly permissive source may send mail which will receive a DMARC pass result that was not, in fact, intended by the Domain Owner. These results may lead to issues when systems interpret DMARC pass results to indicate a message is in some way authentic. They also allow such unauthorized senders to evade the Domain Owner's intended message handling for authentication failures. That's better. At least it's formally correct. Still, it is rather obscure for an average reader. The attempt to make this issue general, in the sense that it is valid for SPF and DKIM alike, makes no sense. Stealing a DKIM key is not comparable to an overly permissive SPF record. The text should be terser and clearer, possibly with an example. No one said anything about stealing a DKIM key. "anyone who steals your DKIM key is authorized by definition" https://mailarchive.ietf.org/arch/msg/dmarc/h_ytb51KHHkQTyCMfGMs9NPXmQo Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
On March 18, 2024 6:53:29 PM UTC, John R Levine wrote: >On Mon, 18 Mar 2024, Alessandro Vesely wrote: >> The text should be terser and clearer, possibly with an example. > >I would be happy to remove the whole thing, since it's only distantly related >to defining or implementing DMARC. I disagree. I think this is a foreseeable risk, so we need to document it. I think the current text strikes the right balance between being silent and being a how-to. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
On March 18, 2024 6:40:54 PM UTC, Alessandro Vesely wrote: >On Mon 18/Mar/2024 09:14:26 +0100 Dotzero wrote: >> On Mon, Mar 18, 2024 at 2:38 AM John R Levine wrote: >>> On Sun, 17 Mar 2024, Dotzero wrote: > Whenever mail is sent, there is a risk that an overly permissive source > may send mail which will receive a DMARC pass result that was not, in > fact, authorized by the Domain Owner. These false positives may lead > to issues when systems interpret DMARC pass results to indicate > a message is in some way authentic. They also allow such unauthorized > senders to evade the Domain Owner's requested message handling for > authentication failures. >>> I have a problem with this 2nd paragraph and believe it is factually incorrect. The Domain Owner has in fact authorized the message(s) as a result of an overly permissive approach. I would suggest that in fact any resulting DMARC pass is technically NOT a false positive because it is authorized by the overly permissive approach.. >>> >>> Seems to me we it depends on what you think "authorized" means. My sense >>> is I told you it's OK to send the message, yours seme to be that any host >>> on an IP in the SPF record or anyone who steals your DKIM key is authorized >>> by definition. >>> >>> Is there some other wording that can make the difference clear? >> >> Here's a quick stab at some modified wording for the second paragraph: >> >> Whenever mail is sent, there is a risk that an overly permissive source >> may send mail which will receive a DMARC pass result that was not, in >> fact, intended by the Domain Owner. These results may lead >> to issues when systems interpret DMARC pass results to indicate >> a message is in some way authentic. They also allow such unauthorized >> senders to evade the Domain Owner's intended message handling for >> authentication failures. > > >That's better. At least it's formally correct. Still, it is rather obscure >for an average reader. > >The attempt to make this issue general, in the sense that it is valid for SPF >and DKIM alike, makes no sense. Stealing a DKIM key is not comparable to an >overly permissive SPF record. > >The text should be terser and clearer, possibly with an example. > No one said anything about stealing a DKIM key. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
Now with Mike's tweak: Add this to 11.1 Authentication Methods Both of the email authentication methods that underlie DMARC provide some assurance that an email was transmitted by an MTA which is authorized to do so. SPF policies map domain names to sets of authorized MTAs [ref to RFC 7208, section 11.4]. Verified DKIM signatures indicate that an email was transmitted by an MTA with access to a private key that matches the published DKIM key record. Whenever mail is sent, there is a risk that an overly permissive source may send mail that will receive a DMARC pass result that was not, in fact, intended by the Domain Owner. These results may lead to issues when systems interpret DMARC pass results to indicate a message is in some way authentic. They also allow such unauthorized senders to evade the Domain Owner's intended message handling for authentication failures. To avoid this risk one must ensure that no unauthorized source can add DKIM signatures to the domain's mail or transmit mail which will evaluate as SPF pass. If, nonetheless, a Domain Wwner wishes to include a permissive source in a domain's SPF record, the source can be excluded from DMARC consideration by using the '?' qualifier on the SPF record mechanism associated with that source. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
On Mon, 18 Mar 2024, Alessandro Vesely wrote: The text should be terser and clearer, possibly with an example. I would be happy to remove the whole thing, since it's only distantly related to defining or implementing DMARC. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
On Mon 18/Mar/2024 09:14:26 +0100 Dotzero wrote: On Mon, Mar 18, 2024 at 2:38 AM John R Levine wrote: On Sun, 17 Mar 2024, Dotzero wrote: Whenever mail is sent, there is a risk that an overly permissive source may send mail which will receive a DMARC pass result that was not, in fact, authorized by the Domain Owner. These false positives may lead to issues when systems interpret DMARC pass results to indicate a message is in some way authentic. They also allow such unauthorized senders to evade the Domain Owner's requested message handling for authentication failures. I have a problem with this 2nd paragraph and believe it is factually incorrect. The Domain Owner has in fact authorized the message(s) as a result of an overly permissive approach. I would suggest that in fact any resulting DMARC pass is technically NOT a false positive because it is authorized by the overly permissive approach.. Seems to me we it depends on what you think "authorized" means. My sense is I told you it's OK to send the message, yours seme to be that any host on an IP in the SPF record or anyone who steals your DKIM key is authorized by definition. Is there some other wording that can make the difference clear? Here's a quick stab at some modified wording for the second paragraph: Whenever mail is sent, there is a risk that an overly permissive source may send mail which will receive a DMARC pass result that was not, in fact, intended by the Domain Owner. These results may lead to issues when systems interpret DMARC pass results to indicate a message is in some way authentic. They also allow such unauthorized senders to evade the Domain Owner's intended message handling for authentication failures. That's better. At least it's formally correct. Still, it is rather obscure for an average reader. The attempt to make this issue general, in the sense that it is valid for SPF and DKIM alike, makes no sense. Stealing a DKIM key is not comparable to an overly permissive SPF record. The text should be terser and clearer, possibly with an example. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
On Mon, Mar 18, 2024 at 2:38 AM John R Levine wrote: > On Sun, 17 Mar 2024, Dotzero wrote: > >> Whenever mail is sent, there is a risk that an overly permissive source > >> may send mail which will receive a DMARC pass result that was not, in > >> fact, authorized by the Domain Owner. These false positives may lead > >> to issues when systems interpret DMARC pass results to indicate > >> a message is in some way authentic. They also allow such unauthorized > >> senders to evade the Domain Owner's requested message handling for > >> authentication failures. > > > I have a problem with this 2nd paragraph and believe it is factually > > incorrect. The Domain Owner has in fact authorized the message(s) as a > > result of an overly permissive approach. I would suggest that in fact any > > resulting DMARC pass is technically NOT a false positive because it is > > authorized by the overly permissive approach.. > > Seems to me we it depends on what you think "authorized" means. My sense > is I told you it's OK to send the message, yours seme to be that any host > on an IP in the SPF record or anyone who steals your DKIM key is > authorized by definition. > > Is there some other wording that can make the difference clear? > > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly Here's a quick stab at some modified wording for the second paragraph: Whenever mail is sent, there is a risk that an overly permissive source may send mail which will receive a DMARC pass result that was not, in fact, intended by the Domain Owner. These results may lead to issues when systems interpret DMARC pass results to indicate a message is in some way authentic. They also allow such unauthorized senders to evade the Domain Owner's intended message handling for authentication failures. Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
Murray S. Kucherawy skrev den 2024-03-18 04:15: It is not a false positive in that the technology did exactly what it was supposed to do; i.e., this is not a bug. We should just be clear about this. how to make dmarc fully aligned when spf +all is allowed :( it renders no go rfc is already solved ? please turn of html posting ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
On Sun, 17 Mar 2024, Dotzero wrote: Whenever mail is sent, there is a risk that an overly permissive source may send mail which will receive a DMARC pass result that was not, in fact, authorized by the Domain Owner. These false positives may lead to issues when systems interpret DMARC pass results to indicate a message is in some way authentic. They also allow such unauthorized senders to evade the Domain Owner's requested message handling for authentication failures. I have a problem with this 2nd paragraph and believe it is factually incorrect. The Domain Owner has in fact authorized the message(s) as a result of an overly permissive approach. I would suggest that in fact any resulting DMARC pass is technically NOT a false positive because it is authorized by the overly permissive approach.. Seems to me we it depends on what you think "authorized" means. My sense is I told you it's OK to send the message, yours seme to be that any host on an IP in the SPF record or anyone who steals your DKIM key is authorized by definition. Is there some other wording that can make the difference clear? Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
On March 18, 2024 3:15:42 AM UTC, "Murray S. Kucherawy" wrote: >On Mon, Mar 18, 2024 at 1:08 PM Dotzero wrote: > >> >> Add this to 11.1 Authentication Methods >>> >>> >>> Both of the email authentication methods that underlie DMARC provide >>> some assurance that an email was transmitted by an MTA which is >>> authorized to do so. SPF policies map domain names to sets of >>> authorized MTAs [ref to RFC 7208, section 11.4]. Verified DKIM >>> signatures indicate that an email was transmitted by an MTA with >>> access to a private key that matches the published DKIM key record. >>> >>> Whenever mail is sent, there is a risk that an overly permissive source >>> may send mail which will receive a DMARC pass result that was not, in >>> fact, authorized by the Domain Owner. These false positives may lead >>> to issues when systems interpret DMARC pass results to indicate >>> a message is in some way authentic. They also allow such unauthorized >>> senders to evade the Domain Owner's requested message handling for >>> authentication failures. >>> >> >> I have a problem with this 2nd paragraph and believe it is factually >> incorrect. The Domain Owner has in fact authorized the message(s) as a >> result of an overly permissive approach. I would suggest that in fact any >> resulting DMARC pass is technically NOT a false positive because it is >> authorized by the overly permissive approach.. >> >> >It's a false positive in the sense that the result is not what the Domain >Owner probably wanted to have happen. > >It is not a false positive in that the technology did exactly what it was >supposed to do; i.e., this is not a bug. > >We should just be clear about this. > >-MSK, p11g I agree. I think John's proposed text is appropriate for this. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
On March 18, 2024 1:36:29 AM UTC, John Levine wrote: >Tightened up a little, reworded in view of the fact that your own >mail provider (M*r*s*ft) may let people spoof you through shared IP ranges. > > >>11.X External Mail Sender Cross-Domain Forgery > >Add this to 11.1 Authentication Methods > I agree about this. >Both of the email authentication methods that underlie DMARC provide >some assurance that an email was transmitted by an MTA which is >authorized to do so. SPF policies map domain names to sets of >authorized MTAs [ref to RFC 7208, section 11.4]. Verified DKIM >signatures indicate that an email was transmitted by an MTA with >access to a private key that matches the published DKIM key record. > >Whenever mail is sent, there is a risk that an overly permissive source >may send mail which will receive a DMARC pass result that was not, in >fact, authorized by the Domain Owner. These false positives may lead >to issues when systems interpret DMARC pass results to indicate >a message is in some way authentic. They also allow such unauthorized >senders to evade the Domain Owner's requested message handling for >authentication failures. > >The only method to avoid this risk is to ensure that no unauthorized >source can add DKIM signatures to the domain's mail or transmit mail >which will evaluate as SPF pass. If nonetheless domain owner wishes to >include a permissive source in a domain's SPF record, the source can >be excluded from DMARC consideration by using the '?' qualifier on the >SPF record mechanism associated with that source. I'm fine with this. Thanks, Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
On Mon, Mar 18, 2024 at 1:08 PM Dotzero wrote: > > Add this to 11.1 Authentication Methods >> >> >> Both of the email authentication methods that underlie DMARC provide >> some assurance that an email was transmitted by an MTA which is >> authorized to do so. SPF policies map domain names to sets of >> authorized MTAs [ref to RFC 7208, section 11.4]. Verified DKIM >> signatures indicate that an email was transmitted by an MTA with >> access to a private key that matches the published DKIM key record. >> >> Whenever mail is sent, there is a risk that an overly permissive source >> may send mail which will receive a DMARC pass result that was not, in >> fact, authorized by the Domain Owner. These false positives may lead >> to issues when systems interpret DMARC pass results to indicate >> a message is in some way authentic. They also allow such unauthorized >> senders to evade the Domain Owner's requested message handling for >> authentication failures. >> > > I have a problem with this 2nd paragraph and believe it is factually > incorrect. The Domain Owner has in fact authorized the message(s) as a > result of an overly permissive approach. I would suggest that in fact any > resulting DMARC pass is technically NOT a false positive because it is > authorized by the overly permissive approach.. > > It's a false positive in the sense that the result is not what the Domain Owner probably wanted to have happen. It is not a false positive in that the technology did exactly what it was supposed to do; i.e., this is not a bug. We should just be clear about this. -MSK, p11g ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
On Sun, Mar 17, 2024 at 9:36 PM John Levine wrote: > Tightened up a little, reworded in view of the fact that your own > mail provider (M*r*s*ft) may let people spoof you through shared IP ranges. > > > >11.X External Mail Sender Cross-Domain Forgery > > Add this to 11.1 Authentication Methods > > > Both of the email authentication methods that underlie DMARC provide > some assurance that an email was transmitted by an MTA which is > authorized to do so. SPF policies map domain names to sets of > authorized MTAs [ref to RFC 7208, section 11.4]. Verified DKIM > signatures indicate that an email was transmitted by an MTA with > access to a private key that matches the published DKIM key record. > > Whenever mail is sent, there is a risk that an overly permissive source > may send mail which will receive a DMARC pass result that was not, in > fact, authorized by the Domain Owner. These false positives may lead > to issues when systems interpret DMARC pass results to indicate > a message is in some way authentic. They also allow such unauthorized > senders to evade the Domain Owner's requested message handling for > authentication failures. > I have a problem with this 2nd paragraph and believe it is factually incorrect. The Domain Owner has in fact authorized the message(s) as a result of an overly permissive approach. I would suggest that in fact any resulting DMARC pass is technically NOT a false positive because it is authorized by the overly permissive approach.. Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
Tightened up a little, reworded in view of the fact that your own mail provider (M*r*s*ft) may let people spoof you through shared IP ranges. >11.X External Mail Sender Cross-Domain Forgery Add this to 11.1 Authentication Methods Both of the email authentication methods that underlie DMARC provide some assurance that an email was transmitted by an MTA which is authorized to do so. SPF policies map domain names to sets of authorized MTAs [ref to RFC 7208, section 11.4]. Verified DKIM signatures indicate that an email was transmitted by an MTA with access to a private key that matches the published DKIM key record. Whenever mail is sent, there is a risk that an overly permissive source may send mail which will receive a DMARC pass result that was not, in fact, authorized by the Domain Owner. These false positives may lead to issues when systems interpret DMARC pass results to indicate a message is in some way authentic. They also allow such unauthorized senders to evade the Domain Owner's requested message handling for authentication failures. The only method to avoid this risk is to ensure that no unauthorized source can add DKIM signatures to the domain's mail or transmit mail which will evaluate as SPF pass. If nonetheless domain owner wishes to include a permissive source in a domain's SPF record, the source can be excluded from DMARC consideration by using the '?' qualifier on the SPF record mechanism associated with that source. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
It appears that Scott Kitterman said: >1. Bad mail gets DMARC pass and so DMARC policy is not applied (avoid >consequences of DMARC fail). > >2. Bad mail gets DMARC pass and something else (e.g. BIMI) does a wrong thing >(gets benefits of DMARC pass). I agree these are the two main points. Will see if I can boil the text down somewhat. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
But if we have no advice on how to detect a false Pass, how is this useful? Are we helping evaluators or just giving ourselves cover that "your disaster is not our fault because we warned you"? On Sun, Mar 17, 2024, 10:59 AM Scott Kitterman wrote: > > > On March 17, 2024 11:11:04 AM UTC, Alessandro Vesely > wrote: > >On Sat 16/Mar/2024 20:01:22 +0100 Scott Kitterman wrote: > >> On Thursday, March 14, 2024 12:24:50 PM EDT Scott Kitterman wrote: > >>> On Thursday, March 14, 2024 11:44:22 AM EDT Todd Herr wrote: > > Issue 135 is open for the subject topic. Please add your thoughts to > this thread and/or to the issue in Github. > > Thank you. > >>> > >>> [...] > >>> > >>> I think both of these should be addressed as part of this issue in > Security > >>> Considerations. > >> > >> It seems to me that, to the extent we are going to address this issue, > there > >> is agreement that Security Considerations is appropriate. Here's > proposed > >> text: > >> > >> 11.X External Mail Sender Cross-Domain Forgery > >> > >> Both of the email authentication methods which underlie DMARC > fundamentally > >> provide some degree of assurance that an email was transmitted by an > MTA which > >> is authorized to do so. SPF policies just map domain names to sets of > >> authorized MTAs [ref to RFC 7208, section 11.4]. Verified DKIM > signatures > >> indicate that an email was transmitted by an MTA with access to a > private key > >> that matches the published DKIM key record. > >> > >> When Domain Owners authorize mail to be sent by sources outside their > >> Administrative Management Domain there is a risk that an overly > permissive > >> source may send mail which will, as a result, receive a DMARC pass > result that > >> was not, in fact, authorized by the Domain Owner. These false > positives may > >> lead to issues with systems that make use of DMARC pass results to > indicate a > >> message is in some way authentic. They also allow such unauthorized > senders > >> to evade the Domain Owner's requested message handling for > authentication > >> failures. > >> > >> The only method to avoid this risk is to ensure that no overly > permissive > >> sources can successfully DKIM sign the domain's mail or transmit mail > which > >> will evaluate as SPF pass. If there are non-DMARC reasons for a domain > owner > >> to include a permissive source in a domain's SPF record, the source can > be > >> excluded from DMARC consideration by using the '?' qualifier on the SPF > record > >> mechanism associated with that source. > > > > > >That text is too long and lacks an example. > > > >The first paragraph can be omitted without losing context. BTW, Section > 11.4 of RFC 7208 is about /cross-user/ forgery, not cross-domain. > > > >The second paragraph doesn't mention SPF. Couldn't it be more direct? > For example: > > > >Domain Owners who set up SPF records which include sources outside > their > >Administrative Management Domain run the risk that an overly > permissive > >source may allow its users to send scam mail which will receive a > DMARC > >pass results that were not intended by the Domain Owner. These false > >positives [...] > > > >The third paragraph is also longer than needed. There's no need to > mention DKIM if we're talking SPF forgery. I'd also point out that the > neutral qualifier prevents quick rejection of the message, and is probably > useless for those who have ~all. (Are there MTAs who distinguish between > neutral and softfail? Are we prompting them to do so?) Perhaps mention > that this is a compromise between striking the SPF record tout-court and > allowing false positives. > > > >Most important, write "?include:example.com". An example is worth a > thousand words. > > I disagree. > > Security considerations should be a complete description of the > consideration. While the data that's been discussed about current issues > has been SPF related, there's no reason a third-party couldn't equally > screw up and sign DKIM in a similar manner. We should include both (we > discussed this pretty extensively already, let's not do it again). > > I think we need to be explicit that there are two risks: > > 1. Bad mail gets DMARC pass and so DMARC policy is not applied (avoid > consequences of DMARC fail). > > 2. Bad mail gets DMARC pass and something else (e.g. BIMI) does a wrong > thing (gets benefits of DMARC pass). > > It's not typical to put examples in security considerations. > Additionally, I think doing so would over emphasize that aspect of the > consideration. We're a technical group and so we like technical solutions, > but for this one, I think the boring and difficult policy question of not > authorizing third parties that do bad things is more important. > > Scott K > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > _
Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
On March 17, 2024 11:11:04 AM UTC, Alessandro Vesely wrote: >On Sat 16/Mar/2024 20:01:22 +0100 Scott Kitterman wrote: >> On Thursday, March 14, 2024 12:24:50 PM EDT Scott Kitterman wrote: >>> On Thursday, March 14, 2024 11:44:22 AM EDT Todd Herr wrote: Issue 135 is open for the subject topic. Please add your thoughts to this thread and/or to the issue in Github. Thank you. >>> >>> [...] >>> >>> I think both of these should be addressed as part of this issue in Security >>> Considerations. >> >> It seems to me that, to the extent we are going to address this issue, there >> is agreement that Security Considerations is appropriate. Here's proposed >> text: >> >> 11.X External Mail Sender Cross-Domain Forgery >> >> Both of the email authentication methods which underlie DMARC fundamentally >> provide some degree of assurance that an email was transmitted by an MTA >> which >> is authorized to do so. SPF policies just map domain names to sets of >> authorized MTAs [ref to RFC 7208, section 11.4]. Verified DKIM signatures >> indicate that an email was transmitted by an MTA with access to a private key >> that matches the published DKIM key record. >> >> When Domain Owners authorize mail to be sent by sources outside their >> Administrative Management Domain there is a risk that an overly permissive >> source may send mail which will, as a result, receive a DMARC pass result >> that >> was not, in fact, authorized by the Domain Owner. These false positives may >> lead to issues with systems that make use of DMARC pass results to indicate a >> message is in some way authentic. They also allow such unauthorized senders >> to evade the Domain Owner's requested message handling for authentication >> failures. >> >> The only method to avoid this risk is to ensure that no overly permissive >> sources can successfully DKIM sign the domain's mail or transmit mail which >> will evaluate as SPF pass. If there are non-DMARC reasons for a domain owner >> to include a permissive source in a domain's SPF record, the source can be >> excluded from DMARC consideration by using the '?' qualifier on the SPF >> record >> mechanism associated with that source. > > >That text is too long and lacks an example. > >The first paragraph can be omitted without losing context. BTW, Section 11.4 >of RFC 7208 is about /cross-user/ forgery, not cross-domain. > >The second paragraph doesn't mention SPF. Couldn't it be more direct? For >example: > >Domain Owners who set up SPF records which include sources outside their >Administrative Management Domain run the risk that an overly permissive >source may allow its users to send scam mail which will receive a DMARC >pass results that were not intended by the Domain Owner. These false >positives [...] > >The third paragraph is also longer than needed. There's no need to mention >DKIM if we're talking SPF forgery. I'd also point out that the neutral >qualifier prevents quick rejection of the message, and is probably useless for >those who have ~all. (Are there MTAs who distinguish between neutral and >softfail? Are we prompting them to do so?) Perhaps mention that this is a >compromise between striking the SPF record tout-court and allowing false >positives. > >Most important, write "?include:example.com". An example is worth a thousand >words. I disagree. Security considerations should be a complete description of the consideration. While the data that's been discussed about current issues has been SPF related, there's no reason a third-party couldn't equally screw up and sign DKIM in a similar manner. We should include both (we discussed this pretty extensively already, let's not do it again). I think we need to be explicit that there are two risks: 1. Bad mail gets DMARC pass and so DMARC policy is not applied (avoid consequences of DMARC fail). 2. Bad mail gets DMARC pass and something else (e.g. BIMI) does a wrong thing (gets benefits of DMARC pass). It's not typical to put examples in security considerations. Additionally, I think doing so would over emphasize that aspect of the consideration. We're a technical group and so we like technical solutions, but for this one, I think the boring and difficult policy question of not authorizing third parties that do bad things is more important. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
On Sat 16/Mar/2024 20:01:22 +0100 Scott Kitterman wrote: On Thursday, March 14, 2024 12:24:50 PM EDT Scott Kitterman wrote: On Thursday, March 14, 2024 11:44:22 AM EDT Todd Herr wrote: Issue 135 is open for the subject topic. Please add your thoughts to this thread and/or to the issue in Github. Thank you. [...] I think both of these should be addressed as part of this issue in Security Considerations. It seems to me that, to the extent we are going to address this issue, there is agreement that Security Considerations is appropriate. Here's proposed text: 11.X External Mail Sender Cross-Domain Forgery Both of the email authentication methods which underlie DMARC fundamentally provide some degree of assurance that an email was transmitted by an MTA which is authorized to do so. SPF policies just map domain names to sets of authorized MTAs [ref to RFC 7208, section 11.4]. Verified DKIM signatures indicate that an email was transmitted by an MTA with access to a private key that matches the published DKIM key record. When Domain Owners authorize mail to be sent by sources outside their Administrative Management Domain there is a risk that an overly permissive source may send mail which will, as a result, receive a DMARC pass result that was not, in fact, authorized by the Domain Owner. These false positives may lead to issues with systems that make use of DMARC pass results to indicate a message is in some way authentic. They also allow such unauthorized senders to evade the Domain Owner's requested message handling for authentication failures. The only method to avoid this risk is to ensure that no overly permissive sources can successfully DKIM sign the domain's mail or transmit mail which will evaluate as SPF pass. If there are non-DMARC reasons for a domain owner to include a permissive source in a domain's SPF record, the source can be excluded from DMARC consideration by using the '?' qualifier on the SPF record mechanism associated with that source. That text is too long and lacks an example. The first paragraph can be omitted without losing context. BTW, Section 11.4 of RFC 7208 is about /cross-user/ forgery, not cross-domain. The second paragraph doesn't mention SPF. Couldn't it be more direct? For example: Domain Owners who set up SPF records which include sources outside their Administrative Management Domain run the risk that an overly permissive source may allow its users to send scam mail which will receive a DMARC pass results that were not intended by the Domain Owner. These false positives [...] The third paragraph is also longer than needed. There's no need to mention DKIM if we're talking SPF forgery. I'd also point out that the neutral qualifier prevents quick rejection of the message, and is probably useless for those who have ~all. (Are there MTAs who distinguish between neutral and softfail? Are we prompting them to do so?) Perhaps mention that this is a compromise between striking the SPF record tout-court and allowing false positives. Most important, write "?include:example.com". An example is worth a thousand words. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
On Thursday, March 14, 2024 12:24:50 PM EDT Scott Kitterman wrote: > On Thursday, March 14, 2024 11:44:22 AM EDT Todd Herr wrote: > > Colleagues, > > > > Issue 135 is open for the subject topic. Please add your thoughts to this > > thread and/or to the issue in Github. > > > > Thank you. > > I'd suggest we discuss where to say it first. I think the right place is > security considerations, which starts: > > 11. Security Considerations > >This section discusses security issues and possible remediations >(where available) for DMARC. > > I think there are two, related questions here: > > One is the risk associated with which I'll call a false pass from one of the > underlying authentication mechanisms. > > The other is the risk associated with using DMARC results for positive > associations (as BIMI does). Even absent third party considerations, all it > takes is one compromised user account and forged messages can get a DMARC > pass. DMARC was designed to identify "bad" mail, not certify any kind of > goodness. > > I think both of these should be addressed as part of this issue in Security > Considerations. It seems to me that, to the extent we are going to address this issue, there is agreement that Security Considerations is appropriate. Here's proposed text: 11.X External Mail Sender Cross-Domain Forgery Both of the email authentication methods which underlie DMARC fundamentally provide some degree of assurance that an email was transmitted by an MTA which is authorized to do so. SPF policies just map domain names to sets of authorized MTAs [ref to RFC 7208, section 11.4]. Verified DKIM signatures indicate that an email was transmitted by an MTA with access to a private key that matches the published DKIM key record. When Domain Owners authorize mail to be sent by sources outside their Administrative Management Domain there is a risk that an overly permissive source may send mail which will, as a result, receive a DMARC pass result that was not, in fact, authorized by the Domain Owner. These false positives may lead to issues with systems that make use of DMARC pass results to indicate a message is in some way authentic. They also allow such unauthorized senders to evade the Domain Owner's requested message handling for authentication failures. The only method to avoid this risk is to ensure that no overly permissive sources can successfully DKIM sign the domain's mail or transmit mail which will evaluate as SPF pass. If there are non-DMARC reasons for a domain owner to include a permissive source in a domain's SPF record, the source can be excluded from DMARC consideration by using the '?' qualifier on the SPF record mechanism associated with that source. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
On Thursday, March 14, 2024 11:44:22 AM EDT Todd Herr wrote: > Colleagues, > > Issue 135 is open for the subject topic. Please add your thoughts to this > thread and/or to the issue in Github. > > Thank you. I'd suggest we discuss where to say it first. I think the right place is security considerations, which starts: 11. Security Considerations This section discusses security issues and possible remediations (where available) for DMARC. I think there are two, related questions here: One is the risk associated with which I'll call a false pass from one of the underlying authentication mechanisms. The other is the risk associated with using DMARC results for positive associations (as BIMI does). Even absent third party considerations, all it takes is one compromised user account and forged messages can get a DMARC pass. DMARC was designed to identify "bad" mail, not certify any kind of goodness. I think both of these should be addressed as part of this issue in Security Considerations. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
On Thu 14/Mar/2024 16:44:22 +0100 Todd Herr wrote: Issue 135 is open for the subject topic. Please add your thoughts to this thread and/or to the issue in Github. I proposed an alternative text for section 5, Policy[*]. I repeat it here with an added sentence: OLD A Domain Owner or PSO may choose not to participate in DMARC evaluation by Mail Receivers simply by not publishing an appropriate DNS TXT record for its domain(s). A Domain Owner can also choose not to have some underlying authentication technologies apply to DMARC evaluation of its domain(s). In this case, the Domain Owner simply declines to advertise participation in those schemes. For example, if the results of path authorization checks ought not to be considered as part of the overall DMARC result for a given Author Domain, then the Domain Owner does not publish an SPF policy record that can produce an SPF pass result. NEW A Domain Owner or PSO may choose not to participate in DMARC evaluation by Mail Receivers simply by not publishing an appropriate DNS TXT record for its domain(s). A Domain Owner can also adjust how some underlying authentication technologies apply to DMARC evaluation of its domain(s). To do so, the Domain Owner directly operates on its participation in those schemes. For example, if the results of path authorization checks ought not to be considered as part of the overall DMARC result for a given Author Domain, then the Domain Owner does not publish an SPF policy record, or it can use the neutral qualifier to avoid granting "pass" results to external domains (that is, for example "v=spf1 ?include:example.com -all"). Obviously, the other authentication technology has to be resiliently implemented in such case. Best Ale -- [*] https://mailarchive.ietf.org/arch/msg/dmarc/Mr0jW04HijJqeleW0sXZhWX-s3Q ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
Colleagues, Issue 135 is open for the subject topic. Please add your thoughts to this thread and/or to the issue in Github. Thank you. -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com Phone: 703-220-4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
