Re: [dmarc-ietf] Protocols All The Way Down (long - sorry)

[Jesse Thompson]

On Tue, Jul 11, 2023, at 7:49 PM, Wei Chuang wrote:
> Also can we do more to harden SPF?  The SPF upgrade attacks needs three 
> things:
>  • IPs shared by multiple sending domains
>  • Some sender uses those IPs that permits spam and phish traffic
>  • Those multiple sending domains have SPF policies that include those IPs

To the last item. We (as an ESP) only send with relaxed SPF alignment. Therefor 
our SPF include should [ideally] not be on the RFC5322.From domain (granted, I 
am working on revising some docs that still rely on PRA assumptions).

> Perhaps one way to harden to SPF for DMARC is to detect if the IPs are 
> shared.  The authenticator in addition to regular to SPF validation, might be 
> able to use reverse PTR lookup and match the SPF record domain name (or match 
> some subset like the org domain) to forward validate.  Only one domain can 
> claim ownership for the IPs and be allowed to SPF authenticate for DMARC.  

I think that with relaxed alignment it requires that a potential spoofer 
(through our service) to be able to produce an SPF aligned result that is a 
subdomain of the RFC5322.From domain (which I don't think is happening with the 
SPF upgrade attacks today, at least for us) and the spoofer would need to be 
able to know and use the same subdomain (which includes our SPF) that has a 
high reputation in your trust models. I do have concerns about penalizing 
shared IPs in general, since they are a necessity with IPv4.

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

Re: [dmarc-ietf] Protocols All The Way Down (long - sorry)

[Neil Anuskiewicz]

Michael,As someone who did work for an ESP, your bit about the conflict between short term cash flow that a short term customer with some money to spend for a few months and the optimizing for customer lifetime value. That war, or shall I say tension, was always there. I’d imagine the little ESP I worked for was not unusual. That tension must play out many places as the roles and wildly different incentives bake tension right into the cake.On Jul 12, 2023, at 6:33 AM, Dotzero  wrote:On Wed, Jul 12, 2023 at 6:47 AM Scott Kitterman  wrote:It's not news that there's a risk for SPF associated with shared IP addresses.  
That's why it's in RFC 7208 (11.4) and was in RFC 4408 similarly before.+1 

I understand your view and agree on the problem.  I also sympathize with the 
need to technically address conditions as they exist in operations.  I'm not 
convinced that we should bake the solutions into protocol, however.

As I've said before, I think this is primarily and economics/incentives 
problem, not a technical problem.  If you increase the incentives for third 
party providers to support DKIM in place of SPF, I don't think you've actually 
solved anything.The reality is that many ESPs have asked "how does DMARC fit into my business model?". My response has always been that it is not up to the community to figure out your business model. 

As fas as I've seen, the low cost (for a third party to sign using their 
customer's domain name) approach is for the third party provider to publish 
DKIM key records based on their own private keys and then tell their customer 
to put a CNAME in their DNS that points to it.  In the case of a shared 
server, the third party provider then needs to keep track of which customer is 
authorized to sign for which d= domain, but they can use their own keys/
infrastructure for doing so. That is one approach. We used to delegate subdomains and contractually require key rotation, etc. We did that after 2007 (due to Storm Worm), well before DMARC was published. There were ESPs that balked at signing with our keys and they were not considered as potential vendors. There were others that worked with us and also provided dedicated IPs that were shared among our various brands (for SPF). Many folks lag behind because they perceive the "cost" of security as higher than the cost(s) associated with the consequences of poor practices.A slightly more complicated approach would be for the domain to provide private signing keys to the 3rd party. 

The internal management function of keeping track of which customers can use 
which signing domains is essentially the same as the internal management 
function of keeping track of which customers can use which Mail From addresses 
with SPF.

My speculation (and it is that), is that the most cost sensitive third party 
providers currently use SPF only and are less likely to keep effective control 
of which customer can send from which identity precisely because it's less 
expensive.  If you change the deployment incentives so that DKIM is now more 
necessary for some of their customers, they'll no doubt deploy it, but without 
better internal controls, you'll end up with the same problems with these 
providers expressed through a different technology.In some ways, receivers/mailbox providers enable the bad practices by accepting problematic email because that requires less work in dealing with the ISP Relations people from those mailers. As a sidenote, one need only look at the ratio of deliverability people to compliance people at some of these organizations to understand priorities. A harder line would force those mailers to reevaluate their practices and offerings. This is an operations/implementation problem and not so much a protocol/standards problem. Just saying.Michael Hammer
___dmarc mailing listdmarc@ietf.orghttps://www.ietf.org/mailman/listinfo/dmarc___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Protocols All The Way Down (long - sorry)

[Neil Anuskiewicz]

> On Jul 12, 2023, at 3:47 AM, Scott Kitterman  wrote:
> 
> It's not news that there's a risk for SPF associated with shared IP 
> addresses.  
> That's why it's in RFC 7208 (11.4) and was in RFC 4408 similarly before.
> 
> I understand your view and agree on the problem.  I also sympathize with the 
> need to technically address conditions as they exist in operations.  I'm not 
> convinced that we should bake the solutions into protocol, however.
> 
> As I've said before, I think this is primarily and economics/incentives 
> problem, not a technical problem.  If you increase the incentives for third 
> party providers to support DKIM in place of SPF, I don't think you've 
> actually 
> solved anything.

Perhaps not but sans any additional incentives the big ESPs, especially in the 
SME niche, are already doing the CNAME efficient system and that efficiency 
creates its own incentives. SPF is hard to scale especially in the SME focused 
ESP with a massive customer base. From the ESP point of view it’s a win, I 
think, so this trend will likely continue.

Perhaps the value neutral discussion of SPF OR DKIM logic could be less 
dispassionate, remembering that the IETF WG has the technical soft leadership. 
We can see where things are going and think accordingly. I think that standards 
are your ostensible mission but really you also need to be a top shelf sales 
organization.

Maybe in some ways DKIM and SPF need to be put in different cribs so the 
emphcise isn’t on the OR. Perhaps it’s on the relative value of SPF and dkim 
even though in theory they could get you to the goal the same. It’s ok to 
decide dkim is sold and spf is a real nice to have add on like a real nice 
stereo. No need to be heavy handed if you sell effectively.  
> 
> As fas as I've seen, the low cost (for a third party to sign using their 
> customer's domain name) approach is for the third party provider to publish 
> DKIM key records based on their own private keys and then tell their customer 
> to put a CNAME in their DNS that points to it.  In the case of a shared 
> server, the third party provider then needs to keep track of which customer is
> authorized to sign for which d= domain, but they can use their own keys/
> infrastructure for doing so.
> 
> The internal management function of keeping track of which customers can use 
> which signing domains is essentially the same as the internal management 
> function of keeping track of which customers can use which Mail From 
> addresses 
> with SPF.
> 
> My speculation (and it is that), is that the most cost sensitive third party 
> providers currently use SPF only and are less likely to keep effective 
> control 
> of which customer can send from which identity precisely because it's less 
> expensive.  If you change the deployment incentives so that DKIM is now more 
> necessary for some of their customers, they'll no doubt deploy it, but without
> better internal controls, you'll end up with the same problems with these 
> providers expressed through a different technology.
> 
> Scott K
> 
>> On Tuesday, July 11, 2023 8:49:28 PM EDT Wei Chuang wrote:
>> The data we presented June 20th (archive
>> )
>> also suggests that it is premature to drop SPF from DMARC.  However I
>> differ in believing that we should accept the spoofing risk demonstrated
>> recently via SPF, and that we shouldn't strive to reduce it by making
>> improvements to DMARC and possibly SPF.  One approach is to enable
>> different senders to distinguish their differing levels of risk and
>> infrastructure by letting them specify an "auth=" flag proposed on the 20th
>> .
>> For example a mom-and-pop sender on their own infrastructure with their own
>> IPs will have a different profile than a risky, enterprise sender on shared
>> IPs.  The former would be reasonably safe using SPF and would benefit most
>> from using it.  The latter should use DKIM authentication only due to the
>> risk of SPF upgrade spoofing and the phishing exposure.  I describe some
>> additional ideas about how to use "auth=" flag with different risk and
>> infrastructure stratification on the DKIM list on July 3rd (archive
>> > /> ).
>> 
>> And FWIW I don't think mom-and-pop senders will find it that hard to adopt
>> DKIM if sufficiently motivated.  For example for BIMI on Gmail, we now
>> require DKIM-only authentication.  Indeed a new BIMI sender that I perceive
>> to be running literally a "mom-and-pop" produce shop was using SPF
>> authentication and was confused as to why their logo wasn't showing.  After
>> explaining the requirement they were able to move to DKIM authentication in
>> one day.  Yes, it did take explaining twice what was happening, but they
>> were able to deploy DKIM on their own and got their

Re: [dmarc-ietf] Protocols All The Way Down (long - sorry)

[Dotzero]

On Wed, Jul 12, 2023 at 6:47 AM Scott Kitterman 
wrote:

> It's not news that there's a risk for SPF associated with shared IP
> addresses.
> That's why it's in RFC 7208 (11.4) and was in RFC 4408 similarly before.
>

+1


>
> I understand your view and agree on the problem.  I also sympathize with
> the
> need to technically address conditions as they exist in operations.  I'm
> not
> convinced that we should bake the solutions into protocol, however.
>
> As I've said before, I think this is primarily and economics/incentives
> problem, not a technical problem.  If you increase the incentives for
> third
> party providers to support DKIM in place of SPF, I don't think you've
> actually
> solved anything.
>

The reality is that many ESPs have asked "how does DMARC fit into my
business model?". My response has always been that it is not up to the
community to figure out your business model.


> As fas as I've seen, the low cost (for a third party to sign using their
> customer's domain name) approach is for the third party provider to
> publish
> DKIM key records based on their own private keys and then tell their
> customer
> to put a CNAME in their DNS that points to it.  In the case of a shared
> server, the third party provider then needs to keep track of which
> customer is
> authorized to sign for which d= domain, but they can use their own keys/
> infrastructure for doing so.
>

That is one approach. We used to delegate subdomains and contractually
require key rotation, etc. We did that after 2007 (due to Storm Worm), well
before DMARC was published. There were ESPs that balked at signing with our
keys and they were not considered as potential vendors. There were others
that worked with us and also provided dedicated IPs that were shared among
our various brands (for SPF). Many folks lag behind because they perceive
the "cost" of security as higher than the cost(s) associated with the
consequences of poor practices.

A slightly more complicated approach would be for the domain to provide
private signing keys to the 3rd party.


>
> The internal management function of keeping track of which customers can
> use
> which signing domains is essentially the same as the internal management
> function of keeping track of which customers can use which Mail From
> addresses
> with SPF.
>
> My speculation (and it is that), is that the most cost sensitive third
> party
> providers currently use SPF only and are less likely to keep effective
> control
> of which customer can send from which identity precisely because it's less
> expensive.  If you change the deployment incentives so that DKIM is now
> more
> necessary for some of their customers, they'll no doubt deploy it, but
> without
> better internal controls, you'll end up with the same problems with these
> providers expressed through a different technology.
>

In some ways, receivers/mailbox providers enable the bad practices by
accepting problematic email because that requires less work in dealing with
the ISP Relations people from those mailers. As a sidenote, one need only
look at the ratio of deliverability people to compliance people at some of
these organizations to understand priorities. A harder line would force
those mailers to reevaluate their practices and offerings. This is an
operations/implementation problem and not so much a protocol/standards
problem. Just saying.

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

Re: [dmarc-ietf] Protocols All The Way Down (long - sorry)

[Scott Kitterman]

It's not news that there's a risk for SPF associated with shared IP addresses.  
That's why it's in RFC 7208 (11.4) and was in RFC 4408 similarly before.

I understand your view and agree on the problem.  I also sympathize with the 
need to technically address conditions as they exist in operations.  I'm not 
convinced that we should bake the solutions into protocol, however.

As I've said before, I think this is primarily and economics/incentives 
problem, not a technical problem.  If you increase the incentives for third 
party providers to support DKIM in place of SPF, I don't think you've actually 
solved anything.

As fas as I've seen, the low cost (for a third party to sign using their 
customer's domain name) approach is for the third party provider to publish 
DKIM key records based on their own private keys and then tell their customer 
to put a CNAME in their DNS that points to it.  In the case of a shared 
server, the third party provider then needs to keep track of which customer is 
authorized to sign for which d= domain, but they can use their own keys/
infrastructure for doing so.

The internal management function of keeping track of which customers can use 
which signing domains is essentially the same as the internal management 
function of keeping track of which customers can use which Mail From addresses 
with SPF.

My speculation (and it is that), is that the most cost sensitive third party 
providers currently use SPF only and are less likely to keep effective control 
of which customer can send from which identity precisely because it's less 
expensive.  If you change the deployment incentives so that DKIM is now more 
necessary for some of their customers, they'll no doubt deploy it, but without 
better internal controls, you'll end up with the same problems with these 
providers expressed through a different technology.

Scott K

On Tuesday, July 11, 2023 8:49:28 PM EDT Wei Chuang wrote:
> The data we presented June 20th (archive
> )
> also suggests that it is premature to drop SPF from DMARC.  However I
> differ in believing that we should accept the spoofing risk demonstrated
> recently via SPF, and that we shouldn't strive to reduce it by making
> improvements to DMARC and possibly SPF.  One approach is to enable
> different senders to distinguish their differing levels of risk and
> infrastructure by letting them specify an "auth=" flag proposed on the 20th
> .
> For example a mom-and-pop sender on their own infrastructure with their own
> IPs will have a different profile than a risky, enterprise sender on shared
> IPs.  The former would be reasonably safe using SPF and would benefit most
> from using it.  The latter should use DKIM authentication only due to the
> risk of SPF upgrade spoofing and the phishing exposure.  I describe some
> additional ideas about how to use "auth=" flag with different risk and
> infrastructure stratification on the DKIM list on July 3rd (archive
>  /> ).
> 
> And FWIW I don't think mom-and-pop senders will find it that hard to adopt
> DKIM if sufficiently motivated.  For example for BIMI on Gmail, we now
> require DKIM-only authentication.  Indeed a new BIMI sender that I perceive
> to be running literally a "mom-and-pop" produce shop was using SPF
> authentication and was confused as to why their logo wasn't showing.  After
> explaining the requirement they were able to move to DKIM authentication in
> one day.  Yes, it did take explaining twice what was happening, but they
> were able to deploy DKIM on their own and got their logo to show up.
> 
> Also can we do more to harden SPF?  The SPF upgrade attacks needs three
> things:
> 
>- IPs shared by multiple sending domains
>- Some sender uses those IPs that permits spam and phish traffic
>- Those multiple sending domains have SPF policies that include those IPs
> 
> Perhaps one way to harden to SPF for DMARC is to detect if the IPs are
> shared.  The authenticator in addition to regular to SPF validation, might
> be able to use reverse PTR lookup and match the SPF record domain name (or
> match some subset like the org domain) to forward validate.  Only one
> domain can claim ownership for the IPs and be allowed to SPF authenticate
> for DMARC.
> 
> -Wei
> 
> On Mon, Jul 10, 2023 at 5:38 PM Scott Kitterman 
> 
> wrote:
> > I've been thinking about the thread on ditching SPF relative to DMARC.
> > 
> > DMARC is built on other protocols.  Piles of them.
> > 
> > DMARC is built most directly on DNS, DKIM, and SPF.  It is also built on
> > SMTP
> > and Email.  DKIM and SPF are also built on DNS and SMTP (SPF) or Email
> > (DKIM).
> > These protocols are built on others.  All of them have flaws and
> > limitations.
> > 
> > As an example, although each of the three t

Re: [dmarc-ietf] Protocols All The Way Down (long - sorry)

[Jan Dušátko]

Hi,
each mechanism approaches the problem in a different way:
- SPF authorizes selected hosts (machines approved to send mail)
- DKIM authenticates sender (proof of origin)
- ARC authenticate senders chain (also proof of origin, but also proof 
of whole communication chain)


we can also continue with other technologies, but this is not matter the 
DMARC story. For example S/MIME and GPG are from my perspective proof of 
will.


In a previous communication, I listed SPF as an obsolete technology. 
Also, this is matter of my perspective, due to problems in cloud systems 
where thousands of domains are on similar machines/address ranges. For 
this reason, SPF is currently limited in use, yet it still has its uses.


In a previous communication, I also reported on measurement statistics 
about saturation of specific technologies. These statistics are 
collected over domains. I will try to figure out the number of that 
domains, we did that analysis about one year ago. Total volume are about 
50 million e-mails per week. The problem with collecting this data is 
distribution across different mail systems on about 7000-8000 domains 
and another thousands of subdomains (oscillating in time).


From my point of view, the biggest problem at the moment is the 
protection of the sender's brand, i.e. the ability to unambiguously 
identify from which source the email originated and whether it was 
counterfeit (has been e-mail forged or not?). Current technologies such 
as SPF, DKIM and ARC, DMARC try to ensure this protection, but the owner 
is limited in deciding how he can allow his authentication. Since he is 
dependent on the correct implementation of these technologies by the 
recipient, he should be able to define his requirements. He cannot 
enforce them, but any problems due to the poor authentication of the 
sender then go to the recipient.


Regards

Jan

Dne 12. 7. 2023 v 3:18 Douglas Foster napsal(a):

So we disable SPF when the sender tells us to do so., but leave it enabled
by defaultThat makes a lot of sense to me.

When the domain passes SPF on a shared server farm, but provides no DKIM
signatures, I currently have no choice other than to consider the message
to be authenticated.  The AUTH token will provide that reason.

Hosting services could insist that senders configure DKIM, but that seems
to be a pipe dream.

Doug

On Tue, Jul 11, 2023, 8:50 PM Wei Chuang 
wrote:


The data we presented June 20th (archive
)
also suggests that it is premature to drop SPF from DMARC.  However I
differ in believing that we should accept the spoofing risk demonstrated
recently via SPF, and that we shouldn't strive to reduce it by making
improvements to DMARC and possibly SPF.  One approach is to enable
different senders to distinguish their differing levels of risk and
infrastructure by letting them specify an "auth=" flag proposed on the
20th
.
For example a mom-and-pop sender on their own infrastructure with their own
IPs will have a different profile than a risky, enterprise sender on shared
IPs.  The former would be reasonably safe using SPF and would benefit most
from using it.  The latter should use DKIM authentication only due to the
risk of SPF upgrade spoofing and the phishing exposure.  I describe some
additional ideas about how to use "auth=" flag with different risk and
infrastructure stratification on the DKIM list on July 3rd (archive

).

And FWIW I don't think mom-and-pop senders will find it that hard to adopt
DKIM if sufficiently motivated.  For example for BIMI on Gmail, we now
require DKIM-only authentication.  Indeed a new BIMI sender that I perceive
to be running literally a "mom-and-pop" produce shop was using SPF
authentication and was confused as to why their logo wasn't showing.  After
explaining the requirement they were able to move to DKIM authentication in
one day.  Yes, it did take explaining twice what was happening, but they
were able to deploy DKIM on their own and got their logo to show up.

Also can we do more to harden SPF?  The SPF upgrade attacks needs three
things:

- IPs shared by multiple sending domains
- Some sender uses those IPs that permits spam and phish traffic
- Those multiple sending domains have SPF policies that include those
IPs

Perhaps one way to harden to SPF for DMARC is to detect if the IPs are
shared.  The authenticator in addition to regular to SPF validation, might
be able to use reverse PTR lookup and match the SPF record domain name (or
match some subset like the org domain) to forward validate.  Only one
domain can claim ownership for the IPs and be allowed to SPF authenticate
for DMARC.

-Wei

On Mon, Jul 10, 2023 at 5:38 PM Scott Kitterman 
wrote:


I've been thinking about the thread on ditching SPF relative

Re: [dmarc-ietf] Protocols All The Way Down (long - sorry)

[Douglas Foster]

So we disable SPF when the sender tells us to do so., but leave it enabled
by defaultThat makes a lot of sense to me.

When the domain passes SPF on a shared server farm, but provides no DKIM
signatures, I currently have no choice other than to consider the message
to be authenticated.  The AUTH token will provide that reason.

Hosting services could insist that senders configure DKIM, but that seems
to be a pipe dream.

Doug

On Tue, Jul 11, 2023, 8:50 PM Wei Chuang 
wrote:

> The data we presented June 20th (archive
> )
> also suggests that it is premature to drop SPF from DMARC.  However I
> differ in believing that we should accept the spoofing risk demonstrated
> recently via SPF, and that we shouldn't strive to reduce it by making
> improvements to DMARC and possibly SPF.  One approach is to enable
> different senders to distinguish their differing levels of risk and
> infrastructure by letting them specify an "auth=" flag proposed on the
> 20th
> .
> For example a mom-and-pop sender on their own infrastructure with their own
> IPs will have a different profile than a risky, enterprise sender on shared
> IPs.  The former would be reasonably safe using SPF and would benefit most
> from using it.  The latter should use DKIM authentication only due to the
> risk of SPF upgrade spoofing and the phishing exposure.  I describe some
> additional ideas about how to use "auth=" flag with different risk and
> infrastructure stratification on the DKIM list on July 3rd (archive
> 
> ).
>
> And FWIW I don't think mom-and-pop senders will find it that hard to adopt
> DKIM if sufficiently motivated.  For example for BIMI on Gmail, we now
> require DKIM-only authentication.  Indeed a new BIMI sender that I perceive
> to be running literally a "mom-and-pop" produce shop was using SPF
> authentication and was confused as to why their logo wasn't showing.  After
> explaining the requirement they were able to move to DKIM authentication in
> one day.  Yes, it did take explaining twice what was happening, but they
> were able to deploy DKIM on their own and got their logo to show up.
>
> Also can we do more to harden SPF?  The SPF upgrade attacks needs three
> things:
>
>- IPs shared by multiple sending domains
>- Some sender uses those IPs that permits spam and phish traffic
>- Those multiple sending domains have SPF policies that include those
>IPs
>
> Perhaps one way to harden to SPF for DMARC is to detect if the IPs are
> shared.  The authenticator in addition to regular to SPF validation, might
> be able to use reverse PTR lookup and match the SPF record domain name (or
> match some subset like the org domain) to forward validate.  Only one
> domain can claim ownership for the IPs and be allowed to SPF authenticate
> for DMARC.
>
> -Wei
>
> On Mon, Jul 10, 2023 at 5:38 PM Scott Kitterman 
> wrote:
>
>> I've been thinking about the thread on ditching SPF relative to DMARC.
>>
>> DMARC is built on other protocols.  Piles of them.
>>
>> DMARC is built most directly on DNS, DKIM, and SPF.  It is also built on
>> SMTP
>> and Email.  DKIM and SPF are also built on DNS and SMTP (SPF) or Email
>> (DKIM).
>> These protocols are built on others.  All of them have flaws and
>> limitations.
>>
>> As an example, although each of the three top level protocols in this
>> particular stack depend on data from DNS being reliable, they merely
>> counsel
>> caution about DNS spoofing, they don't mandate DNSSEC.  Note that other
>> protocols have different choices in this regard (e.g. DANE).
>>
>> We accept the risk of DNS spoofing associated with non-DNSSEC secured DNS
>> because the view is that the benefit to deployability of SPF, DKIM, and
>> DMARC
>> is sufficient to offset the risks.
>>
>> What are the risks?  Since DNS spoofing is not particularly easy since
>> Dan
>> Kaminsky got everyone to implement source port randomization [1].  I
>> think
>> it's reasonable to assume if an actor is going to the trouble to spoff
>> SPF/
>> DKIM/DMARC records, then it's to try and get a 'bad' message to appear
>> authentic.  I'm not aware of this being a significant problem (probably
>> since
>> there are easier ways to do it), so I think the design decision to not
>> limit
>> these protols to DNSSEC protected domains is a reasonable one.
>>
>> Similarly, SPF pass results can be leveraged to a DMARC a DMARC pass
>> result if
>> an actor can manage to get a third party provider to accept mail to be
>> sent
>> with the victim domain's mail from when that domain has listed that third
>> party as a source of authorized mail.  RFC 7208 warns about this risk {2}.
>>
>> DKIM has different risks.  The cryptographic mechanism used by DKIM is
>> meant to
>> provide strong, but limited duration assurance that an

Re: [dmarc-ietf] Protocols All The Way Down (long - sorry)

[Wei Chuang]

The data we presented June 20th (archive
)
also suggests that it is premature to drop SPF from DMARC.  However I
differ in believing that we should accept the spoofing risk demonstrated
recently via SPF, and that we shouldn't strive to reduce it by making
improvements to DMARC and possibly SPF.  One approach is to enable
different senders to distinguish their differing levels of risk and
infrastructure by letting them specify an "auth=" flag proposed on the 20th
.
For example a mom-and-pop sender on their own infrastructure with their own
IPs will have a different profile than a risky, enterprise sender on shared
IPs.  The former would be reasonably safe using SPF and would benefit most
from using it.  The latter should use DKIM authentication only due to the
risk of SPF upgrade spoofing and the phishing exposure.  I describe some
additional ideas about how to use "auth=" flag with different risk and
infrastructure stratification on the DKIM list on July 3rd (archive

).

And FWIW I don't think mom-and-pop senders will find it that hard to adopt
DKIM if sufficiently motivated.  For example for BIMI on Gmail, we now
require DKIM-only authentication.  Indeed a new BIMI sender that I perceive
to be running literally a "mom-and-pop" produce shop was using SPF
authentication and was confused as to why their logo wasn't showing.  After
explaining the requirement they were able to move to DKIM authentication in
one day.  Yes, it did take explaining twice what was happening, but they
were able to deploy DKIM on their own and got their logo to show up.

Also can we do more to harden SPF?  The SPF upgrade attacks needs three
things:

   - IPs shared by multiple sending domains
   - Some sender uses those IPs that permits spam and phish traffic
   - Those multiple sending domains have SPF policies that include those IPs

Perhaps one way to harden to SPF for DMARC is to detect if the IPs are
shared.  The authenticator in addition to regular to SPF validation, might
be able to use reverse PTR lookup and match the SPF record domain name (or
match some subset like the org domain) to forward validate.  Only one
domain can claim ownership for the IPs and be allowed to SPF authenticate
for DMARC.

-Wei

On Mon, Jul 10, 2023 at 5:38 PM Scott Kitterman 
wrote:

> I've been thinking about the thread on ditching SPF relative to DMARC.
>
> DMARC is built on other protocols.  Piles of them.
>
> DMARC is built most directly on DNS, DKIM, and SPF.  It is also built on
> SMTP
> and Email.  DKIM and SPF are also built on DNS and SMTP (SPF) or Email
> (DKIM).
> These protocols are built on others.  All of them have flaws and
> limitations.
>
> As an example, although each of the three top level protocols in this
> particular stack depend on data from DNS being reliable, they merely
> counsel
> caution about DNS spoofing, they don't mandate DNSSEC.  Note that other
> protocols have different choices in this regard (e.g. DANE).
>
> We accept the risk of DNS spoofing associated with non-DNSSEC secured DNS
> because the view is that the benefit to deployability of SPF, DKIM, and
> DMARC
> is sufficient to offset the risks.
>
> What are the risks?  Since DNS spoofing is not particularly easy since Dan
> Kaminsky got everyone to implement source port randomization [1].  I think
> it's reasonable to assume if an actor is going to the trouble to spoff SPF/
> DKIM/DMARC records, then it's to try and get a 'bad' message to appear
> authentic.  I'm not aware of this being a significant problem (probably
> since
> there are easier ways to do it), so I think the design decision to not
> limit
> these protols to DNSSEC protected domains is a reasonable one.
>
> Similarly, SPF pass results can be leveraged to a DMARC a DMARC pass
> result if
> an actor can manage to get a third party provider to accept mail to be
> sent
> with the victim domain's mail from when that domain has listed that third
> party as a source of authorized mail.  RFC 7208 warns about this risk {2}.
>
> DKIM has different risks.  The cryptographic mechanism used by DKIM is
> meant to
> provide strong, but limited duration assurance that an email was sent
> through
> a mail server authorized to do so and additionally that it has not been
> modified in certain ways since.  This has not always worked out well [3].
> It
> only took the IETF six years to address the issue [4].  Additionally, for
> some
> types of senders, they can be vulnerable to replay if they sign on 'bad'
> message in error.  This is an issue that was identified during DKIM's
> development and warned about in the protocol documentation [5].
>
> This might all seem terrible, but it's really not.  If you look that the
> goals
> of DMARC (current draft section 2.1), they are modest.  Specific t

[dmarc-ietf] Protocols All The Way Down (long - sorry)

[Scott Kitterman]

I've been thinking about the thread on ditching SPF relative to DMARC.

DMARC is built on other protocols.  Piles of them.

DMARC is built most directly on DNS, DKIM, and SPF.  It is also built on SMTP 
and Email.  DKIM and SPF are also built on DNS and SMTP (SPF) or Email (DKIM).  
These protocols are built on others.  All of them have flaws and limitations.

As an example, although each of the three top level protocols in this 
particular stack depend on data from DNS being reliable, they merely counsel 
caution about DNS spoofing, they don't mandate DNSSEC.  Note that other 
protocols have different choices in this regard (e.g. DANE).

We accept the risk of DNS spoofing associated with non-DNSSEC secured DNS 
because the view is that the benefit to deployability of SPF, DKIM, and DMARC 
is sufficient to offset the risks.

What are the risks?  Since DNS spoofing is not particularly easy since Dan 
Kaminsky got everyone to implement source port randomization [1].  I think 
it's reasonable to assume if an actor is going to the trouble to spoff SPF/
DKIM/DMARC records, then it's to try and get a 'bad' message to appear 
authentic.  I'm not aware of this being a significant problem (probably since 
there are easier ways to do it), so I think the design decision to not limit 
these protols to DNSSEC protected domains is a reasonable one.

Similarly, SPF pass results can be leveraged to a DMARC a DMARC pass result if 
an actor can manage to get a third party provider to accept mail to be sent 
with the victim domain's mail from when that domain has listed that third 
party as a source of authorized mail.  RFC 7208 warns about this risk {2}.

DKIM has different risks.  The cryptographic mechanism used by DKIM is meant to 
provide strong, but limited duration assurance that an email was sent through 
a mail server authorized to do so and additionally that it has not been 
modified in certain ways since.  This has not always worked out well [3].  It 
only took the IETF six years to address the issue [4].  Additionally, for some 
types of senders, they can be vulnerable to replay if they sign on 'bad' 
message in error.  This is an issue that was identified during DKIM's 
development and warned about in the protocol documentation [5].

This might all seem terrible, but it's really not.  If you look that the goals 
of DMARC (current draft section 2.1), they are modest.  Specific to this 
particular question:

   *  Allow Domain Owners and PSOs to assert their desired message
  handling for authentication failures for messages purporting to
  have authorship within the domain.

   *  Reduce the amount of successfully delivered spoofed emails.

The risks associated with all the above issues are that there are cases where 
'bad' messages pass DMARC and so the domain owner/PSO policy is not applied.  
Given that none of these protocols are perfect (and the risks extend much 
further than these I've highlighted), there are always going to be messages 
that get marked DMARC pass that are 'bad'.  Fundamentally 'good' and 'bad' 
aren't fully reducible to a protocol and the gaps between the protocol and 
human judgement will always exist.

Any message that passes DMARC should still be sugject to the normal spam/ 
phising prevent processing done by receivers.  Just because you got an email 
from bigbank.example which passed DMARC, doesn't mean that it might not have 
been sent through a compromised desktop in bigbank.example's office that has 
the 
least professionally run information secuirty opreation.

DMARC is going to have false positives and false negatives and those need to 
be considered by implementers when assessing how to use DMARC.  The 'problem' 
with DMARC (including the 'problem' with SPF in DMARC) only arises when DMARC 
results are used in ways that were never intended.  By design and based on the 
goals of DMARC, a DMARC pass result doesn't carry any guarantee that any 
particular email was in fact sent legitimately by the organization that 
claimed to send it, but unfortunately, people are assuming it does [6].

As I've said before, I don't think dropping SPF from DMARC is a good idea and 
I don't think it will usefully solve the problem that proponents of dropping 
think it will solve.  I do think we need to do something in the draft to 
address the overall question of the reliability of the DMARC assertion that a 
particular message is authorized/has been authenticated.

The think that the current security considerations are insufficient and we can 
address these concerns by expanding on them.  Currently, the DMARCbis Security 
Considerations start with:

> 11.1.  Authentication Methods
> 
>Security considerations from the authentication methods used by DMARC
>are incorporated here by reference.

I would assess that as necessary, but not sufficient.  Here's my proposal for 
expanding 11.1:


11.1.  Authentication Methods

   Security considerations from the authentication methods used by