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

Re: [dmarc-ietf] Another p=reject text proposal

[Barry Leiba]

It's actually not even enough to check when you subscribe, though that
will help keep the user from being surprised later.  But you also have
to check every time a message is posted to the list, because anyone's
domain could have changed to p=reject recently.

And anyway, yes, the IETF considered that and decided, as you say, to
try to be more inclusive.  But we've seen problems caused by the From
rewriting also, related to difficulties in replying... it's not
benign.

Barry

On Tue, Jul 11, 2023 at 4:30 PM Tero Kivinen  wrote:
>
> Barry Leiba writes:
> > > 2) As others have observed, the mailing list problem is
> > > exclusively an evaluator error. An evaluator's job is to allow
> > > safe and wanted messages while blocking unsafe or unwanted
> > > messages.
> >
> > I disagree.  As I and others have observed, those creating the problem
> > are the ones who are using p=reject in a way that it was not intended
> > to be used.
>
> If we simply want to "fix" the mailing list issue, the mailing lists
> could simply refuse any subscription attempt from address which
> publishes p=reject, and say that your email address is not compatible
> with mailing lists in general, use some other address when sending
> emails to mailing list.
>
> On the other hand mailing list adminstrators usually try to include
> everybody, and not block people if they can cope with them, and thats
> why they do From address rewriting etc instead of just rejecting
> subscription requests.
> --
> kivi...@iki.fi

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

Re: [dmarc-ietf] Another p=reject text proposal

[Tero Kivinen]

Barry Leiba writes:
> > 2) As others have observed, the mailing list problem is
> > exclusively an evaluator error. An evaluator's job is to allow
> > safe and wanted messages while blocking unsafe or unwanted
> > messages.
> 
> I disagree.  As I and others have observed, those creating the problem
> are the ones who are using p=reject in a way that it was not intended
> to be used.

If we simply want to "fix" the mailing list issue, the mailing lists
could simply refuse any subscription attempt from address which
publishes p=reject, and say that your email address is not compatible
with mailing lists in general, use some other address when sending
emails to mailing list.

On the other hand mailing list adminstrators usually try to include
everybody, and not block people if they can cope with them, and thats
why they do From address rewriting etc instead of just rejecting
subscription requests.
-- 
kivi...@iki.fi

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

Re: [dmarc-ietf] Another p=reject text proposal

[Barry Leiba]

> To Murray's observation about fairness, my thoughts:

I don't see any use of the word "fair" in the message from Murray that
you quote.

> 1) Life is not fair.

This is impolitely dismissive.  Please don't do that.

> 2) As others have observed, the mailing list problem is exclusively an 
> evaluator error.  An evaluator's job
> is to allow safe and wanted messages while blocking unsafe or unwanted 
> messages.

I disagree.  As I and others have observed, those creating the problem
are the ones who are using p=reject in a way that it was not intended
to be used.  Many who support that use say that it's necessary to use
it that way; I and others disagree with that, and we can have and are
having that discussion.  But that *is* the genesis of the problem.
It's not fundamentally a mailing list problem and it's not really an
evaluator problem (but I'm willing to look at it partially that way,
because evaluators do have a choice, within DMARC, about how to use
the information that DMARC provides).

> 3) The problem can be solved by senders not asserting reject, by lists 
> rewriting From, or by evaluators
> using more than DMARC Fail alone.   Our document should address all three.  
> The only one that is
> guaranteed to provide delivery under all sender-evaluator combinations will 
> be From rewrite.

I don't think DMARCbis should be addressing what mailing lists can do
to work around it, and I disagree with your last sentence there:
rewriting the "From" header field has many problems and fails in a
number of ways, making it *not* guaranteed to provide delivery.  It's
also violating the sense of what "From" and "Sender" fields are meant
to convey.  As many of us have said, it's an ugly hack and is not
something that should be in a Standards Track specification.

Barry

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

Re: [dmarc-ietf] Another p=reject text proposal

[Douglas Foster]

To Murray's observation about fairness, my thoughts:

1) Life is not fair.

2) As others have observed, the mailing list problem is exclusively an
evaluator error.  An evaluator's job is to allow safe and wanted messages
while blocking unsafe or unwanted messages.

3) The problem can be solved by senders not asserting reject, by lists
rewriting From, or by evaluators using more than DMARC Fail alone.   Our
document should address all three.  The only one that is guaranteed to
provide delivery under all sender-evaluator combinations will be From
rewrite.

Doug Foster

On Sun, Jul 9, 2023, 1:14 AM Murray S. Kucherawy 
wrote:

> On Fri, Jul 7, 2023 at 6:14 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> Malicious impersonation creates a need for authentication.   If the list
>> makes changes that disable the originator's authentication, then it is the
>> list's problem to find a way to convince the recipient that the message is
>> not a malicious impersonation.  ARC and Munging together are the best
>> available way to do so, because no other options are on the table.
>>
>
> I continue to disagree with this line of thinking.  Lists have been
> behaving a particular way, with important operational benefits to users
> (unrelated to authentication), for a very long time.  That they should
> suddenly be told by senders that the Internet works a different way
> starting now and those behaviors are wrong and must be fixed, to me, defies
> reason.
>
> If you want to blame someone for the list problem, blame the criminals.
>>
>
> Here, we agree.
>
> -MSK, participating
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc