Re: [dmarc-ietf] DMARC and Data Hygiene

[Neil Anuskiewicz]

 At a fundamental authentication property level, there are additional differences too.  IPs tend to be shared more than private keys. Proving an IP based validation to a third party is harder than with a digital signature.  (This is one the issues of trusting the SPF results in ARC-Authentication-Result, whereas with DKIM once can try to validate the signature yourself).  On the other hand it's only fair to make the observation that SPF is easier to set up than DKIM and we want to capture those benefits as well.Is dkim really harder than SPF? I think part of the reason some of mega ESPs only support dkim alignment is because a lot can be automated. And you’re addiding something, not changing something (I.e., the envelope from). In most cases these days implementing dkim on the user side involves copying and pasting a txt or, increasingly common, a CNAME. It’s easier for everyone.I think DKIM’s simple for the end user at the mega ESPs. The incentives push them to make it as easy possible, while punting or shoving aligned spf aside.No, SPF has its place unless I’ve been a way from this list for so long I didn’t get the memo on that. So yes not deprecated until we come up with something a bit better or it becomes more of a liability than an asset.We're definitely not saying SPF should be deprecated, and in fact we want more deployment of SPF as it's highly complementary to DKIM both from a deployment perspective but as a spam fighting signal.  We just want to prevent its use in From header spoofing.  [1] https://www.sysnet.ucsd.edu/~voelker/pubs/forwarding-eurosp23.pdf 

I'll lay out examples to demonstrate:

Case 1 - First Party Only

An organization only authorizes email to be sent from MTAs it directly 
controls (I know this mostly doesn't exist, but it's useful to show where the 
problems are).  The organization does not send email for any third parties.

In this case, as long as the organization can limit sending to authorized 
users, the quality of both SPF and DKIM pass results should be well aligned 
with the nature of the mail the organization sends.

Case 2 - Sender For Others, Own Domain

An domain uses it's own domain to send mail for others (like all webmail 
providers).  The domain's email is sent using it's own infrastructure, so it 
doesn't need to worry directly about third parties.

In this case, there's still no real risk of external forgery, so an SPF or 
DKIM pass means it was sent by the domain.  The risk is to the domain's 
reputation if users sign up and use the service to send "bad" mail.

If the domain fails to prevent 'bad' messages from being sent, then these 'bad 
messages get a DMARC pass.  The mail is sent through the authorized email 
server, so it gets SPF pass and a valid DKIM signature.

This is a particular threat for DKIM, because once this succeeds for a single 
message, the user can replay the message on third party infrastructure to send 
it to large numbers of recipients.  This is the core issue the DKIM working 
group was resurrected to address.  It is not, however, clear that there's a 
protocol solution to this problem and the group has been pretty quiet 
recently.Just pointing out we're prototyping one of the drafts and there's other work behind the scene. 
Case 3 - Sender For Others, Their Domain

When organizations authorized third parties to send on their behalf (by 
publishing an SPF record or a DKIM public key record in DNS), they are 
trusting their domain's reputation to those third parties.

In particular, they are at risk of those third parties doing poor inbound 
validation and other customers of the authorized third parties injecting 'bad' 
mail authorized by their domain.

This is where I think the focus of recent discussion has been.

In these cases, email is emitted via third parties and passes SPF (may also be 
DKIM signed, but I suspect it's less common because replay is easier), so it's 
authorized, but unwanted.

Case 2 and Case 3 are both real problems, but only because people are trying 
to make DMARC pass a positive assertion.  In order to do that reliably, 
organizations need to be more like Case 1 and be very careful vetting third 
parties that they authorize for.  I don't think that's a protocol problem.I'm not sure.  Much as Case 1 provides safety, the email Internet today has a large part that's based on Case 2 and 3 and it's up to us to frame standards that provide safety for our users by solving the issues you mentioned.  (Or if those needs are ignored, then likely those users will move to walled gardens that can claim more safety)  For case 2, we (and others) put drafts that provide a technical solution.  For case 3, we posed some ideas that can hopefully help.-Wei

Scott K




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

___dmarc mailing 

Re: [dmarc-ietf] DMARC and Data Hygiene

[Neil Anuskiewicz]

On Jun 20, 2023, at 11:42 PM, Wei Chuang  wrote:On Tue, Jun 20, 2023 at 8:18 AM Scott Kitterman  wrote:I am starting a separate thread, because this isn't just about SPF.

I think the criticism of the reliability of SPF data is valid, but I think 
DKIM is similarly problematic.  Once you get rid of SPF, you'll find you 
haven't really solved much.  The next logical step will be to get rid of DKIM.

DKIM has man wonderful features, but the bottom line for DMARC is a valid DKIM 
signature indicates that the mail was sent (at some point) from an MTA that 
was authorized by the signing domain.  This is what a SPF pass result means 
too.  DKIM has broader utility in DMARC because it can persist through some 
indirect mail flows, but either way, an SPF pass and a valid DKIM signature 
both mean the message was authorized by the domain in the relevant identity.

The particular SPF problem that's being the focus of some much attention is 
addressed in the RFC 7208 security considerations (See section 11.4).

DKIM has a similar, but different problem.  The DKIM replay problem is bad 
enough that the IETF has chartered a working group to try to address it:

https://datatracker.ietf.org/doc/charter-ietf-dkim/I would argue we can see a difference in the SPF and DKIM attacks with respect to spoofing and that makes a difference for phishing.  With the SPF upgrade attack, the adversary can spoof an arbitrary identity in the victim domain and have it SPF authenticated.  See [1] for examples.  With DKIM replay, the adversary needs access to an account in the victim domain to obtain a signed message, but can't arbitrarily spoof some other identity in the victim domain.  At a fundamental authentication property level, there are additional differences too.  IPs tend to be shared more than private keys. Proving an IP based validation to a third party is harder than with a digital signature.  (This is one the issues of trusting the SPF results in ARC-Authentication-Result, whereas with DKIM once can try to validate the signature yourself).  On the other hand it's only fair to make the observation that SPF is easier to set up than DKIM and we want to capture those benefits as well.We're definitely not saying SPF should be deprecated, and in fact we want more deployment of SPF as it's highly complementary to DKIM both from a deployment perspective but as a spam fighting signal.  We just want to prevent its use in From header spoofing.  [1] https://www.sysnet.ucsd.edu/~voelker/pubs/forwarding-eurosp23.pdf 

I'll lay out examples to demonstrate:

Case 1 - First Party Only

An organization only authorizes email to be sent from MTAs it directly 
controls (I know this mostly doesn't exist, but it's useful to show where the 
problems are).  The organization does not send email for any third parties.

In this case, as long as the organization can limit sending to authorized 
users, the quality of both SPF and DKIM pass results should be well aligned 
with the nature of the mail the organization sends.

Case 2 - Sender For Others, Own Domain

An domain uses it's own domain to send mail for others (like all webmail 
providers).  The domain's email is sent using it's own infrastructure, so it 
doesn't need to worry directly about third parties.

In this case, there's still no real risk of external forgery, so an SPF or 
DKIM pass means it was sent by the domain.  The risk is to the domain's 
reputation if users sign up and use the service to send "bad" mail.

If the domain fails to prevent 'bad' messages from being sent, then these 'bad 
messages get a DMARC pass.  The mail is sent through the authorized email 
server, so it gets SPF pass and a valid DKIM signature.

This is a particular threat for DKIM, because once this succeeds for a single 
message, the user can replay the message on third party infrastructure to send 
it to large numbers of recipients.  This is the core issue the DKIM working 
group was resurrected to address.  It is not, however, clear that there's a 
protocol solution to this problem and the group has been pretty quiet 
recently.Just pointing out we're prototyping one of the drafts and there's other work behind the scene. 
Case 3 - Sender For Others, Their Domain

When organizations authorized third parties to send on their behalf (by 
publishing an SPF record or a DKIM public key record in DNS), they are 
trusting their domain's reputation to those third parties.

In particular, they are at risk of those third parties doing poor inbound 
validation and other customers of the authorized third parties injecting 'bad' 
mail authorized by their domain.

This is where I think the focus of recent discussion has been.

In these cases, email is emitted via third parties and passes SPF (may also be 
DKIM signed, but I suspect it's less common because replay is easier), so it's 
authorized, but unwanted.

Case 2 and Case 3 are both real problems, but only because people are trying 
to make DMARC pass 

Re: [dmarc-ietf] DMARC and Data Hygiene

[Douglas Foster]

In a perfect world, we would have a two-tailed test, where PASS really
means "no malicious impersonation" and "FAIL" really means "malicious
impersonation".   Absent that ideal, we can try for a one-tailed test,
either
"FAIL" means "malicious interpretation" but "PASS" only means "uncertain",
or
"PASS" means "no malicious interpretation" and "FAIL" means "uncertain"

The discussion has convinced me that neither is entirely reliable, so we
have a zero-tail test.   But as a practical matter, I trust PASS more than
FAIL so I only act on FAIL after all other possibilities are ruled out.

In the typical environment, messages which are not blocked by sender
authentication will still need to pass content filtering, unless the sender
is whitelisted.  Whitelisting needs to be based on evidence to avoid
whitelisting an impersonator.   So if an evaluator does any whitelisting,
he needs a PASS rule to make whitelisting safe.   That makes PASS critical,
at least for that subset of messages (and those messages may not be from
DMARC-enforcing senders.)

I don't have the luxury of blocking messages that are legitimate and needed
for business purposes, so I have to quarantine and inspect for messages
that are uncertain.   Sender authentication FAIL is prioritized for that
quarantine and review process.Messages which pass sender authentication
can still get blocked during content filtering.  Content filtering failures
often indicate malicious senders, so those results are reviewed and often
become sender authentication blocks.

Doug






On Wed, Jun 21, 2023 at 11:46 PM Scott Kitterman 
wrote:

> I think that's exactly backwards.  The most DMARC pass can mean is from
> who it
> says it's from.  It says nothing about if the message should be accepted.
> Even in the case of email directly from the infrastructure of a high
> reputation domain, there's no guarantee it didn't get there because one of
> the
> employees got phished and their credentials or client are compromised.
>
> Scott K
>
> On Wednesday, June 21, 2023 9:26:28 AM EDT Douglas Foster wrote:
> > Every allowed message is presumed to be free of malicious impersonation.
> > That presumption is either based on evidence (some mixture of DKIM, SPF,
> > and fcDNS) or blind faith. "Positive assertions" are intrinsic to
> what
> > we are doing.  Without them, we have only blind faith.
> >
> > Doug Foster.
> >
> > On Tue, Jun 20, 2023, 1:29 PM Dotzero  wrote:
> > > On Tue, Jun 20, 2023 at 11:18 AM Scott Kitterman  >
> > >
> > > wrote:
> > >> I am starting a separate thread, because this isn't just about SPF.
> > >>
> > >> I think the criticism of the reliability of SPF data is valid, but I
> > >> think
> > >> DKIM is similarly problematic.  Once you get rid of SPF, you'll find
> you
> > >> haven't really solved much.  The next logical step will be to get rid
> of
> > >> DKIM.
> > >>
> > >> DKIM has man wonderful features, but the bottom line for DMARC is a
> valid
> > >> DKIM
> > >> signature indicates that the mail was sent (at some point) from an MTA
> > >> that
> > >> was authorized by the signing domain.  This is what a SPF pass result
> > >> means
> > >> too.  DKIM has broader utility in DMARC because it can persist through
> > >> some
> > >> indirect mail flows, but either way, an SPF pass and a valid DKIM
> > >> signature
> > >> both mean the message was authorized by the domain in the relevant
> > >> identity.
> > >>
> > >>
> > >> The particular SPF problem that's being the focus of some much
> attention
> > >> is
> > >> addressed in the RFC 7208 security considerations (See section 11.4).
> > >>
> > >> DKIM has a similar, but different problem.  The DKIM replay problem is
> > >> bad
> > >> enough that the IETF has chartered a working group to try to address
> it:
> > >>
> > >> https://datatracker.ietf.org/doc/charter-ietf-dkim/
> > >>
> > >> I'll lay out examples to demonstrate:
> > >>
> > >> Case 1 - First Party Only
> > >>
> > >> An organization only authorizes email to be sent from MTAs it directly
> > >> controls (I know this mostly doesn't exist, but it's useful to show
> where
> > >> the
> > >> problems are).  The organization does not send email for any third
> > >> parties.
> > >>
> > >> In this case, as long as the organization can limit sending to
> authorized
> > >> users, the quality of both SPF and DKIM pass results should be well
> > >> aligned
> > >> with the nature of the mail the organization sends.
> > >>
> > >> Case 2 - Sender For Others, Own Domain
> > >>
> > >> An domain uses it's own domain to send mail for others (like all
> webmail
> > >> providers).  The domain's email is sent using it's own
> infrastructure, so
> > >> it
> > >> doesn't need to worry directly about third parties.
> > >>
> > >> In this case, there's still no real risk of external forgery, so an
> SPF
> > >> or
> > >> DKIM pass means it was sent by the domain.  The risk is to the
> domain's
> > >> reputation if users sign up and use the service to send "bad" mail.

Re: [dmarc-ietf] DMARC and Data Hygiene

[Scott Kitterman]

I think that's exactly backwards.  The most DMARC pass can mean is from who it 
says it's from.  It says nothing about if the message should be accepted.  
Even in the case of email directly from the infrastructure of a high 
reputation domain, there's no guarantee it didn't get there because one of the 
employees got phished and their credentials or client are compromised.

Scott K

On Wednesday, June 21, 2023 9:26:28 AM EDT Douglas Foster wrote:
> Every allowed message is presumed to be free of malicious impersonation.
> That presumption is either based on evidence (some mixture of DKIM, SPF,
> and fcDNS) or blind faith. "Positive assertions" are intrinsic to what
> we are doing.  Without them, we have only blind faith.
> 
> Doug Foster.
> 
> On Tue, Jun 20, 2023, 1:29 PM Dotzero  wrote:
> > On Tue, Jun 20, 2023 at 11:18 AM Scott Kitterman 
> > 
> > wrote:
> >> I am starting a separate thread, because this isn't just about SPF.
> >> 
> >> I think the criticism of the reliability of SPF data is valid, but I
> >> think
> >> DKIM is similarly problematic.  Once you get rid of SPF, you'll find you
> >> haven't really solved much.  The next logical step will be to get rid of
> >> DKIM.
> >> 
> >> DKIM has man wonderful features, but the bottom line for DMARC is a valid
> >> DKIM
> >> signature indicates that the mail was sent (at some point) from an MTA
> >> that
> >> was authorized by the signing domain.  This is what a SPF pass result
> >> means
> >> too.  DKIM has broader utility in DMARC because it can persist through
> >> some
> >> indirect mail flows, but either way, an SPF pass and a valid DKIM
> >> signature
> >> both mean the message was authorized by the domain in the relevant
> >> identity.
> >> 
> >> 
> >> The particular SPF problem that's being the focus of some much attention
> >> is
> >> addressed in the RFC 7208 security considerations (See section 11.4).
> >> 
> >> DKIM has a similar, but different problem.  The DKIM replay problem is
> >> bad
> >> enough that the IETF has chartered a working group to try to address it:
> >> 
> >> https://datatracker.ietf.org/doc/charter-ietf-dkim/
> >> 
> >> I'll lay out examples to demonstrate:
> >> 
> >> Case 1 - First Party Only
> >> 
> >> An organization only authorizes email to be sent from MTAs it directly
> >> controls (I know this mostly doesn't exist, but it's useful to show where
> >> the
> >> problems are).  The organization does not send email for any third
> >> parties.
> >> 
> >> In this case, as long as the organization can limit sending to authorized
> >> users, the quality of both SPF and DKIM pass results should be well
> >> aligned
> >> with the nature of the mail the organization sends.
> >> 
> >> Case 2 - Sender For Others, Own Domain
> >> 
> >> An domain uses it's own domain to send mail for others (like all webmail
> >> providers).  The domain's email is sent using it's own infrastructure, so
> >> it
> >> doesn't need to worry directly about third parties.
> >> 
> >> In this case, there's still no real risk of external forgery, so an SPF
> >> or
> >> DKIM pass means it was sent by the domain.  The risk is to the domain's
> >> reputation if users sign up and use the service to send "bad" mail.
> >> 
> >> If the domain fails to prevent 'bad' messages from being sent, then these
> >> 'bad
> >> messages get a DMARC pass.  The mail is sent through the authorized email
> >> server, so it gets SPF pass and a valid DKIM signature.
> >> 
> >> This is a particular threat for DKIM, because once this succeeds for a
> >> single
> >> message, the user can replay the message on third party infrastructure to
> >> send
> >> it to large numbers of recipients.  This is the core issue the DKIM
> >> working
> >> group was resurrected to address.  It is not, however, clear that there's
> >> a
> >> protocol solution to this problem and the group has been pretty quiet
> >> recently.
> >> 
> >> Case 3 - Sender For Others, Their Domain
> >> 
> >> When organizations authorized third parties to send on their behalf (by
> >> publishing an SPF record or a DKIM public key record in DNS), they are
> >> trusting their domain's reputation to those third parties.
> >> 
> >> In particular, they are at risk of those third parties doing poor inbound
> >> validation and other customers of the authorized third parties injecting
> >> 'bad'
> >> mail authorized by their domain.
> >> 
> >> This is where I think the focus of recent discussion has been.
> >> 
> >> In these cases, email is emitted via third parties and passes SPF (may
> >> also be
> >> DKIM signed, but I suspect it's less common because replay is easier), so
> >> it's
> >> authorized, but unwanted.
> >> 
> >> Case 2 and Case 3 are both real problems, but only because people are
> >> trying
> >> to make DMARC pass a positive assertion.  In order to do that reliably,
> >> organizations need to be more like Case 1 and be very careful vetting
> >> third
> >> parties that they authorize for.  I don't think that's 

Re: [dmarc-ietf] DMARC and Data Hygiene

[Douglas Foster]

Every allowed message is presumed to be free of malicious impersonation.
That presumption is either based on evidence (some mixture of DKIM, SPF,
and fcDNS) or blind faith. "Positive assertions" are intrinsic to what
we are doing.  Without them, we have only blind faith.

Doug Foster.


On Tue, Jun 20, 2023, 1:29 PM Dotzero  wrote:

>
>
> On Tue, Jun 20, 2023 at 11:18 AM Scott Kitterman 
> wrote:
>
>> I am starting a separate thread, because this isn't just about SPF.
>>
>> I think the criticism of the reliability of SPF data is valid, but I
>> think
>> DKIM is similarly problematic.  Once you get rid of SPF, you'll find you
>> haven't really solved much.  The next logical step will be to get rid of
>> DKIM.
>>
>> DKIM has man wonderful features, but the bottom line for DMARC is a valid
>> DKIM
>> signature indicates that the mail was sent (at some point) from an MTA
>> that
>> was authorized by the signing domain.  This is what a SPF pass result
>> means
>> too.  DKIM has broader utility in DMARC because it can persist through
>> some
>> indirect mail flows, but either way, an SPF pass and a valid DKIM
>> signature
>> both mean the message was authorized by the domain in the relevant
>> identity.
>>
>
>> The particular SPF problem that's being the focus of some much attention
>> is
>> addressed in the RFC 7208 security considerations (See section 11.4).
>>
>> DKIM has a similar, but different problem.  The DKIM replay problem is
>> bad
>> enough that the IETF has chartered a working group to try to address it:
>>
>> https://datatracker.ietf.org/doc/charter-ietf-dkim/
>>
>> I'll lay out examples to demonstrate:
>>
>> Case 1 - First Party Only
>>
>> An organization only authorizes email to be sent from MTAs it directly
>> controls (I know this mostly doesn't exist, but it's useful to show where
>> the
>> problems are).  The organization does not send email for any third
>> parties.
>>
>> In this case, as long as the organization can limit sending to authorized
>> users, the quality of both SPF and DKIM pass results should be well
>> aligned
>> with the nature of the mail the organization sends.
>>
>> Case 2 - Sender For Others, Own Domain
>>
>> An domain uses it's own domain to send mail for others (like all webmail
>> providers).  The domain's email is sent using it's own infrastructure, so
>> it
>> doesn't need to worry directly about third parties.
>>
>> In this case, there's still no real risk of external forgery, so an SPF
>> or
>> DKIM pass means it was sent by the domain.  The risk is to the domain's
>> reputation if users sign up and use the service to send "bad" mail.
>>
>> If the domain fails to prevent 'bad' messages from being sent, then these
>> 'bad
>> messages get a DMARC pass.  The mail is sent through the authorized email
>> server, so it gets SPF pass and a valid DKIM signature.
>>
>> This is a particular threat for DKIM, because once this succeeds for a
>> single
>> message, the user can replay the message on third party infrastructure to
>> send
>> it to large numbers of recipients.  This is the core issue the DKIM
>> working
>> group was resurrected to address.  It is not, however, clear that there's
>> a
>> protocol solution to this problem and the group has been pretty quiet
>> recently.
>>
>> Case 3 - Sender For Others, Their Domain
>>
>> When organizations authorized third parties to send on their behalf (by
>> publishing an SPF record or a DKIM public key record in DNS), they are
>> trusting their domain's reputation to those third parties.
>>
>> In particular, they are at risk of those third parties doing poor inbound
>> validation and other customers of the authorized third parties injecting
>> 'bad'
>> mail authorized by their domain.
>>
>> This is where I think the focus of recent discussion has been.
>>
>> In these cases, email is emitted via third parties and passes SPF (may
>> also be
>> DKIM signed, but I suspect it's less common because replay is easier), so
>> it's
>> authorized, but unwanted.
>>
>> Case 2 and Case 3 are both real problems, but only because people are
>> trying
>> to make DMARC pass a positive assertion.  In order to do that reliably,
>> organizations need to be more like Case 1 and be very careful vetting
>> third
>> parties that they authorize for.  I don't think that's a protocol problem.
>>
>
> I think this is a key factor for the calculus of value in DMARC " ...but
> only because people are trying to make DMARC pass a positive assertion." I
> agree that it's not a protocol implementation.
>
> It really can't/shouldn't be used to try and make positive assertions
> (even though people attempt to do so). Apart from the cases Scott points
> out, there is the very real situation of when good domains go bad, whether
> because the good domain has been subverted, sold or for other reasons. If
> we move away from attempting to use DMARC to make a positive assertion then
> the issues around configurations/implementations become less problematic.
> 

Re: [dmarc-ietf] DMARC and Data Hygiene

[Scott Kitterman]

On Wednesday, June 21, 2023 2:41:35 AM EDT Wei Chuang wrote:
> On Tue, Jun 20, 2023 at 8:18 AM Scott Kitterman 
> 
> wrote:
> > I am starting a separate thread, because this isn't just about SPF.
> > 
> > I think the criticism of the reliability of SPF data is valid, but I think
> > DKIM is similarly problematic.  Once you get rid of SPF, you'll find you
> > haven't really solved much.  The next logical step will be to get rid of
> > DKIM.
> > 
> > DKIM has man wonderful features, but the bottom line for DMARC is a valid
> > DKIM
> > signature indicates that the mail was sent (at some point) from an MTA
> > that
> > was authorized by the signing domain.  This is what a SPF pass result
> > means
> > too.  DKIM has broader utility in DMARC because it can persist through
> > some
> > indirect mail flows, but either way, an SPF pass and a valid DKIM
> > signature
> > both mean the message was authorized by the domain in the relevant
> > identity.
> > 
> > 
> > The particular SPF problem that's being the focus of some much attention
> > is
> > addressed in the RFC 7208 security considerations (See section 11.4).
> > 
> > DKIM has a similar, but different problem.  The DKIM replay problem is bad
> > enough that the IETF has chartered a working group to try to address it:
> > 
> > https://datatracker.ietf.org/doc/charter-ietf-dkim/
> 
> I would argue we can see a difference in the SPF and DKIM attacks with
> respect to spoofing and that makes a difference for phishing.  With the SPF
> upgrade attack, the adversary can spoof an arbitrary identity in the victim
> domain and have it SPF authenticated.  See [1] for examples.  With DKIM
> replay, the adversary needs access to an account in the victim domain to
> obtain a signed message, but can't arbitrarily spoof some other identity in
> the victim domain.
> 
> At a fundamental authentication property level, there are additional
> differences too.  IPs tend to be shared more than private keys. Proving an
> IP based validation to a third party is harder than with a digital
> signature.  (This is one the issues of trusting the SPF results in
> ARC-Authentication-Result, whereas with DKIM once can try to validate the
> signature yourself).  On the other hand it's only fair to make
> the observation that SPF is easier to set up than DKIM and we want to
> capture those benefits as well.
> 
> We're definitely not saying SPF should be deprecated, and in fact we want
> more deployment of SPF as it's highly complementary to DKIM both from a
> deployment perspective but as a spam fighting signal.  We just want to
> prevent its use in From header spoofing.
> 
> [1] https://www.sysnet.ucsd.edu/~voelker/pubs/forwarding-eurosp23.pdf
> 
> > I'll lay out examples to demonstrate:
> > 
> > Case 1 - First Party Only
> > 
> > An organization only authorizes email to be sent from MTAs it directly
> > controls (I know this mostly doesn't exist, but it's useful to show where
> > the
> > problems are).  The organization does not send email for any third
> > parties.
> > 
> > In this case, as long as the organization can limit sending to authorized
> > users, the quality of both SPF and DKIM pass results should be well
> > aligned
> > with the nature of the mail the organization sends.
> > 
> > Case 2 - Sender For Others, Own Domain
> > 
> > An domain uses it's own domain to send mail for others (like all webmail
> > providers).  The domain's email is sent using it's own infrastructure, so
> > it
> > doesn't need to worry directly about third parties.
> > 
> > In this case, there's still no real risk of external forgery, so an SPF or
> > DKIM pass means it was sent by the domain.  The risk is to the domain's
> > reputation if users sign up and use the service to send "bad" mail.
> > 
> > If the domain fails to prevent 'bad' messages from being sent, then these
> > 'bad
> > messages get a DMARC pass.  The mail is sent through the authorized email
> > server, so it gets SPF pass and a valid DKIM signature.
> > 
> > This is a particular threat for DKIM, because once this succeeds for a
> > single
> > message, the user can replay the message on third party infrastructure to
> > send
> > it to large numbers of recipients.  This is the core issue the DKIM
> > working
> > group was resurrected to address.  It is not, however, clear that there's
> > a
> > protocol solution to this problem and the group has been pretty quiet
> > recently.
> 
> Just pointing out we're prototyping one of the drafts and there's
> other work behind the scene.
> 
> > Case 3 - Sender For Others, Their Domain
> > 
> > When organizations authorized third parties to send on their behalf (by
> > publishing an SPF record or a DKIM public key record in DNS), they are
> > trusting their domain's reputation to those third parties.
> > 
> > In particular, they are at risk of those third parties doing poor inbound
> > validation and other customers of the authorized third parties injecting
> > 'bad'
> > mail authorized by their 

Re: [dmarc-ietf] DMARC and Data Hygiene

[Wei Chuang]

On Tue, Jun 20, 2023 at 8:18 AM Scott Kitterman 
wrote:

> I am starting a separate thread, because this isn't just about SPF.
>
> I think the criticism of the reliability of SPF data is valid, but I think
> DKIM is similarly problematic.  Once you get rid of SPF, you'll find you
> haven't really solved much.  The next logical step will be to get rid of
> DKIM.
>
> DKIM has man wonderful features, but the bottom line for DMARC is a valid
> DKIM
> signature indicates that the mail was sent (at some point) from an MTA
> that
> was authorized by the signing domain.  This is what a SPF pass result
> means
> too.  DKIM has broader utility in DMARC because it can persist through
> some
> indirect mail flows, but either way, an SPF pass and a valid DKIM
> signature
> both mean the message was authorized by the domain in the relevant
> identity.


> The particular SPF problem that's being the focus of some much attention
> is
> addressed in the RFC 7208 security considerations (See section 11.4).
>
> DKIM has a similar, but different problem.  The DKIM replay problem is bad
> enough that the IETF has chartered a working group to try to address it:
>
> https://datatracker.ietf.org/doc/charter-ietf-dkim/


I would argue we can see a difference in the SPF and DKIM attacks with
respect to spoofing and that makes a difference for phishing.  With the SPF
upgrade attack, the adversary can spoof an arbitrary identity in the victim
domain and have it SPF authenticated.  See [1] for examples.  With DKIM
replay, the adversary needs access to an account in the victim domain to
obtain a signed message, but can't arbitrarily spoof some other identity in
the victim domain.

At a fundamental authentication property level, there are additional
differences too.  IPs tend to be shared more than private keys. Proving an
IP based validation to a third party is harder than with a digital
signature.  (This is one the issues of trusting the SPF results in
ARC-Authentication-Result, whereas with DKIM once can try to validate the
signature yourself).  On the other hand it's only fair to make
the observation that SPF is easier to set up than DKIM and we want to
capture those benefits as well.

We're definitely not saying SPF should be deprecated, and in fact we want
more deployment of SPF as it's highly complementary to DKIM both from a
deployment perspective but as a spam fighting signal.  We just want to
prevent its use in From header spoofing.

[1] https://www.sysnet.ucsd.edu/~voelker/pubs/forwarding-eurosp23.pdf


>
>
> I'll lay out examples to demonstrate:
>
> Case 1 - First Party Only
>
> An organization only authorizes email to be sent from MTAs it directly
> controls (I know this mostly doesn't exist, but it's useful to show where
> the
> problems are).  The organization does not send email for any third parties.
>
> In this case, as long as the organization can limit sending to authorized
> users, the quality of both SPF and DKIM pass results should be well
> aligned
> with the nature of the mail the organization sends.
>
> Case 2 - Sender For Others, Own Domain
>
> An domain uses it's own domain to send mail for others (like all webmail
> providers).  The domain's email is sent using it's own infrastructure, so
> it
> doesn't need to worry directly about third parties.
>
> In this case, there's still no real risk of external forgery, so an SPF or
> DKIM pass means it was sent by the domain.  The risk is to the domain's
> reputation if users sign up and use the service to send "bad" mail.
>
> If the domain fails to prevent 'bad' messages from being sent, then these
> 'bad
> messages get a DMARC pass.  The mail is sent through the authorized email
> server, so it gets SPF pass and a valid DKIM signature.
>
> This is a particular threat for DKIM, because once this succeeds for a
> single
> message, the user can replay the message on third party infrastructure to
> send
> it to large numbers of recipients.  This is the core issue the DKIM
> working
> group was resurrected to address.  It is not, however, clear that there's
> a
> protocol solution to this problem and the group has been pretty quiet
> recently.
>

Just pointing out we're prototyping one of the drafts and there's
other work behind the scene.


> Case 3 - Sender For Others, Their Domain
>
> When organizations authorized third parties to send on their behalf (by
> publishing an SPF record or a DKIM public key record in DNS), they are
> trusting their domain's reputation to those third parties.
>
> In particular, they are at risk of those third parties doing poor inbound
> validation and other customers of the authorized third parties injecting
> 'bad'
> mail authorized by their domain.
>
> This is where I think the focus of recent discussion has been.
>
> In these cases, email is emitted via third parties and passes SPF (may
> also be
> DKIM signed, but I suspect it's less common because replay is easier), so
> it's
> authorized, but unwanted.
>
> Case 2 and Case 3 are 

Re: [dmarc-ietf] DMARC and Data Hygiene

[Dotzero]

On Tue, Jun 20, 2023 at 11:18 AM Scott Kitterman 
wrote:

> I am starting a separate thread, because this isn't just about SPF.
>
> I think the criticism of the reliability of SPF data is valid, but I think
> DKIM is similarly problematic.  Once you get rid of SPF, you'll find you
> haven't really solved much.  The next logical step will be to get rid of
> DKIM.
>
> DKIM has man wonderful features, but the bottom line for DMARC is a valid
> DKIM
> signature indicates that the mail was sent (at some point) from an MTA
> that
> was authorized by the signing domain.  This is what a SPF pass result
> means
> too.  DKIM has broader utility in DMARC because it can persist through
> some
> indirect mail flows, but either way, an SPF pass and a valid DKIM
> signature
> both mean the message was authorized by the domain in the relevant
> identity.
>

> The particular SPF problem that's being the focus of some much attention
> is
> addressed in the RFC 7208 security considerations (See section 11.4).
>
> DKIM has a similar, but different problem.  The DKIM replay problem is bad
> enough that the IETF has chartered a working group to try to address it:
>
> https://datatracker.ietf.org/doc/charter-ietf-dkim/
>
> I'll lay out examples to demonstrate:
>
> Case 1 - First Party Only
>
> An organization only authorizes email to be sent from MTAs it directly
> controls (I know this mostly doesn't exist, but it's useful to show where
> the
> problems are).  The organization does not send email for any third parties.
>
> In this case, as long as the organization can limit sending to authorized
> users, the quality of both SPF and DKIM pass results should be well
> aligned
> with the nature of the mail the organization sends.
>
> Case 2 - Sender For Others, Own Domain
>
> An domain uses it's own domain to send mail for others (like all webmail
> providers).  The domain's email is sent using it's own infrastructure, so
> it
> doesn't need to worry directly about third parties.
>
> In this case, there's still no real risk of external forgery, so an SPF or
> DKIM pass means it was sent by the domain.  The risk is to the domain's
> reputation if users sign up and use the service to send "bad" mail.
>
> If the domain fails to prevent 'bad' messages from being sent, then these
> 'bad
> messages get a DMARC pass.  The mail is sent through the authorized email
> server, so it gets SPF pass and a valid DKIM signature.
>
> This is a particular threat for DKIM, because once this succeeds for a
> single
> message, the user can replay the message on third party infrastructure to
> send
> it to large numbers of recipients.  This is the core issue the DKIM
> working
> group was resurrected to address.  It is not, however, clear that there's
> a
> protocol solution to this problem and the group has been pretty quiet
> recently.
>
> Case 3 - Sender For Others, Their Domain
>
> When organizations authorized third parties to send on their behalf (by
> publishing an SPF record or a DKIM public key record in DNS), they are
> trusting their domain's reputation to those third parties.
>
> In particular, they are at risk of those third parties doing poor inbound
> validation and other customers of the authorized third parties injecting
> 'bad'
> mail authorized by their domain.
>
> This is where I think the focus of recent discussion has been.
>
> In these cases, email is emitted via third parties and passes SPF (may
> also be
> DKIM signed, but I suspect it's less common because replay is easier), so
> it's
> authorized, but unwanted.
>
> Case 2 and Case 3 are both real problems, but only because people are
> trying
> to make DMARC pass a positive assertion.  In order to do that reliably,
> organizations need to be more like Case 1 and be very careful vetting
> third
> parties that they authorize for.  I don't think that's a protocol problem.
>

I think this is a key factor for the calculus of value in DMARC " ...but
only because people are trying to make DMARC pass a positive assertion." I
agree that it's not a protocol implementation.

It really can't/shouldn't be used to try and make positive assertions (even
though people attempt to do so). Apart from the cases Scott points out,
there is the very real situation of when good domains go bad, whether
because the good domain has been subverted, sold or for other reasons. If
we move away from attempting to use DMARC to make a positive assertion then
the issues around configurations/implementations become less problematic.
Perfection is the enemy of good.

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

[dmarc-ietf] DMARC and Data Hygiene

[Scott Kitterman]

I am starting a separate thread, because this isn't just about SPF.

I think the criticism of the reliability of SPF data is valid, but I think 
DKIM is similarly problematic.  Once you get rid of SPF, you'll find you 
haven't really solved much.  The next logical step will be to get rid of DKIM.

DKIM has man wonderful features, but the bottom line for DMARC is a valid DKIM 
signature indicates that the mail was sent (at some point) from an MTA that 
was authorized by the signing domain.  This is what a SPF pass result means 
too.  DKIM has broader utility in DMARC because it can persist through some 
indirect mail flows, but either way, an SPF pass and a valid DKIM signature 
both mean the message was authorized by the domain in the relevant identity.

The particular SPF problem that's being the focus of some much attention is 
addressed in the RFC 7208 security considerations (See section 11.4).

DKIM has a similar, but different problem.  The DKIM replay problem is bad 
enough that the IETF has chartered a working group to try to address it:

https://datatracker.ietf.org/doc/charter-ietf-dkim/

I'll lay out examples to demonstrate:

Case 1 - First Party Only

An organization only authorizes email to be sent from MTAs it directly 
controls (I know this mostly doesn't exist, but it's useful to show where the 
problems are).  The organization does not send email for any third parties.

In this case, as long as the organization can limit sending to authorized 
users, the quality of both SPF and DKIM pass results should be well aligned 
with the nature of the mail the organization sends.

Case 2 - Sender For Others, Own Domain

An domain uses it's own domain to send mail for others (like all webmail 
providers).  The domain's email is sent using it's own infrastructure, so it 
doesn't need to worry directly about third parties.

In this case, there's still no real risk of external forgery, so an SPF or 
DKIM pass means it was sent by the domain.  The risk is to the domain's 
reputation if users sign up and use the service to send "bad" mail.

If the domain fails to prevent 'bad' messages from being sent, then these 'bad 
messages get a DMARC pass.  The mail is sent through the authorized email 
server, so it gets SPF pass and a valid DKIM signature.

This is a particular threat for DKIM, because once this succeeds for a single 
message, the user can replay the message on third party infrastructure to send 
it to large numbers of recipients.  This is the core issue the DKIM working 
group was resurrected to address.  It is not, however, clear that there's a 
protocol solution to this problem and the group has been pretty quiet 
recently.

Case 3 - Sender For Others, Their Domain

When organizations authorized third parties to send on their behalf (by 
publishing an SPF record or a DKIM public key record in DNS), they are 
trusting their domain's reputation to those third parties.

In particular, they are at risk of those third parties doing poor inbound 
validation and other customers of the authorized third parties injecting 'bad' 
mail authorized by their domain.

This is where I think the focus of recent discussion has been.

In these cases, email is emitted via third parties and passes SPF (may also be 
DKIM signed, but I suspect it's less common because replay is easier), so it's 
authorized, but unwanted.

Case 2 and Case 3 are both real problems, but only because people are trying 
to make DMARC pass a positive assertion.  In order to do that reliably, 
organizations need to be more like Case 1 and be very careful vetting third 
parties that they authorize for.  I don't think that's a protocol problem.

Scott K




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