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

[Chuhan Wang]

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

> Begin forwarded message:
> 
> From: Douglas Foster 
> Subject: Re: [dmarc-ietf] Break SPF response: DKIM Only
> Date: February 29, 2024 at 18:13:53 CST
> To: IETF DMARC WG 
> 
> SPF trust was promised on the theory that shared infrastructure would prevent 
> clients from impersonating each other.   This document blows up that 
> assumption.  
> 
> It points out that clients have lost control of their SPF integrity.   
> Neither those clients nor their message recipients have enough data to know 
> what parts of an SPF policy are unneeded. 
> 
> Then it points out that there are attack vectors beyond the imagination of 
> ordinary mortals.   This document is a death knell for unsigned email, and we 
> need to lead the effort by providing a way for senders to clearly document 
> that all of their messages are signed.
> 
> Thee are many domains that sign all messages, but there is no way for 
> evaluators to reliably identify them 
> 
> This is not the time for Darwinism ("foolish people get what they deserve").  
>  The infrastructure companies create the problem, clients choose the vendor, 
> but unrelated recipients suffer the consequences.   The wrong people take the 
> hit.We need to provide a way to mitigate the harm caused by unjustified 
> trust in SPF.
> 
> Doug
> 
> On Thu, Feb 29, 2024, 1:29 PM Scott Kitterman  > wrote:
> 
> 
> On February 29, 2024 6:15:37 PM UTC, Benny Pedersen  > wrote:
> >Douglas Foster skrev den 2024-02-29 18:48:
> >> I am surprised at the lack of feedback about Barry's research link.
> >> It is a devastating attack on our ability to trust SPF when shared
> >> infrastructure is involved.   As a result of that document, I have
> >> switched camps and believe that we MUST provide a DKIM-only option for
> >> DMARC.
> >> 
> >> The proposed workaround, of using a "?" modifier to force SPF Neutral
> >> instead of Pass, seems to lack both awareness and implementation,
> >> since it was not even mentioned in the research document as a
> >> mitigation.
> >
> >spf specs have desided to allow +all and unlimited numbers of ips, there is 
> >no way to stop it unless rfc changes it
> >
> >even "v=spf1 ip4:0.0.0.0/0  -all" is fully valid
> >
> >for maillist is never being dmarc aligned anyway, but direct could be 
> >aligned, if not a forwarding host does something, with or without srs
> >
> >maybe rfc wise it could help to have a max ips to get spf pass ?
> >
> There's no point.  As has been discussed for probably 20 years, as soon as 
> you special case any of these kinds of records, people will move to slightly 
> more obscure ways to get the same results.
> 
> >From a protocol perspective there's no surprise here.  The security 
> >considerations of RFC 4408 explicitly warned about shared infrastructure 
> >risks.  The challenge is that no one cared.  There's no doubt a business 
> >opportunity here, but I expect no one will pursue it since it doesn't 
> >require AI.
> 
> Scott K
> 
> ___
> 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-ietf] Fwd: The sad state of SPF: research just presented at NDSS

[Chuhan Wang]

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

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

[Hector Santos]

> On Feb 28, 2024, at 6:33 PM, Barry Leiba  wrote:
> 
> 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, Interesting.  Appreciate the security note.

Per document, 2.39% domains are the problem with CDN, HTTP Proxy, SMTP threat 
entry points.  Not an SPF issue.   If anything, add more SMTP command override 
support for immediate disconnect for GET, POST, etc, erroneous SMTP commands:

// Script:  Smtpfilter-GET.wcc:

// add code to block GetCalllerID()
Print “550 ”
HangUp()
End

// Script:  Smtpfilter-POST.wcc:

// add code to block GetCalllerID()
Print “550 ”
HangUp()
End


All the best,
Hector Santos

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

Re: [dmarc-ietf] DMARCbis WGLC Significant(ish) Issue - Section 7.6

[Hector Santos]

No rehashing, my technical opinion, clearly the semantics but both lead to:

“You SHOULD|MUST consider the documented conflicts before using the restricted 
policy p=reject”

Question. Is p=quarantine ok to use?  Or do we presume p=reject implies 
p=quarantine?’'



All the best,
Hector Santos



> On Feb 29, 2024, at 2:53 PM, Seth Blank  
> wrote:
> 
> I thought we landed on SHOULD NOT, there was strong resistance to MUST NOT
> 
> On Thu, Feb 29, 2024 at 2:48 PM Scott Kitterman  > wrote:
>> Okay.  I think 8.6 is the one in error.  You see how this is going to go, 
>> right?
>> 
>> Scott K
>> 
>> On February 29, 2024 7:45:15 PM UTC, Todd Herr 
>> > > wrote:
>> >It is not my intent here to relitigate any issues.
>> >
>> >Rather, I believe that the text in 7.6 is wrong, likely due to an oversight
>> >on my part when the new text in 8.6 was published, and I just want to
>> >confirm that 7.6 is indeed wrong.
>> >
>> >On Thu, Feb 29, 2024 at 2:10 PM Scott Kitterman > >>
>> >wrote:
>> >
>> >> In what way is this a new issue that has not already been argued to death
>> >> in the WG?  I think for WGLC, we've already done this. We will, no doubt
>> >> get to have this conversation during the IETF last call, but for the
>> >> working group, this strikes me as exactly the type of relitigation of
>> >> issues we've been counseled to avoid.
>> >>
>> >> Scott K
>> >>
>> >> On February 29, 2024 6:54:57 PM UTC, Todd Herr > >> 40valimail@dmarc.ietf.org > 
>> >> wrote:
>> >> >Colleagues,
>> >> >
>> >> >I've been reading DMARCbic rev -30 today with a plan to collect the first
>> >> >set of minor edits and I came across a sentence that I believe goes 
>> >> >beyond
>> >> >minor, so wanted to get a sanity check.
>> >> >
>> >> >Section 7.6, Domain Owner Actions, ends with the following sentence:
>> >> >
>> >> >In particular, this document makes explicit that domains for
>> >> >general-purpose email MUST NOT deploy a DMARC policy of p=reject.
>> >> >
>> >> >
>> >> >I don't believe this to be true, however. Rather, Section 8.6,
>> >> >Interoperability Considerations, says SHOULD NOT on the topic (e.g., "It
>> >> is
>> >> >therefore critical that domains that host users who might post messages 
>> >> >to
>> >> >mailing lists SHOULD NOT publish p=reject")
>> >> >
>> >> >Section 7.6 therefore should be updated to read "domains for
>> >> >general-purpose email SHOULD NOT deploy a DMARC policy of p=reject", yes?
>> >> >
>> >>
>> >> ___
>> >> 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
> 
> 
> --
> Seth Blank  | Chief Technology Officer
> e: s...@valimail.com 
> p:
> 
> 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

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

[dmarc-ietf] A possible point for SPF advice

[Alessandro Vesely]

Hi,

Section 5 has a paragraph that can fit Scott's solution to SPF spoofing.   
Here's a possible change:


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").

Best
Ale
--

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

Re: [dmarc-ietf] DISCARD: 4.3. Authentication Mechanisms

[Alessandro Vesely]

Sorry, I've been fooled by the page break.


Alessandro Vesely writes:


Hi,

it is not true that DMARC relies solely on SPF authentication.

OLD
   *  SPF, [RFC7208], which can authenticate both the domain found in an
  SMTP [RFC5321] HELO/EHLO command (the HELO identity) and the
  domain found in an SMTP MAIL command (the MAIL FROM identity).  As
  noted earlier, however, DMARC relies solely on SPF authentication

NEW
   *  SPF, [RFC7208], which can authenticate both the domain found in an
  SMTP [RFC5321] HELO/EHLO command (the HELO identity) and the
  domain found in an SMTP MAIL command (the MAIL FROM identity).  As
  noted earlier, however, DMARC uses only the MAIL FROM identity

Best
Ale
--

___
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-ietf] 4.3. Authentication Mechanisms

[Alessandro Vesely]

Hi,

it is not true that DMARC relies solely on SPF authentication.

OLD
   *  SPF, [RFC7208], which can authenticate both the domain found in an
  SMTP [RFC5321] HELO/EHLO command (the HELO identity) and the
  domain found in an SMTP MAIL command (the MAIL FROM identity).  As
  noted earlier, however, DMARC relies solely on SPF authentication

NEW
   *  SPF, [RFC7208], which can authenticate both the domain found in an
  SMTP [RFC5321] HELO/EHLO command (the HELO identity) and the
  domain found in an SMTP MAIL command (the MAIL FROM identity).  As
  noted earlier, however, DMARC uses only the MAIL FROM identity

Best
Ale
--

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