Re: [dmarc-ietf] Fwd: The sad state of SPF: research just presented at NDSS

[Scott Kitterman]

On March 12, 2024 11:42:11 PM UTC, John Levine  wrote:
>It appears that Scott Kitterman   said:
>>Or, as RFC 4408 and RFC 7208 warn against, ESPs don't allow customers to send 
>>mail for anything other than their own domains.  ESP customers, don't use 
>>ESPs that do this.
>
>It's not just ESPs. There's a widely reported bug that lets anyone
>whose mail is hosted at Microsoft send SPF-compliant mail pretending
>to be any other MS customer.
>
>The BreakSPF paper describes a bunch of other ways to send mail
>through various clouds such as pointing a web proxy at someone's port
>25 and sending SMTP commands inside HTTP, which works a lot more often
>than you might imagine.
>
And yet people seem surprised that there's no security when the basics of such 
things are ignored.  These are not protocol problems.

Scott K

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

Re: [dmarc-ietf] Fwd: The sad state of SPF: research just presented at NDSS

[Mark Alley]

On 3/12/2024 6:42 PM, John Levine wrote:

It appears that Scott Kitterman  said:

Or, as RFC 4408 and RFC 7208 warn against, ESPs don't allow customers to send 
mail for anything other than their own domains.  ESP customers, don't use ESPs 
that do this.

It's not just ESPs. There's a widely reported bug that lets anyone
whose mail is hosted at Microsoft send SPF-compliant mail pretending
to be any other MS customer.


Purportedly, they've tightened the connector requirements (SRS for 
anything not meeting them) that was directly related to last year's SPF 
upgrade debacle (which a popular package carrier's BIMI implementation 
was a victim of), but there are still other arguably more egregious 
methods allowed via said vendor that enable unauthenticated mail to 
become suddenly authenticated with DKIM because... "it's a feature".


I don't know how we can account for willful negligence.

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

Re: [dmarc-ietf] Fwd: The sad state of SPF: research just presented at NDSS

[John Levine]

It appears that Scott Kitterman   said:
>Or, as RFC 4408 and RFC 7208 warn against, ESPs don't allow customers to send 
>mail for anything other than their own domains.  ESP customers, don't use ESPs 
>that do this.

It's not just ESPs. There's a widely reported bug that lets anyone
whose mail is hosted at Microsoft send SPF-compliant mail pretending
to be any other MS customer.

The BreakSPF paper describes a bunch of other ways to send mail
through various clouds such as pointing a web proxy at someone's port
25 and sending SMTP commands inside HTTP, which works a lot more often
than you might imagine.

R's,
John

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

Re: [dmarc-ietf] Fwd: The sad state of SPF: research just presented at NDSS

[Scott Kitterman]

On March 12, 2024 5:37:47 PM UTC, Richard Clayton  
wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>In message , Scott
>Kitterman  writes
>
>>Or, as RFC 4408 and RFC 7208 warn against, ESPs don't allow customers to send 
>>mail for anything other than their own domains.  ESP customers, don't use 
>>ESPs 
>>that do this.
>
>leaving aside how practical this advice may be and how it would be
>possible for anyone to accurately, a priori, determine the ESPs
>abilities to control their sending arrangements ...
>
>... there's also "clouds" -- where senders are documenting the entirety
>of the cloud's IP space as being a potential sending location. Although
>it might be possible to have DNS records track actual usage as resources
>are spun up and down there's obvious issues around caching.
>
>of course we might say not to use clouds that do that ... but the "that
>do that" part of the sentence would be superfluous

The first step to finding out how feasible it is would be to try it.  I think 
we're where we are because people haven't been even attempting to sort this 
stuff out.  SPF specifically, and email authentication in general, isn't 
something magical.  You actually have to make an effort to think it through.

Scott K

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

Re: [dmarc-ietf] Fwd: Break SPF response: DKIM Only

[Douglas Foster]

Neil, to your question about mitigating false SPF PASS:

There are three possible mitigations by senders:

   - Drop the SPF policy so that messages evaluate to SPF None.   A few
   domains do this.
   - Change the SPF Policy to return SPF Neutral for cloud services, as
   currently proposed.
   - Provide a DMARC option for "DKIM only", which has been proposed and
   rejected.

All of these options depend on a sender being willing to give up SPF Pass.
 In my own reporting data, I see some occurrences of DNS Timeout on DKIM
checks, an event over which I have no control, so I don't know that even I
want to give up SPF Pass.   I don't think we can expect senders to choose
any of the options, even if all three were to be made available.

The necessary response is for evaluators to identify those domains that
reliably carry DKIM signatures, and to configure those domains for "DKIM
Only" processing at reception.   Failures should be routed to quarantine
for further investigation.Even in my relatively modest data set, I have
about 2000 domains that are candidates for this treatment.   By comparison,
I have only about 20 domains that use DKIM signatures with SPF None to
avoid the problem.

Doug Foster


On Tue, Mar 12, 2024 at 3:32 PM Neil Anuskiewicz 
wrote:

>
>
> On Mar 4, 2024, at 11:07 PM, Chuhan Wang 
> wrote:
>
> 
> Hi Douglas,
>
> Thank you for your insightful summary of our paper. I'd like to share some
> of my opinions.
>
> You mentioned clients lose control of their SPF integrity. It's one of the
> key problems exactly. Clients host their email services on email providers.
> They are required to include email providers' SPF records in their SPF
> records. However, the centralization of SPF deployment magnifies SPF
> vulnerabilities. Our results show that when the email provider is
> vulnerable, a single vulnerable SPF record can influence more than 10,000
> domains, which actually violates the assumption of SPF that domains can be
> distinguished by IP addresses.
>
> The reliance on IP addresses for sender authentication, a model that might
> have seemed reasonable 20 years ago, has now proven to be inadequate in
> today's situation. The centralized deployment of SPF, driven by centralized
> email services, has only exacerbated the vulnerabilities inherent in this
> trust model. The cascading effects of a single vulnerable SPF record
> affecting thousands of domains highlight the fragility of our current email
> authentication chain.
>
> It's also worth noting that a similar centralization phenomenon also
> exists in the deployment of DKIM (e.g., shared DKIM keys), based on our
> previous research published in the USENIX Security 2022.
> https://www.usenix.org/conference/usenixsecurity22/presentation/wang-chuhan
>
> Based on the current status of SPF deployment, maybe it's time for us to
> shift the trust model and explore better approaches to address email
> authentication issues.
>
>
> Chuhan Wang
> Tsinghua University
>
>
> Sir, I was wondering if you could provide a short, concise proposal to
> mitigate this problem? Perhaps how you might introduce a student to a new
> concept.
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: The sad state of SPF: research just presented at NDSS

[Neil Anuskiewicz]

> On Mar 11, 2024, at 10:38 PM, Neil Anuskiewicz  wrote:
> 
> 
> The solution to that vulnerability is in part use a subdomain and, when 
> possible, narrow the scope of what you permit. Better yet, choose a vendor 
> that’s known for tight security. A quick Look at the the security headlines 
> will show you some vendor red flags. But the sad state of spf is a misleading 
> title at best, 
> 
>>> On Mar 4, 2024, at 8:37 PM, Chuhan Wang  wrote:
>>> 
>> 
>> Hi Everyone,
>> 
>> I am Chuhan Wang from Tsinghua University, the author of paper BreakSPF: How 
>> Shared Infrastructures Magnify SPF Vulnerabilities Across the Internet.
>> Thanks Barry for sharing our paper presented at NDSS regarding the 
>> vulnerabilities of SPF in this work group. I'm glad to see that our research 
>> on BreakSPF is being discussed in the IETF work group. It's encouraging to 
>> know that our work is contributing to important conversations about email 
>> security.
>> 
>> I am willing to discuss any questions or concerns that may arise from our 
>> paper. Please feel free to reach out to me, and I'll be more than happy to 
>> discuss our findings and insights with the group.
>> 
>> Chuhan Wang
>> Tsinghua University
>> 
>>> Could infrastructure, in theory, be divided into the most restrictive scope 
>>> possible with walls between?

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

Re: [dmarc-ietf] Problem with multiple policies, different alignment

[Murray S. Kucherawy]

On Tue, Mar 12, 2024 at 6:23 AM Tobias Herkula  wrote:

> The DMARC Record on the DKIM signing domain is not relevant for DMARC
> evaluation, so if the 5322.From header domain is “example.com” the
> “adkim:r” is relevant for evaluation regarding your example setup and would
> consider a DKIM signature domain of “sub1.example.com” as aligned. It’s
> the same behavior as vice versa. As if the 5322.From header domain is “
> sub1.example.com” the “adkim:s” would apply and a DKIM signature Domain
> of “example.com” should not be considered aligned.
>

Well, Section 4.8 in -30 reads:

== BEGIN ==
For Organizational Domain discovery, it may be necessary to perform
multiple DNS Tree Walks to determine if any two domains are in alignment.
This means that a DNS Tree Walk to discover an Organizational Domain might
start at any of the following locations:
-
* The domain found in the RFC5322.From header of the message being
evaluated.
- * The domain found in the RFC5321.MailFrom header if there is an SPF pass
result for the message being evaluated.
- * Any DKIM d= domain if there is a DKIM pass result for that domain for
the message being evaluated.=== END ===

So it's not clear that the "d=" domain isn't relevant.  Perhaps this list
should be ordered?

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

Re: [dmarc-ietf] Inconsistencies in DMARC Aggregate Report XML Schema

[Hector Santos]

> On Mar 11, 2024, at 10:33 PM, Neil Anuskiewicz 
>  wrote:
> 
> Wow, the stat on how many domain operators move to enforcing reject policy 
> sans aggregate reports shocked me. Trust the force, Luke.

It should not be a surprise the client/server protocol concept of “email 
reporting” was always and I still believe is considered a taboo as it can be a 
form of abuse when not negotiated, requested or solicited. It is an 100% 
optional feature to provide a reporting address.

With DMARC policy publishing, for exploratory reasons only, I have reports sent 
to an email to newsgroup forum where I can privately review and so far, it has 
not provided any benefit beyond what is expected.  I have advocated for a 
straight text report but I probably have to write a translator. The current 
format expects JSON/XML readers. 

 Our wcDMARC verification processor does not have built-in support for 
reporting. 


All the best,
Hector Santos


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

Re: [dmarc-ietf] Fwd: Break SPF response: DKIM Only

[Neil Anuskiewicz]

> On Mar 4, 2024, at 11:07 PM, Chuhan Wang  wrote:
> 
> 
> Hi Douglas,
> 
> Thank you for your insightful summary of our paper. I'd like to share some of 
> my opinions.
> 
> You mentioned clients lose control of their SPF integrity. It's one of the 
> key problems exactly. Clients host their email services on email providers. 
> They are required to include email providers' SPF records in their SPF 
> records. However, the centralization of SPF deployment magnifies SPF 
> vulnerabilities. Our results show that when the email provider is vulnerable, 
> a single vulnerable SPF record can influence more than 10,000 domains, which 
> actually violates the assumption of SPF that domains can be distinguished by 
> IP addresses.
> 
> The reliance on IP addresses for sender authentication, a model that might 
> have seemed reasonable 20 years ago, has now proven to be inadequate in 
> today's situation. The centralized deployment of SPF, driven by centralized 
> email services, has only exacerbated the vulnerabilities inherent in this 
> trust model. The cascading effects of a single vulnerable SPF record 
> affecting thousands of domains highlight the fragility of our current email 
> authentication chain.
> 
> It's also worth noting that a similar centralization phenomenon also exists 
> in the deployment of DKIM (e.g., shared DKIM keys), based on our previous 
> research published in the USENIX Security 2022. 
> https://www.usenix.org/conference/usenixsecurity22/presentation/wang-chuhan
> 
> Based on the current status of SPF deployment, maybe it's time for us to 
> shift the trust model and explore better approaches to address email 
> authentication issues.
> 
> Chuhan Wang
> Tsinghua University

Sir, I was wondering if you could provide a short, concise proposal to mitigate 
this problem? Perhaps how you might introduce a student to a new concept.___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Don't trivialize psd=n

[Neil Anuskiewicz]

Is there any reason to lead with don’t worry about the tag but there is one 
critical use case. I think a more declarative statement in favor of the tag for 
those who will be stressed and skimming. Sure they might add a psd where it’s 
not needed but that’s better than not know the important part: the exception. 
So the strong statement should be the lead and the exception, btw, only really 
need it when… comes next. That would lead to some extraneous tags but less 
likely missing when it counts, rare.

> On Mar 10, 2024, at 12:14 PM, Douglas Foster 
>  wrote:
> 
> 
> Both of these statements seem unnecessarily weak, bordering on apologetic.
> 
> 5.3.General Record Format
> PSD ("n")
> ."... There is no need to put psd=n in a DMARC record, except in the very 
> unusual case of a parent PSD publishing a DMARC record without the requisite 
> psd=y tag."
> 
> 11.8 Determination of the Organizational Domain For Relaxed Alignment
> "For cases where strict alignment is not appropriate, this issue can be 
> mitigated by periodically checking the DMARC records, if any, of PSDs above 
> the organization's domains in the DNS tree and (for legacy [RFC7489] checking 
> that appropriate PSL entries remain present). If a PSD domain publishes a 
> DMARC record without the appropriate psd=y tag, organizational domain owners 
> can add psd=n to their organizational domain's DMARC record so that the PSD 
> record will not be incorrectly evaluated to be the organizational domain."
> 
> I suggest that the second sentence of 5.3 should read:
> "While the tree walk is designed to be upward-compatible with existing 
> policies that do not provide a psd tag, use of psd=n is RECOMMENDED as it 
> reduces evaluator processing effort, reduces load on the DNS, and increases 
> confidence in the evaluation results.  Use of psd=n is REQUIRED if a parent 
> domain has a DMARC policy without a psd tag."
> 
> Given the number of private registries that have embraced DMARC for PSDs 
> prior to publication of DMARCbis, it is difficult to even justify the 
> assumption that an unflagged PSD will be "very unusual"  
> Similarly, 11.8 could more usefully read:
> "For cases where strict alignment is not appropriate, this issue can be fully 
> mitigated by publishing a psd=n tag on the organizational domain."
> 
> Why would anyone "periodically check" for a problem, when the risk can be 
> completely eliminated in advance by taking a simple preventative measure?
> 
> Doug Foster
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: The sad state of SPF: research just presented at NDSS

[Neil Anuskiewicz]

On Mar 12, 2024, at 9:05 AM, Dotzero  wrote:Neil, SPF essentially deals with hosts and IP address ranges. Your suggested solution does not address the main problem(s) raised in the research.One approach that potentially addresses the SPF problem of shared hosting would be for ESPs to use IPv6 address space for sending. Each customer can then be assigned unique IP addresses. An approach like this causes other potential operational problems, for example infrequent senders (think of a monthly newsletter sent at the beginning of each month). The issues presented by Chuhan Wang have actually been known and understood for quite sometime even if not well documented for a wider audience.I do agree that the title is misleading. Michael HammerI like the IPv6 idea in principle but would the MBP’s adjust as small businesses can’t operate optimally with a sender reputation that’s like the sound of one hand clapping.I think SPF isn’t the problem, it’s the overloading of includes, lax vendor security in many cases, often overloading the org domain with a few includes that are cringeworthy in their permissiveness. If there were incentives to solve this problem the ESPs would be on it. Unfortunately, security breaches tend to act as externalities not proving a direct incentive for ESP’s and others to make mitigating this issue a priority. That said, a smart sender can avoid spf problems with planning and situational awareness.I don’t blame the spf protocol I blame the pushing the envelope until threat actors started writing thank you notes.On Tue, Mar 12, 2024 at 1:38 AM Neil Anuskiewicz 40marmot-tech@dmarc.ietf.org> wrote:The solution to that vulnerability is in part use a subdomain and, when possible, narrow the scope of what you permit. Better yet, choose a vendor that’s known for tight security. A quick Look at the the security headlines will show you some vendor red flags. But the sad state of spf is a misleading title at best, On Mar 4, 2024, at 8:37 PM, Chuhan Wang  wrote:Hi Everyone,I am Chuhan Wang from Tsinghua University, the author of paper BreakSPF: How Shared Infrastructures Magnify SPF Vulnerabilities Across the Internet.Thanks Barry for sharing our paper presented at NDSS regarding the vulnerabilities of SPF in this work group. I'm glad to see that our research on BreakSPF is being discussed in the IETF work group. It's encouraging to know that our work is contributing to important conversations about email security.I am willing to discuss any questions or concerns that may arise from our paper. Please feel free to reach out to me, and I'll be more than happy to discuss our findings and insights with the group.Chuhan WangTsinghua UniversityBegin forwarded message:From: Barry Leiba Subject: [dmarc-ietf] The sad state of SPF: research just presented at NDSSDate: February 28, 2024 at 17:33:41 CSTTo: IETF DMARC WG A paper was presented this morning at NDSS about the state of SPF, which is worth a read by this group:https://www.ndss-symposium.org/ndss-paper/breakspf-how-shared-infrastructures-magnify-spf-vulnerabilities-across-the-internet/B___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: The sad state of SPF: research just presented at NDSS

[Richard Clayton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In message , Scott
Kitterman  writes

>Or, as RFC 4408 and RFC 7208 warn against, ESPs don't allow customers to send 
>mail for anything other than their own domains.  ESP customers, don't use ESPs 
>that do this.

leaving aside how practical this advice may be and how it would be
possible for anyone to accurately, a priori, determine the ESPs
abilities to control their sending arrangements ...

... there's also "clouds" -- where senders are documenting the entirety
of the cloud's IP space as being a potential sending location. Although
it might be possible to have DNS records track actual usage as resources
are spun up and down there's obvious issues around caching.

of course we might say not to use clouds that do that ... but the "that
do that" part of the sentence would be superfluous

- -- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1

iQA/AwUBZfCS692nQQHFxEViEQJ3qwCfTxLBZW+aOgmaGtTBdMsaspMinakAniaz
2BW+OEMvrpnjG1aBhwEDSzgu
=xi5C
-END PGP SIGNATURE-

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

Re: [dmarc-ietf] Fwd: The sad state of SPF: research just presented at NDSS

[Scott Kitterman]

Or, as RFC 4408 and RFC 7208 warn against, ESPs don't allow customers to send 
mail for anything other than their own domains.  ESP customers, don't use ESPs 
that do this.

Scott K

On March 12, 2024 4:05:15 PM UTC, Dotzero  wrote:
>Neil, SPF essentially deals with hosts and IP address ranges. Your
>suggested solution does not address the main problem(s) raised in the
>research.
>
>One approach that potentially addresses the SPF problem of shared hosting
>would be for ESPs to use IPv6 address space for sending. Each customer can
>then be assigned unique IP addresses. An approach like this causes other
>potential operational problems, for example infrequent senders (think of a
>monthly newsletter sent at the beginning of each month). The issues
>presented by Chuhan Wang have actually been known and understood for quite
>sometime even if not well documented for a wider audience.
>
>I do agree that the title is misleading.
>
>Michael Hammer
>
>On Tue, Mar 12, 2024 at 1:38 AM Neil Anuskiewicz 40marmot-tech@dmarc.ietf.org> wrote:
>
>> The solution to that vulnerability is in part use a subdomain and, when
>> possible, narrow the scope of what you permit. Better yet, choose a vendor
>> that’s known for tight security. A quick Look at the the security headlines
>> will show you some vendor red flags. But the sad state of spf is a
>> misleading title at best,
>>
>> On Mar 4, 2024, at 8:37 PM, Chuhan Wang 
>> wrote:
>>
>> 
>>
>> Hi Everyone,
>> I am Chuhan Wang from Tsinghua University, the author of paper *BreakSPF:
>> How Shared Infrastructures Magnify SPF Vulnerabilities Across the Internet.*
>>
>> Thanks Barry for sharing our paper presented at NDSS regarding the
>> vulnerabilities of SPF in this work group. I'm glad to see that our
>> research on BreakSPF is being discussed in the IETF work group. It's
>> encouraging to know that our work is contributing to important
>> conversations about email security.
>>
>> I am willing to discuss any questions or concerns that may arise from our
>> paper. Please feel free to reach out to me, and I'll be more than happy to
>> discuss our findings and insights with the group.
>> Chuhan Wang
>> Tsinghua University
>>
>> Begin forwarded message:
>>
>> *From: *Barry Leiba 
>> *Subject: **[dmarc-ietf] The sad state of SPF: research just presented at
>> NDSS*
>> *Date: *February 28, 2024 at 17:33:41 CST
>> *To: *IETF DMARC WG 
>>
>> A paper was presented this morning at NDSS about the state of SPF, which
>> is worth a read by this group:
>>
>>
>> https://www.ndss-symposium.org/ndss-paper/breakspf-how-shared-infrastructures-magnify-spf-vulnerabilities-across-the-internet/
>>
>> Barry
>> ___
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
>>
>> ___
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
>> ___
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>

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

Re: [dmarc-ietf] Fwd: The sad state of SPF: research just presented at NDSS

[Dotzero]

Neil, SPF essentially deals with hosts and IP address ranges. Your
suggested solution does not address the main problem(s) raised in the
research.

One approach that potentially addresses the SPF problem of shared hosting
would be for ESPs to use IPv6 address space for sending. Each customer can
then be assigned unique IP addresses. An approach like this causes other
potential operational problems, for example infrequent senders (think of a
monthly newsletter sent at the beginning of each month). The issues
presented by Chuhan Wang have actually been known and understood for quite
sometime even if not well documented for a wider audience.

I do agree that the title is misleading.

Michael Hammer

On Tue, Mar 12, 2024 at 1:38 AM Neil Anuskiewicz  wrote:

> The solution to that vulnerability is in part use a subdomain and, when
> possible, narrow the scope of what you permit. Better yet, choose a vendor
> that’s known for tight security. A quick Look at the the security headlines
> will show you some vendor red flags. But the sad state of spf is a
> misleading title at best,
>
> On Mar 4, 2024, at 8:37 PM, Chuhan Wang 
> wrote:
>
> 
>
> Hi Everyone,
> I am Chuhan Wang from Tsinghua University, the author of paper *BreakSPF:
> How Shared Infrastructures Magnify SPF Vulnerabilities Across the Internet.*
>
> Thanks Barry for sharing our paper presented at NDSS regarding the
> vulnerabilities of SPF in this work group. I'm glad to see that our
> research on BreakSPF is being discussed in the IETF work group. It's
> encouraging to know that our work is contributing to important
> conversations about email security.
>
> I am willing to discuss any questions or concerns that may arise from our
> paper. Please feel free to reach out to me, and I'll be more than happy to
> discuss our findings and insights with the group.
> Chuhan Wang
> Tsinghua University
>
> Begin forwarded message:
>
> *From: *Barry Leiba 
> *Subject: **[dmarc-ietf] The sad state of SPF: research just presented at
> NDSS*
> *Date: *February 28, 2024 at 17:33:41 CST
> *To: *IETF DMARC WG 
>
> A paper was presented this morning at NDSS about the state of SPF, which
> is worth a read by this group:
>
>
> https://www.ndss-symposium.org/ndss-paper/breakspf-how-shared-infrastructures-magnify-spf-vulnerabilities-across-the-internet/
>
> Barry
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Problem with multiple policies, different alignment

[Tobias Herkula]

The DMARC Record on the DKIM signing domain is not relevant for DMARC 
evaluation, so if the 5322.From header domain is “example.com” the “adkim:r” is 
relevant for evaluation regarding your example setup and would consider a DKIM 
signature domain of “sub1.example.com” as aligned. It’s the same behavior as 
vice versa. As if the 5322.From header domain is “sub1.example.com” the 
“adkim:s” would apply and a DKIM signature Domain of “example.com” should not 
be considered aligned.

/ Tobias Herkula

From: dmarc  On Behalf Of Douglas Foster
Sent: Tuesday, March 12, 2024 12:15 PM
To: IETF DMARC WG 
Subject: [dmarc-ietf] Problem with multiple policies, different alignment

I have been building a DMARC implementation, starting with a simple function:
TreeWalk(domain) which returns:

  *   Policy found or not found indicator
  *   Policy Domain
  *   Organizational Domain
  *   Policy record
My thought was that the Tree Walk result was independent of the domain 
identifier being checked, but this is not true.

Assume these DMARC policies:

  *   example.com aspf:r adkim:r
  *   sub1.example.com aspf:s akim:s

When the message contains:

  *   From: u...@sub1.example.com
  *   DKIM: d=example.com
Strict alignment on the From domain makes the organizational domain 
unimportant, so the PSL lookup or Tree Walk are not necessary.   The 
organizational domain used for reporting purposes is 
sub1.example.com.The DKIM signature is not aligned.

But when the message contains the reverse, the logic gets complicated:

  *   From: u...@example.com
  *   DKIM: d=sub1.example.com
If we apply the same Tree Walk to this message, we have a problem.   The From 
domain Tree Walk returns "example.com" as the 
organizational domain, and the Tree Walk of the DKIM domain returns 
"sub1.example.com" as the organizational domain 
because of strict alignment.   So the result appears to be unaligned.

Consequently, the Tree Walk needs to be sensitive to the identifier being 
checked. If the identifier is not the From address, the Tree Walk is only 
interested in the existence of a policy and the PSL tags, and the special case 
related to strict alignment needs to be bypassed.

I don't think this case was covered in previous discussions.

Doug Foster

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

[dmarc-ietf] Problem with multiple policies, different alignment

[Douglas Foster]

I have been building a DMARC implementation, starting with a simple
function:
TreeWalk(domain) which returns:

   - Policy found or not found indicator
   - Policy Domain
   - Organizational Domain
   - Policy record

My thought was that the Tree Walk result was independent of the domain
identifier being checked, but this is not true.

Assume these DMARC policies:

   - example.com aspf:r adkim:r
   - sub1.example.com aspf:s akim:s


When the message contains:

   - From: u...@sub1.example.com
   - DKIM: d=example.com

Strict alignment on the From domain makes the organizational domain
unimportant, so the PSL lookup or Tree Walk are not necessary.   The
organizational domain used for reporting purposes is sub1.example.com.
The DKIM signature is not aligned.

But when the message contains the reverse, the logic gets complicated:

   - From: u...@example.com
   - DKIM: d=sub1.example.com

If we apply the same Tree Walk to this message, we have a problem.   The
>From domain Tree Walk returns "example.com" as the organizational domain,
and the Tree Walk of the DKIM domain returns "sub1.example.com" as the
organizational domain because of strict alignment.   So the result appears
to be unaligned.

Consequently, the Tree Walk needs to be sensitive to the identifier being
checked. If the identifier is not the From address, the Tree Walk is
only interested in the existence of a policy and the PSL tags, and the
special case related to strict alignment needs to be bypassed.

I don't think this case was covered in previous discussions.

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

Re: [dmarc-ietf] A.5 Issues with ADSP in Operation

[Alessandro Vesely]

On 12/03/2024 03:18, Neil Anuskiewicz wrote:

Please remove the pct tag from the spec.


It has been removed already, which is incompatible with current records.


Best
Ale
--





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