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: 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] 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] Fwd: The sad state of SPF: research just presented at NDSS

[Neil Anuskiewicz]

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/Barry
___dmarc mailing listdmarc@ietf.orghttps://www.ietf.org/mailman/listinfo/dmarc___dmarc mailing listdmarc@ietf.orghttps://www.ietf.org/mailman/listinfo/dmarc___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc