Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?

[Alessandro Vesely <[e-mail]>]

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 <[e-mail]> wrote:
>>>>On Mon 18/Mar/2024 09:14:26 +0100 Dotzero wrote:
>>>>> On Mon, Mar 18, 2024 at 2:38 AM John R Levine <[e-mail]> 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".  Once they do bother with DKIM, then I don't see any reason to believe 
> that you won't see the DKIM part of this as well.  It's a foreseeable result 
> of using providers without appropriate internal controls.


Again, if we want to cover DKIM, we should be clearer about the mechanism used, 
consider the risk, perhaps citing Section 8.3 of DKIM.  Folding both subject 
under a common frame forces the text to be overly general, and thus less 
comprehensible.


Best
Ale
--